And Now for Something Completely Different (was Re: IPv6 news)

Tue Oct 18 22:52:13 UTC 2005

Tony,

On Oct 18, 2005, at 1:56 PM, Tony Li wrote:

>> Not necessarily.  If you transition at the edge, what happens  
>> within the site matters only to the site and what matters to the  
>> core only matters to the core.  No stacks, either core or edge,  
>> need to be rewritten.
>>
> Transitioning at the edge implies to me that the hosts need to know  
> about different semantics for the IPv6 header.  That, in turn,  
> implies that there is different code for the hosts.
> Alternately, if there is no new code anywhere, it's clear that you  
> must necessarily have the same semantics and must not have made a  
> change.
>

No.  The only code change that must occur is at the core/edge  
transition device _at both ends_.  Let me try explaining this by  
example:

Assume you have:
- ISP A providing service to site X.
- ISP B providing service to site Y.
- ISP A has locator prefix A000::0
- ISP B has locator prefix B000::0
- Site X has identifier prefix 1000::0
- Site Y has identifier prefix 2000::0
- Host 1000::1 wants to send a packet to host 2000::2

Then:

1. Packet leaves host 1000::1 destined for 2000:2 and ends up at the  
site edge router for ISP A.
2. The site edge router for ISP A sees destination 2000:2 and looks  
up the locator in some globally distributed database using the  
identifier prefix 2000::0, getting back locator prefix B000::0.
3. The site edge router for ISP A rewrites the destination address  
with the locator prefix, i.e., B000::2.
4. The site edge router for ISP A forwards the packet to the next  
(core) hop for destination B000::2.
5. The site edge router for ISP B receives the packet destined for  
B000::2
6. The site edge router for ISP B rewrites the destination prefix  
with the identifier prefix, i.e., 2000::2
7. The site edge router for ISP B forwards the packet to the  
destination.

You want multi-homing?  Site Y has two ISPs, each having their own  
locator prefix, e.g., ISP B (B000::0) and ISP C (C000::0).  The  
lookup at step 2 returns two locators and the site edge router for  
ISP A can choose which path to take (perhaps with advice from the  
administrator of Site Y encoded in the response from the lookup,  
e.g., a preference or priority value).  Transparent renumbering is  
obvious.  Mobility might be possible with a little work and the old  
site edge router forwarding to the new site edge router for the  
duration of the cached response from the lookup.

No code changes within the site or within the core would be necessary.

Of course, the tricky bit is in looking up the locator in the  
globally distributed database and caching the response (which  
presumably would be necessary because the lookup will take a long  
time, relatively speaking).  When a new 'conversation' between two  
hosts start, the initial packet will obviously have increased  
latency, but subsequent packets could rely on cached information.

Again, I realize this is a hack, but I suspect it is a hack that  
impacts fewer points than something like shim6.

> Again, source address selection is going to require something  
> different than what we have today.  The host might have to interact  
> with some centralized policy server, execute a selection algorithm,  
> or consult an oracle.  Whatever that might be, there is new code  
> involved.
>

Well, yes, if source address selection is important.  My point was  
that there didn't have to be new code in the IP stack.

> As with any political process, the stated requirements are a  
> function of perspective.  The stated requirements may or may not  
> have anything to do with reality, realizability, practicality, or  
> architectural elegance.
>

Hmm.  Are the aliens who took the _real_ IETF and replaced it with  
what's there now going to give it back? :-)

> It could have been done the right way in the protocol, but it  
> wasn't.  Yes, the result is that the subsequent 'work around'  
> solution is much more complicated than it could have been.
>

I grant additional complexity is necessary.  However, additional  
complexity in every system seems like a bad idea to me.

> Again, between multihoming and mobility, the ubiquity and necessity  
> of Internet access, and the reliability of the last mile, this is  
> not going to remain a rare or even minority issue.
>

I very much agree.

Rgds,
-drc