Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt

From: Senthil Sivakumar <[email-masked]>
Date: Fri, 08 Oct 2004 16:17:25 -0700

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: <[email-masked]>
>Reply-To: <[email-masked]>
>Date: Tue, 21 Sep 2004 21:38:33 +0200
>To: <[email-masked]>
>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
>[email-masked] 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-sites.txt 
>
>
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>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
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Oct 2004 15:09:31 +0200

> The point I am trying to stress is deprecating this would leave us with no workable

But there is a workable alternative, which is an application level proxy.
This too has its disadvantages, of course.

     Brian

Senthil Sivakumar wrote:
> of NAT-PT and DNS ALG, which is a good thing. However, most of the 
> issues mentioned
> attributing them to NAT-PT is not correct.  Those should be categorized 
> as generic address
> translation issues.
> 
> Regarding the conclusion, I don't agree with the fact that only 
> applicable scenario
> 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
> 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
> The point I am trying to stress is deprecating this would leave us with 
> no workable
>> 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
>> [email-masked] with the word unsubscribe in the body of 
>> the message.

---

From: Tim Chown <[email-masked]>
Date: Sat, 9 Oct 2004 15:17:31 +0100

> This too has its disadvantages, of course.

I agree with Brian.

Our experience is that translation is only needed for "legacy" apps.  The
large majority of such legacy apps have a ALG capability (web, mail, news,
ftp, sip, ...).  

There are also TCP-relays...

What is the specific application scenario that you have?

Tim

---

From: "Sham Chakravorty" <[email-masked]>
Date: Sat, 9 Oct 2004 13:34:32 -0400

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: [email-masked] [mailto:[email-masked]] 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

workable

     Brian

>> 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

>> <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-s
ites.txt