This was raised way back in October that many of the issues are generic
and not NAT-PT specific. Here is the email that was sent earlier.
* To: "Cedric Aoun" <email@example.com>
* Subject: Re: FW: I-D
* From: Senthil Sivakumar <firstname.lastname@example.org>
* Date: Fri, 08 Oct 2004 16:17:25 -0700
* Cc: V6OPS <email@example.com>, "Elwyn Davies"
* In-reply-to: <BD770085.7553%CEDRIC.AOUN@europem01.nt.com>
* References: <200409211938.PAA14143@ietf.org>
I see that the draft has consolidated all the previous drafts that
highlighted the issues
of NAT-PT and DNS ALG, which is a good thing. However, most of the
here as NAT-PT issues are known issues with address translation (NAT)
attributing them to NAT-PT is not correct. Those should be categorized
as generic address
Some specfic comments on the following issues.
* Disruption of all protocols which embed IP addresses (and/or
ports) in packet payloads or which apply integrity mechanisms
using IP addresses (and ports). (not NAT-PT specific).
* Requirement for applications to use keep alive mechanisms to
workaround connectivity issues caused by premature NAT-PT state
timeout. (not NAT-PT specific).
* Inability to redirect packet fragments after the first with
NAPT-PT. (not NAT-PT specific).
o Issues which are exacerbated by the use of a DNS-ALG:
* Constraints on network topology. (not NAT-PT specific).
* Scalability concerns together with introduction of single point
of failure and security attack nexus.(not NAT-PT specific).
* Lack of address mapping persistence: Some applications require
address retention between sessions. The user traffic will be
disrupted if a different mapping is used. The use of the
DNS-ALG to create address mappings with limited lifetimes means
that applications must start using the address shortly after
the mapping is created, as well as keeping it alive once they
start using it.(not NAT-PT specific).
* Creation of a DOS threat relating to exhaustion of memory and
address/port pool resources on the translator.(not NAT-PT
Regarding the conclusion, I don't agree with the fact that only
is in 3G networks. During the past couple of years of my experience I
customers using it between isolated IPv6 networks to talk to existing
A lot of cases it is not about the nodes being dual stack or not, it is
that is not dual stacked for operational reasons.
I have been gathering some inputs from the customers who are using
regarding this draft. I can consolidate and forward the comments if you
are interested in
knowing and understanding why they think they are moving forward with
The point I am trying to stress is deprecating this would leave us with
solution for communicating between IPv4 only networks/nodes/apps IPv6
networks/nodes/apps. As remote as it might seem for some, that is the
scenario we have encountered as the applicability of NAT-PT.
At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote:
As discussed at IETF 60, the WG agreed to continue the NAT-PT
We would really appreciate if you could provide us your feedback onthe initial version of the deprecation analysis by Monday October 4th.
------ Forwarded Message
Date: Tue, 21 Sep 2004 21:38:33 +0200
Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts
Title : Reasons to Deprecate NAT-PT
Author(s) : C. Aoun, E. Davies
Filename : draft-aoun-v6ops-natpt-deprecate-00.txt
Pages : 24
Date : 2004-9-21
This document discusses reasons why use of the specific form of
IPv6-IPv4 protocol translation mechanism implemented by the
Address Translator - Protocol Translator (NAT-PT) defined inRFC 2766
should be deprecated and RFC2766 moved to historic status.
Description of an alternative protocol translation mechanism isout
of scope for this document.
A URL for this Internet-Draft is:
To remove yourself from the I-D Announcement list, send a messageto
firstname.lastname@example.org with the word unsubscribe in thebody of the message.
You can also visithttps://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with
"anonymous" and a password of your e-mail address. After loggingin,
type "cd internet-drafts" and then
A list of Internet-Drafts directories can be found in
Internet-Drafts can also be obtained by e-mail.
Send a message to:
In the body type:
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To usethis
feature, insert the command "ENCODING mime" before the"FILE"
command. To decode the response(s), you will need"munpack" or
a MIME-compliant mail reader. Different MIME-compliantmail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have beensplit
up into multiple messages), so check your localdocumentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
------ End of Forwarded Message