The great thing about a link-local approach to translation (or BIW as the authors now call the approach) is that it is a self-contained solution: no other network element MUST do anything so that any legacy application MAY use this approach. The issue that some folks I work with have with "translation" is simple: the user groups they represent have massive investment in recently networked systems that are IPv4-only, and they need a non-experimental technique that they can recommend as a last-resort for adaptation of these legacy devices. v4 over v6 or other approach only solves the easy part of the problem (IPv4 peers) but not the knotty residual issue of IPv4-legacy interoperability with IPv6-only applications/devices (or applications that utilize IPv6 features not available to an IPv4-only device.) Otherwise, they have a strong disincentive to adopt IPv6 in the near future. They need something like this in the tool kit, and I would guess that other large organizations elsewhere that MAY want to use a translation approach. At this time the status of NAT-PT (considered Experimental, or perhaps officially Experimental now?) almost dictates that applications MAY NOT use translation.
The advice I would give the authors would be to continue to make this case, but they should submit the draft as an individual contribution (rather than requesting it be a WG work item which may reignite the controversy over whether the v6ops WG wants to "reinvent NAT-PT".) I hope the WG chairs and members would be at least willing to discuss this draft at IETF 67. I will be there, and would like to see this work progress in a way that satisfies the questions raised by the WG and IETF community, protects other network elements and operators from any actual ill effects (not just the same "translation BAD" argument) and gives end-users a viable method to recover their investment in network-centric applications and systems.
I too have not had sufficient time to review the entire document (I assume a diagonal reading is what we in the US call "skimming"), but in general I find it well written and it substantially advances the concept from the prior work I had been involved with. Again, I encourage the WG to focus on what sets this apart from disfavored approaches like NAT-PT, and consider it on its own merit.
Ed Jankiewicz SRI International Paul C. Moster wrote:
Rémi,I think that you are correct. The BIW draft describes a reinvention, or specialization, of NAT-PT. A BIW translator is a NAT-PT that is dedicated to serving a single IPv4-only host. In this restricted role, there are differences between a BIW translator and an RFC2766 NAT-PT. These differences are in the details, however. It is still doing address and protocol translation.Here are two major differences between a BIW translator and an RFC2766 NAT-PT:A BIW translator uses private IPv4 addresses to represent IPv6-only hosts. As a result, IPv4/IPv6 address bindings can persist indefinitely, since there's no rush to reclaim a global IPv4 address for another host to use.A BIW translator serves as the host's proxy on a dual IPv4/IPv6 network, so it needs to pass some IPv4 packets from the host to the network side without protocol translation. It must also participate in SLAAC and DHCP on the host's behalf.Paul At 03:35 PM 10/9/2006, Rémi Denis-Courmont wrote:Le lundi 9 octobre 2006 22:08, vous avez écrit : > Here is a follow up to my previous mail the with Bump in the Wire > draft as an attachment. I ony read the document “diagonaly”, and I might actually have gotten it wrong, but I have a feeling this is a reinvention of NAT-PT. Could you explain how does this new mechanism compare to the latter? -- Rémi Denis-Courmont http://www.remlab.net/
--Ed Jankiewicz - SRI International Fort Monmouth Field Office Supporting US Army CERDEC - XGN and DISA Standards Engineering Branch
732-427-4522 or 732-389-1003 ed.jankiewicz@sri.com