Re: draft-kurtis-multihoming-longprefix comments

[David Conrad <david.conrad@nominum.com>]

Tony,

On Tuesday, January 7, 2003, at 06:29  PM, Tony Li wrote:
> 16+16 would be very visible to the apps.  In fact, any change that has
> independent identifiers and locators would be a change to the apps.
Perhaps I misunderstand, but I don't see why this is the case.

If you assume a border between the part of the network that cares about 
topological significance (that is, the core) and the part that does 
(that is, the end points), then doing mapping/unmapping at that border 
would be invisible to the applications -- the core only cares about the 
locator, not the end point identifier.

For example, assume you throw out the current IPv6 address architecture 
and instead say that the lower 4 bytes of an IPv6 address is an IPv4 
address.  Now, assume reality in the on the non-core side of the border 
gateway, end users use IPv4.  When a packet needs to transit the (IPv6 
using) core, the border gateway does (the moral equivalent of) a 
(dnssec signed, of course) AAAA in-addr-style DNS lookup of the 
destination IPv4 address and synthesizes an IPv6 destination address 
composed of the destination IPv6 prefix returned by the DNS lookup (in 
the top half) and the destination IPv4 address (in the bottom half).  
When the packet hits the destination border, an IPv4 packet is 
synthesized from the lower 4 bytes of the IPv6 address.  If you don't 
want to assume reality, use up to 8 bytes (or more, since we've agreed 
to throw out the existing IPv6 addressing architecture) for the end 
point identifier -- the in-addr-style lookup wouldn't care.

Site multi-homing becomes trivial -- simply add additional prefixes in 
the RR set referenced by the in-addr-style lookup of the IPv4 host.  If 
you want to get tricky, the border gateway could keep information about 
which prefix is best among the ones returned.  Renumbering also becomes 
essentially a non-issue as it can be made transparent to the end users 
since end users are dealing with non-hierarchical identifiers.  
Mobility might also be simplified, although I think there are some 
issues wrt trust boundaries that need more thought.

Of course, this is just an example of how one could implement a 
locator/identifier mapping mechanism that doesn't require apps to 
understand that mapping -- the key is to have a way of doing an 
'unmapping'...

Rgds,
-drc