[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 agree with Shivkumar that deprecating NAT-PT really doesn't earn us
anything but removes one tool that could be used in specific instances.
Application gateways are not in the same usage "level" as NAT-PT - they
occur in different points of the network. Also, the underlying algorithm of
SIIT would still be available.
Sham
-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
Of Brian E Carpenter
Sent: Saturday, October 09, 2004 9:10 AM
To: Senthil Sivakumar
Cc: Cedric Aoun; V6OPS; Elwyn Davies
Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> 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.
But there is a workable alternative, which is an application level proxy.
This too has its disadvantages, of course.
Brian
Senthil Sivakumar wrote:
> 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
>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>http://www.ietf.org/shadow.html
>> or
>>
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-s
ites.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
>>
>