[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bump in the Wire w/ attachment
As Paul says, there are significant differences between NAT-PT
attempting to mediate between two networks, and a local-link restricted
translator with one device behind it. The simplest interpretation is
that the translator in this case operates as an IPv6 host, and is
therefore "invisible" to the network (of course that leaves out a lot of
the real work the translator needs to do to accommodate the IPv4 host,
and act as its proxy to also make the IPv6 network "invisible" to the
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
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.
Paul C. Moster wrote:
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
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.
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?
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