> | there is another important difference between v4 and v6 - we don't have > | enough addresses for everyone to use v4. > ^^^^^^^^ (... at the same time) > > That is, either some subset of everyone can use v4 with addresses > which are changed relatively infrequently, or everyone can use > v4 with addresses with relatively short leases that expire as > soon as possible as a device goes dormant.
"some subset of everyone" doesn't work well. either you have to find some way of deciding who can use the internet at a particular time, or you have to divide the internet up (rather arbitrarily) into discrete subsets, which gives you the suite of NAT problems. short leases don't work for applications whose run times overlap the lease expirations. > | there is another important difference between v4 and v6 - we don't have > | enough addresses for everyone to use v4 [classic]. > ^^^^^^^^ (... to talk to everyone else) > > Or, some subset of everyone can use v4 with globally unique addresses, > or everyone can use v4 with addresses which are only locally unique > (and must therefore use translators to talk to things in other locations). and since translators only work for pairwise connections, this severely constrains the kinds of applications that can be run. > Unfortunately, the overloading of locator and identifier, and > the bad habits that this overloading has engendered in people's > minds, one of the worst habits here is the failure to analyze the effects of such constraints on all aspects of the Internet - not just routing but also management, and applications, and users. > means that neither of these is particularly palatable > at the moment, but neither are they impossible. it's not the bad habits that you are referring to that make NATs unpalatable. it's the fact that they break applications, make networks more fragile and more difficult to configure, and increase the difficulty of diagnosing problems. nor is it clear to me that merely having had separate locators and endpoint identifiers in IPv4 (from day one) would have solved the routing scalability problem. - having a separate endpoint identifier would have allowed applications to deal with changes in locator only if the endpoint identifiers were globally usable to reach the endpoint, and only if changes in the locator were transparent to the applications. in other words, whenever the locator for an endpoint changes you have to have some way of quickly and reliably informing everyone who is using that locator. - being able to route to a host via multiple locators doesn't help unless the guy who is making the routing decision actually has reliable information on which to base that decision. this is why the notion of v6 multihoming using DNS isn't terribly useful - because the host or application that is making the decision typically doesn't have the information it needs to make that decision. - being able to renumber frequently to reflect changes in topology would help. but the difficulty in renumbering isn't just due to those addresses being wired into DNS and host stacks - they're also wired into routers, firewalls, network management stations, etc. making renumbering painless also involves tackling some thorny authentication issues that still haven't been addressed in BGP. separating locators from endpoint identifiers might have been part of the solution, but it seems more likely that we would have needed a complete renumbering architecture. otherwise there would have been nearly as much resistance to renumbering as there is now. > I agree that locator- and identifier-sharing are both non-ideal, > but they may be more practical than moving to a system which > still overloads locator and identifier in a flat address anyway. I strongly suspect that if/when we find a solution to this constraint set that it will involve some separation of identifiers relative to what we have now. but I also strongly suspect that a solution to the whole constraint set (not just the routing problem but also the management problem and still having a network that can support many kinds of applications) is one that mostly uses locators internally to the routing system and mostly insulates locators from end hosts. most of the ideas I've seen expect the locator to live in the field now occupied by the IP address, at least as seen by the host. and even if we implemented that separation in IPv4, I sincerely doubt we could manage delegation and assignment within a 32-bit wide endpoint identifier space efficiently enough to be able to assign endpoint identifiers to everyone that needed them. Keith
