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

Tue Oct 18 16:10:41 UTC 2005

Tony,

On Oct 16, 2005, at 1:15 AM, Tony Li wrote:
> A real locator/identifier separation requires a rewrite.

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.

> Any system that provided site-wide source address control was going  
> to require a rewrite.

Not necessarily (depending on what you mean by the ambiguous term  
"address").  A lot depends on the actual requirements for source  
locator or identifier control.

> David, I should point out that if only a small number of folks care  
> about multihoming, then only a small number of folks need to change  
> their stacks.

I thought all clients would have to be modified if they wanted to  
take full advantage of a shim6 enabled multi-homed server?

> And even in your solution, there would need to be some changes to  
> the end host if you want to support exit point selection, or carry  
> alternate locators in the transport.

One of the problems that I have seen in the IETF is calling desires  
"requirements".  How important is exit point selection?  Are there  
ways of implementing exit point selection without changing the IP  
stack?  How critical is it that alternate locators be carried in the  
transport?  Does the lack of that functionality make the protocol  
unusable?

What _are_ the actual requirements (not the "Goals")?  From my  
perspective, the really, really critical flaw in both IPv4 and IPv6  
is the lack of _transparent_ renumberability.  Multi-homing is also a  
flaw, but less critical and I believe it can be addressed with the  
right solution to renumberability.  A "few" folks worry about multi- 
homing.  Everybody worries about end site renumbering.

> It's just a mess.  I think that we all can agree that a real  
> locator/identifier split is the correct architectural direction,  
> but that's simply not politically tractable.

Right.  And since it couldn't be done the right way in the protocol,  
we make the protocol much more complicated and force a reset to  
address functionality that relatively few folks need.

I'm suggesting not mucking with the packet format anymore.  It might  
be ugly, but it can be made to work until somebody comes up with  
IPv7.  Instead, since the locator/identifier split wasn't done in the  
protocol, do the split in _operation_.  Make the edge/core boundary  
real.  Both edge and core could be addressed without hierarchy, but  
the mapping between the edge and core would change such that the edge  
would never be seen in the DFZ.  Within the core, nothing new or  
different need be done (well, except for deploying IPv6 and running  
the core/edge translators).  Within the edge, nothing new need be  
done either.  Yes, it is a hack.  But I suspect it would address the  
real requirements (or, at least my pet requirement :-)).

Rgds,
-drc