[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bump in the Wire w/ attachment
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:
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 applications and systems.
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?
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