| 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