Subject: Re: My thoughts on local-use addresses

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 1 May 2003 06:37:16 -0400

> From: Keith Moore <[email-masked]>

    > .. I don't see a significant market for IPv6 if it doesn't support
    > applications that cannot be run on NATted IPv4. Yes, there may still be
    > some small advantage of IPv6 for some groups of users if this doesn't
    > happen, but not for the Internet community as a whole.
    > ...
    > In order to create a significant advantage, there need to be so few
    > NATs in IPv6 that application developers can write applications that
    > will fail in the presence of NATs ..
    > I agree that there's a requirement for PI addresses

The irony here is pretty striking.

IPv6 (you reckon) won't succeed in taking off unless it can get rid of NAT's,
but people have NAT's (in part) because they want identifiers for their
machines that are independent of their location in the connectivity topology.
Clearly, you can't have a single label which is both location-independent (so
it's provider independent) and location-dependent (so that the routing
works). Which is why people use NAT's to do this... but you claim IPv6 will
fail to take off if it can't get rid of NAT's.

The irony is that in the architectural discussion phase (such as it was) of
IPng, it was proposed that these two functions (location and identification)
be split, but this concept was fiercely resisted by the IPv6 designers; it
will be extremely piquant if this decision results in continued desire for
NAT's, and therefore (if you're right) the failure of IPv6 to take off...

	Noel

---

From: Keith Moore <[email-masked]>
Date: Thu, 1 May 2003 15:12:34 -0400

>     > .. I don't see a significant market for IPv6 if it doesn't
>     > support applications that cannot be run on NATted IPv4. Yes,
>     > there may still be some small advantage of IPv6 for some groups
>     > of users if this doesn't happen, but not for the Internet
>     > community as a whole....
>     > In order to create a significant advantage, there need to be so
>     > few NATs in IPv6 that application developers can write
>     > applications that will fail in the presence of NATs ..
> IPv6 (you reckon) won't succeed in taking off unless it can get rid of
> NAT's, but people have NAT's (in part) because they want identifiers
> for their machines that are independent of their location in the
> connectivity topology.

People have NATs for a wide variety of reasons:

- they can't get enough global addresses for their hosts
- they are deluded into thinking they provide security
- they don't want to have to renumber
- they need to connect between multiple sites using overlapping
  address space
- they don't realize they have a NAT, they think it's a "firewall"
  or some such
- their ISPs force NATs on them

...but I doubt that a significant percentage of users think in terms
of "want[ing] identifiers for their machines that are independent of
their location in the connectivity topology".  You and I think that
way, but this is not what motivates users to purchase NATs.  Users want
their networks to be secure and easy to manage and for their apps to
work; they buy NATs because they think that under current circumstances
these conditions are better met with NATs than without.  Some of those
users may even be right, at least in the near term, and for the apps
they anticipate wanting to use.  We're more concerned about the future.

