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