[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
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