Re: [RRG] Six/One Router: Provider-Independence, IPv4/IPv6 Interworking, Backwards-Compatibility

Christian Vogt <christian.vogt@nomadiclab.com> Wed, 05 March 2008 18:28 UTC

Envelope-to: rrg-data@psg.com
Delivery-date: Wed, 05 Mar 2008 18:28:56 +0000
Cc: Routing Research Group Mailing List <rrg@psg.com>
Message-Id: <BDC1B771-A315-4E5E-8739-21A8066F78FC@nomadiclab.com>
From: Christian Vogt <christian.vogt@nomadiclab.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: [RRG] Six/One Router: Provider-Independence, IPv4/IPv6 Interworking, Backwards-Compatibility
Date: Wed, 05 Mar 2008 20:28:20 +0200

Brian -

Six/One Router and Proxy Shim6 use similar techniques -- such as  
packet extension headers, unilateral NAT'ing, DNS proxying --, but the  
way these are put together is different in the following aspects:

(1)  The use of unilateral and bilateral address translation in Six/ 
One Router, instead of Proxy Shim6's combination of "implicit"  
tunneling (where the inner tunnel header is replaced by an index to  
state in the proxies) and unilateral address translation, enables  
packet exchanges where one address is translated bilaterally and the  
other unilaterally.  This is useful when a host contacts a peer by  
locator (which it may have gotten via a referral), although both hosts  
are in upgraded edge networks and would better use IDs.  The end-to- 
end semantics of the initiator's ID can then be retained through  
bilateral translation, whereas the responders ID can necessarily be  
translated only unilaterally.  Proxy Shim6 does not allow this case in  
its current version.

(2)  The pure use of address translation also enables seamless  
integration of the IPv4/IPv6 interworking techniques currently  
developed in v6ops [M-NAT, SHANTI], because those are also based on  
address translation.  This means that you can also allow IPv6 hosts to  
communicate with IPv4 hosts.  (Of course, you are still bound by the  
well-known limits of translation-based IPv4/IPv6 interworking  
techniques, but v6ops is working on improving them.)

(3)  For packet exchanges between upgraded edge networks, Six/One  
Router carries all translation state in extension headers.  This  
improves robustness in the presence of handovers or failovers between  
Six/One routers.  Proxy Shim6 depends on state kept in proxies (I  
called it "implicit" tunneling above), so for a handover or failover  
to work, a new proxy must somehow learn the state in the previous proxy.

(4)  Six/One routers are located on-path (on edge network border  
links), whereas Shim6 proxies are in general off-path.  The advantage  
of off-path proxies is that traffic from multiple providers can go via  
a single proxy.  But this requires special routes and tunnels within  
an edge network to ensure that traffic goes via a proxy and via the  
right provider.  Six/One Router does not depend on special routes or  
tunnels.

(5)  Six/One Router verifies ID-to-locator mappings via the mapping  
resolution system rather than through cryptographic properties of IP  
addresses [HBA, CGA] as in Proxy Shim6.  This makes address  
configuration less complex, provides higher flexibility (e.g., it also  
enables use of Stateless Address Autoconfiguration), and allows sites  
to keep their existing addresses when upgrading to Six/One Router.

Having said this, I believe that Proxy Shim6 could well be modified  
such that it supports the above-mentioned features of Six/One Router.   
Given that Proxy Shim6 and Six/One Router already share many  
techniques, the necessary modifications seem quite feasible.

- Christian



On Mar 5, 2008, at 2:39 , Brian E Carpenter wrote:

> I'm wondering what is the high-level conceptual gap between
> this proposal and Proxy Shim6 (draft-bagnulo-pshim6-02.txt).
> They seem to be aiming at a very similar result, except that
> Proxy Shim6 doesn't rely on any new map beyond what is
> implied by certain DNS RRs. They're both forms of what
> I've thought of as "architected NAT" since the original
> 8+8 proposal.
>
>    Brian




--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg