> .. 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.
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