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

Sun Oct 16 07:37:12 UTC 2005

Tony,

On Oct 15, 2005, at 11:26 PM, Tony Li wrote:
> Paul is correct.  Things that looked like NAT were rejected because  
> "NAT is evil".

Religion is so much fun.

> Shifting the NAT to end system removed the objection to NAT, tho  
> it's not entirely clear why.  Shifting NAT to the end system also  
> happened to simplify the entire solution as well.

Except for the part about having to rewrite all existing  
implementations to take full advantage of the technology.

> VJ compression should not be considered a violation of the "end-to- 
> end" principle, as it is a per-link hack and performs a function  
> that CANNOT be performed in the end systems.  However, I'm not  
> entirely sure that this is relevant.

Well, if you NAT the destination identifier into a routing locator  
when a packet traverses the source edge/core boundary and NAT the  
locator back into the original destination identifier when you get to  
the core/destination edge boundary, it might be relevant.  The  
advantages I see of such an approach would be:

- no need to modify existing IPv6 stacks in any way
- identifiers do not need to be assigned according to network  
topology (they could, in fact, be allocated according to national  
political boundaries, geographic boundaries, or randomly for that  
matter).  They wouldn't even necessarily have to be IPv6 addresses  
just so long as they could be mapped and unmapped into the  
appropriate locators (e.g., they could even be, oh say, IPv4 addresses).
- locators could change arbitrarily without affecting end-to-end  
sessions in any way
- the core/destination edge NAT could have arbitrarily many locators  
associated with it
- the source edge/core NAT could determine which of the locators  
associated with a destination it wanted to use

Of course, the locator/identifier mapping is where things might get a  
bit complicated.  What would be needed would be a globally  
distributed lookup technology that could take in an identifier and  
return one or more locators.  It would have to be very fast since the  
mapping would be occurring for every packet, implying a need for  
caching and some mechanism to insure cache coherency, perhaps  
something as simple as a cache entry time to live if you make the  
assumption that the mappings either don't change very frequently and/ 
or stale mappings could be dealt with.  You'd also probably want some  
way to verify that the mappings weren't mucked with by miscreants.   
This sounds strangely familiar...

Obviously, some of the disadvantages of such an approach would be  
that it would require both ends to play and end users wouldn't be  
able to traceroute.  I'm sure there are many other disadvantages as  
well.  However, if an approach like this would be technically  
feasible (and I'm not entirely sure it would be), I suspect it would  
get deployed _much_ faster than an approach that requires every  
network stack to be modified. Again.  Particularly given the number  
of folks who care about multi-homing are so small relative to the  
number of folks on the Internet.

Can two evils make a good?  :-)

Rgds,
-drc
(speaking only for myself, of course)