Subject: Bump in the Wire w/ attachment

From: "Paul C. Moster" <[email-masked]>
Date: Mon, 09 Oct 2006 15:08:35 -0400

Here is a follow up to my previous mail the with Bump in the Wire 
draft as an attachment.

Paul Moster

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 9 Oct 2006 22:35:00 +0300

> Here is a follow up to my previous mail the with Bump in the Wire

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/

---

From: "Paul C. Moster" <[email-masked]>
Date: Mon, 09 Oct 2006 17:05:46 -0400

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

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 11 Oct 2006 11:11:28 -0400

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 
host.)

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.
>
> 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
>
>

-- 
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
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 Oct 2006 11:45:20 +0900

On Oct 12, 2006, at 12:11 AM, Ed Jankiewicz wrote:

> 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  

In private email, I discussed this briefly with Paul, and concluded  
that since (a) it is a transition effort and the working group is not  
supposed to work on transition approaches, and (b) it is as you say a  
redesign of an existing facility that has some fairly serious issues,  
that it was not appropriate - that we would wind up having the  
discussion yet again of whether translation is a rational long-term  
strategy as compared to upgrading the relevant equipment, installing  
a tunnel, or leaving IPv4 and IPv6 running in parallel, as opposed to  
actually discussing the document.

I'm willing to hear that I called this wrong. Comments?

---

From: Ed Jankiewicz <[email-masked]>
Date: Thu, 12 Oct 2006 10:55:41 -0400

Fair enough.  Full disclosure, if not apparent from my earlier posting, 
I am not an impartial commenter on this, having worked on the concept 
and prototype while previously at Datatek.  That being said, I am still 
looking for a way to say that this approach would be permitted on a 
network, where a user felt an external translation box was necessary for 
long-term adaptation of IPv4 legacy equipment (rather than device and 
application specific solutions like ALG it provides a generic means of 
adaptation.)  In my current job I support organizations that recognize 
such a need, whether rational or not, IPv4-only devices will persist for 
the long-term in their networks. 

Perhaps the discussion is not needed at all - a translation box built 
according to the concept in the draft would be an IPv6 host, and the 
"embedded" IPv4 device behind it completely invisible to the network.  
Under that guise, I would agree with you that it is not a topic for the 
v6ops WG to discuss, and no one even need know that a user was doing 
this.  Thus it is not an "operations" issue, a "protocol" issue or even 
a "transition" issue.  As long as the translator behaves properly as an 
IPv6 host, it will meet my definition of a "self-contained solution" in 
that there is no visible impact on any other network element or 
interoperability - i.e. you MAY do anything you want, but you MUST NOT 
ask anything else to do anything to enable you to do it.

In that spirit, I see no need to occupy the v6ops WG with any further 
debate on this topic.  And I understand the sensitivity in this WG for 
retreading ground already covered on transition in general, and 
translation in particular, and will respect that. 

Thanks, see you in San Diego.

Fred Baker wrote:
>> 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.
>
> strategy as compared to upgrading the relevant equipment, installing a 
> tunnel, or leaving IPv4 and IPv6 running in parallel, as opposed to