| Who says you need to use the IP addresses for that purpose? There is
| plenty of precedent -- for a a long time we've had this notion of the
| routing protocols adding labels on that had nothing to do per se with
| the IP address. See the "AS" notion, for example, in which we label
| various clouds with AS numbers, which are never seen by end users. It
| would be straightforward enough to build a labeling scheme that was
| used inside the routing protocol that stayed inside the routing
| protocol. You could happily label the nodes of the routing cloud with
| whatever numbering/labeling scheme you like.
Map-and-encap systems can work quite well; it's mostly a question
of making sure the various mapping points can coordinate with various
things (and each other), and making sure they can cope with
the map-encap-decap-process operations they have to perform.
One of the systems you have rubbished in this thread is
heavily influenced by, and even reliant upon, map-and-encap,
and several smart people believe it would work OK.
Peter Lothberg (whom I find myself agreeing with alot) is
the progenitor of an interesting map-and-encap system which
allows for (among other things) separating end-to-end identity
from topological location.
Unfortunately, map-and-encap systems can also be like MPLS...
Anyway, if you are going to use the same encapsulated
payload and are going to have a common globally unique
identifier inside that payload, why not integrate the inside
and outside headers, rather than use encapsulation and
information pull-up/push-down, which are inevitably more expensive?
Again, Peter once proposed putting a stack of MPLS-style labels
(or IPv4 addresses, a la LSRR) into the first bytes of an 8+8-like system.
You will see more of this later.
| In other words, v6 has neither helped nor hurt the routing problem --
| it is orthogonal.
Well, yes, that's what we've been saying all along!
Sean.