Now, I agree that location-independent identifiers would be desirable IF
they were globally scoped and globally usable, but NATs (at least,
any kind of NATs we've envisioned so far) would not provide these.
Locally scoped identifiers can be stable on the local net (though they
aren't necessarily so, even behind a NAT)  But it's becoming more
apparent that stable local identifiers are not sufficient, unless the
only apps we want to run over the global network are two-party apps with
ephemeral connections.

> Clearly, you can't have a single label which is both
> location-independent (so it's provider independent) and
> location-dependent (so that the routing works). 

It depends on what you mean by "routing".  Users don't care about the
mechanism for how those packets get there, they care whether the apps
work.  If the packets had to get redirected from a location-independent
address to a location-dependent address, that would be fine with users
as long as that operation happened quickly and reliably enough to suit
the users' apps.  Of course, our existing protocols don't really support
this (with the possible exception of mobile IP, which never seems to
get finished) but I don't think it's a matter of "clearly, you can't" do
this.

> Which is why people use NAT's to do this...

Except that NATs don't do this, unless the only apps you care about are
local apps.  And experience indicates that users don't just care about
local apps.

> The irony is that in the architectural discussion phase (such as it
> was) of IPng, it was proposed that these two functions (location and
> identification) be split,

Lots of good ideas got passed over in the IPng discussion.   Despite
that, I think that IPv6 ended up "about right" - modulo a few warts like
A6 and SL and over-reliance on address selection.  By "about right" I
mean that I think that if the warts are fixed it will become feasible to
gracefully extend the IPv6 architecture in useful ways - such as to
provide the capability to use identifiers rather than locators -
without invalidating hosts or apps that were written to the basic IPv6
model.  (there are still some other warts - e.g. wired-in assumptions
about prefix lengths - that I suspect will bite us sooner or later)

Keith

---

From: james woodyatt <[email-masked]>
Date: Thu, 1 May 2003 08:08:44 -0700

On Thursday, May 1, 2003, at 03:37 US/Pacific, J. Noel Chiappa wrote:
>
> [...] IPv6 (you reckon) won't succeed in taking off unless it can get 
> rid of NAT's, but people have NAT's (in part) because they want 
> identifiers for their machines that are independent of their location 
> in the connectivity topology.  Clearly, you can't have a single label 
> which is both location-independent (so it's provider independent) and 
> location-dependent (so that the routing works). Which is why people 
> use NAT's to do this... but you claim IPv6 will fail to take off if it 
> can't get rid of NAT's. [...]

I work for a company that sells a NAT device.  Among other things, I 
maintain the ALG's in that NAT.  My code is bundled into their 
802.11b/g access point.  They also have a software version of this 
product bundled into the operating system they own for the computers 
they make.

I can assure you that the vast majority of those customers using the 
NAT in either of these products-- and I get a lot of customer feedback 
in the form of bugs and enhancement requests-- are doing so for reasons 
that are far less technical than you suggest.

They are *not* doing it because they "want identifiers for their 
machines that are independent of their location in the connectivity 
topology."  They are doing it because they want to share their Internet 
access with multiple computers.  The extent to which they are unhappy 
with the NAT function in those products is exactly the extent to which 
NAT fails to be totally transparent-- which it can never be, because of 
the Internet architecture.

If the only customers using NAT were the ones that really really really 
wanted "identifiers for their machines that are independent of their 
location in the connectivity topology," then I would feel completely 
safe writing applications that fail in the presence of NAT.  They would 
not be deployed in anywhere near the numbers they are clearly deployed 
now.  (In fact, I'd probably be extra tickled by the fact that my 
application failed on the remaining networks.  Their managers would be 
getting what they deserve, in my jaundiced view.)

Have any of you looked at the actual marketing copy that sells real 
people on why they might want to pay real money for a NAT box?  It 
might be instructive.

-- 
j h woodyatt <[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Thu, 1 May 2003 17:53:10 -0400

> in  many enterprise/organizational situations, and at least some 
> home networking ones, communication among hosts on the local 
> network is very important, perhaps equally important as 
> communication with outside hosts.  

I didn't claim otherwise; in fact I suspect that internal communication
is often viewed as more important than external communication.  However,
what I said was  "users don't *just* care about local apps" (emphasis
added).  Which, for instance, is why there is a demand for ALGs in NATs.

> Now, in the IPv6 "multiple addresses per host" model, it would 
> make perfect sense to assign every host on such a subnet an 
> address that was specific to that subnet (or enterprise) and, 
> for those hosts that needed external accessibility, an 
> additional, presumably globally-routable, address. 

It might seem to make perfect sense at first glance, but I'm not sure
that it holds up under analysis.  First, as long as hosts are free to
assign their own addresses, using DHCP (or RA) as a means of access
control to external links doesn't seem very robust.  Second, the
design decision to use multiple prefixes has consequences for
applications that are almost certainly unintended and undesirable.

Now having a set of addresses that are stable across provider changes
really does seem useful, but I see no inherent reason that such
addresses should be only unique (or valid) within the local network. 

> > Lots of good ideas got passed over in the IPng discussion.
> > Despite that, I think that IPv6 ended up "about right" -
> > modulo a few warts like A6 and SL and over-reliance on address
> > selection.  By "about right" I mean that I think that if the
> > warts are fixed it will become feasible to gracefully extend
> > the IPv6 architecture in useful ways - such as to provide the
> > capability to use identifiers rather than locators - without
> > invalidating hosts or apps that were written to the basic IPv6
> > model.
> 
> Keith, I think I agree with you about the "despite that" part of 
> the above (I certainly agree about the "passed over" part). 
> However, if our confusion about how to best handle multiple 
> addresses per host, and where to do so, results in our moving to 
> a "one host, one address" model and a flat, IP-level, address 
> space, I think some of the "graceful extension" potential will 
> disappear.  Indeed, if we go down that path --which I think you 
> have been advocating, although I'm not sure-- I suspect that we 
> had better have a general routing solution that is not dependent 
> on address aggregation before we move much further forward with 
> IPv6 deployment.

Frankly I don't know where this needs end up.  I don't think it ends up
with a purely "one host, one address" model, for a variety of reasons. I
do think it might end up with a model where there are "distinguished
addresses" (or if you prefer, identifiers) for hosts that are generally 
preferred over other addresses or identifiers, but can be automatically
forwarded and/or mapped to locators that can be routed by traditional
means.

I'm looking at various ways of doing this, some of which involve
site-relative locators and some of which don't.  So far I haven't seen a
case wehre relative locators are required.  They can make certain cases
easier- particularly isolated newtorks.  But they seem to make the
overall solution more complex and less robust, even when they're not
exposed to applications.  

I'm still working on understanding this landscape, so I might find a
compelling case for site-relative locators.  But I suspect not.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 May 2003 17:09:53 -0400

--On Thursday, 01 May, 2003 15:12 -0400 Keith Moore 
<[email-masked]> wrote:

> Except that NATs don't do this, unless the only apps you care
> about are local apps.  And experience indicates that users
> don't just care about local apps.

Keith, your mileage may, and probably does, differ.  But, in 
many enterprise/organizational situations, and at least some 
home networking ones, communication among hosts on the local 
network is very important, perhaps equally important as 
communication with outside hosts.  That is especially true in 
the enterprise "intranet" context, in which many users are, on a 
given day, likely to exclusively access internal web sites, 
directories, calendaring systems, etc.  Those usage patterns are 
independent of whether the addresses are global but inaccessible 
from the outside due to filtering or firewall restrictions or 
whether they are "private" space with external connectivity, if 
any, going through a NAT.

Now, in the IPv6 "multiple addresses per host" model, it would 
make perfect sense to assign every host on such a subnet an 
address that was specific to that subnet (or enterprise) and, 
for those hosts that needed external accessibility, an 
additional, presumably globally-routable, address.  If the 
subnet-specific address was appropriately obtained*, it could be 
completely independent of external providers and completely 
stable.  That would confer some small, but non-trivial 
advantages over having a single set of addresses that are 
provider-dependent.  Among other things, I can imagine several 
ways in which having one set of stable addresses that could be 
relied upon for local (intra-enterprise) host management would 
be a help in working through a provider-switch renumbering 
exercise (on the other address(es)).

Of course, none of this is dependent on whether those 
subnet-specific addresses are from a reserved "private" range 
rather than being unique addresses that no one intends to route 
outside the LAN (or enterprise/organization).

Of course, as soon as a given host has more than one address, at 
least some of the issues that Tony has been trying to describe 
become important: _something_ needs to figure out which one(s) 
to use, even if only by the trial and timeout process which, as 
you have pointed out, is much too slow (at least in the general 
case).

>> The irony is that in the architectural discussion phase (such
>> as it was) of IPng, it was proposed that these two functions
>> (location and identification) be split,
>

       john