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" <cedric.aoun@nortelnetworks.com>
* Subject: Re: FW: I-D
ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
* From: Senthil Sivakumar <ssenthil@cisco.com>
* Date: Fri, 08 Oct 2004 16:17:25 -0700
* Cc: V6OPS <v6ops@ops.ietf.org>, "Elwyn Davies"
<elwynd@nortelnetworks.com>
* 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
issues mentioned
here as NAT-PT issues are known issues with address translation (NAT)
itself, so
attributing them to NAT-PT is not correct. Those should be categorized
as generic address
translation issues.
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
specific).
Regarding the conclusion, I don't agree with the fact that only
applicable scenario
is in 3G networks. During the past couple of years of my experience I
have seen
customers using it between isolated IPv6 networks to talk to existing
IPv4 networks.
A lot of cases it is not about the nodes being dual stack or not, it is
the network
that is not dual stacked for operational reasons.
I have been gathering some inputs from the customers who are using
NAT-PT currently
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
NAT-PT.
The point I am trying to stress is deprecating this would leave us with
no workable
solution for communicating between IPv4 only networks/nodes/apps IPv6
only
networks/nodes/apps. As remote as it might seem for some, that is the
use case
scenario we have encountered as the applicability of NAT-PT.
Senthil
At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote:
Hi,
As discussed at IETF 60, the WG agreed to continue the NAT-PT
deprecation analysis.
We would really appreciate if you could provide us your feedback on
the initial version of the deprecation analysis by Monday October 4th.
Regards
Cedric Aoun
------ Forwarded Message
From: <Internet-Drafts@ietf.org>
Reply-To: <internet-drafts@ietf.org>
Date: Tue, 21 Sep 2004 21:38:33 +0200
To: <i-d-announce@ietf.org>
Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
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
Network
Address Translator - Protocol Translator (NAT-PT) defined in
RFC 2766
should be deprecated and RFC2766 moved to historic status.
Description of an alternative protocol translation mechanism is
out
of scope for this document.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-deprecate-00.
txt
To remove yourself from the I-D Announcement list, send a message
to
i-d-announce-request@ietf.org with the word unsubscribe in the
body of the message.
You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with
the username
"anonymous" and a password of your e-mail address. After logging
in,
type "cd internet-drafts" and then
"get draft-aoun-v6ops-natpt-deprecate-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE
/internet-drafts/draft-aoun-v6ops-natpt-deprecate-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use
this
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-compliant
mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been
split
up into multiple messages), so check your local
documentation 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
Internet-Draft.
------ End of Forwarded Message