Subject: Re: Why is IPv6 a must?

From: [email-masked] (Sean Doran)
Date: Tue, 13 Nov 2001 00:31:53 +0100 (CET)

Keith Moore writes:

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

This is locator-sharing.

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

This is identifier-sharing.

Unfortunately, the overloading of locator and identifier, and
the bad habits that this overloading has engendered in people's
minds, means that neither of these is particularly palatable
at the moment, but neither are they impossible.

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.

	Sean.

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Nov 2001 19:16:50 -0500

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

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

> 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

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.

> 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