Subject: Re: [rrg] ILNP

From: RJ Atkinson <[email-masked]>
Date: Wed, 19 May 2010 18:01:18 -0400

Noel,

  Your assumption that "generic IPv4/IPv6 translating routers" 
even exist (outside a lab or trial) is wrong, as near as I can tell.  
I believe there have been several IETF attempts at specifying how 
that would work, including some current (?) I-Ds in the BEHAVE WG,
but there hasn't yet been a successful (i.e. widely available/deployed)
outcome as near as I can tell.  There are disagreements among 
various folks whether such translation devices are necessary or
desirable for the Internet.  I am told Comcast is an example of
an ISP that would like to deploy some sort of IP protocol 
translation device within its network.

  A primary reason that kind of protocol translation does not 
work well for IP is in fact the lack of a non-topological 
Identifier for use in TCP/UDP/etc.  Kindly recall that with IP 
(IPv4 or IPv6) TCP binds to the IP address in use, whereas TCP 
for ILNP binds to the IP-version-independent 64-bit Identifier 
value.

  So I believe that ILNP makes ILNPv4/ILNPv6 translation MUCH
easier than IPv4/IPv6 translation, because one merely needs 
to munge the Locator bits and then mechanically remap some of the 
other bits (e.g. between the ToS bits within the IPv6 Flow Label 
and the IPv4 ToS byte).  As I've noted, the algorithms defined in 
RFC-4291 works FINE mechanically for ILNPv4 -> ILNPv6 translation.  
Translation in the other direction works equally mechanically 
provided the ILNPv6 side happens to use an IPv4 translated Locator.  
In the case where the ILNPv6 side does not happen to use an IPv4 
translated Locator, then one needs a bit more intelligence
inside the translation device.  That noted, such a translation
device is not more complex than a typical home NAT gateway
(and appears less complex than the IPv4/IPv6 translators being 
discussed within the IETF BEHAVE WG) and those home NAT gateway 
devices are both cheap and widely deployed.

  It is not the case that "the entire IPv4 routing table
must be injected into the IPv6 routing".  In a typical 
deployment, such protocol translation is performed by a site's
own border routers.  So, within a site, a single IPv4 default 
route can be injected to carry all IPv4 traffic to the site's 
Site Border Router(s).  I believe this is commonly done today
for the ordinary non-IPv6, non-ILNP deployments.  For ILNPv6
nodes initiating a session with an ILNPv4 node, mechanical 
translation suffices to create packets and send them out.  
For the situation of an ILNPv4 node initiating communications 
with an ILNPv6 site, the destination ILNPv6 site can advertise 
an LP record for the whole site pointing at its own Site Border 
Routers' L32 record(s).  This provides all the information an
ILNPv4-only node would need to create correct packets and send
them to the destination Site Border Routers, who would then 
handle any further protocol processing and packet forwarding
that is necessary.

  Parts of the above come out in some of our prior work, 
for example the MILCOM papers' discussion of topology obfuscation
and the potential role of Site Border Routers in optional
Locator rewriting, but as with many other topics, absence of time 
limits what has been put down "cookbook" style or even just 
documented precisely in an Internet-Draft.  Sadly, there just
hasn't been time yet to write down all the details that the ILNP
community has thought about at length.

  In any event, at this time, this is the wrong mailing list 
for this discussion, as this mailing list is focused on the
contents of the RG Recommendation document.

Yours,

Ran