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 _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
