Subject: RE: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt

From: "Senthil Sivakumar \(ssenthil\)" <[email-masked]>
Date: Tue, 10 May 2005 14:26:24 -0700

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-masked]>
    * 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
    * Cc: V6OPS <[email-masked]>, "Elwyn Davies"
<[email-masked]>
    * In-reply-to: <[email-masked]>
    * References: <[email-masked]>

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
>
>     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 
>     or 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: Elwyn Davies <[email-masked]>
Date: Wed, 11 May 2005 01:01:25 +0100

Some of the issues are indeed generic problems with (v6-v4) address 
translation.  It is not a matter of 'attributing' the issues to NAT-PT.  
If you implement/deploy NAT-PT, these issues *will* arise - this is what 
the draft is highlighting.  As Alain was pointing out and seems to be 
part of your point, some of these issues will affect *any* v4-v6 
translation mechanisms.  We can mention which issues are implicated in 
an updated version of the draft if the list does not object, as I have 
suggested yesterday.  I hope this will satisfy your point also.  It will 
certainly be useful for anybody authoring alternative mechanisms to be 
aware of the genric issues in one place, IMO.

It should also be noted that this is the only draft that has addressed 
the 'known issues with address translation' in the context of v4-v6 
translation as opposed to v4-v4 NAT: there are subtle differences
as Pekka pointed out so we need to cover them here, rather than by 
reference.

Regards,
Elwyn

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 12 May 2005 09:58:09 -0700 (PDT)

folks,

We have a new mailing list [email-masked] to discuss issues that need
cleaning up in NAT-PT. Please join the list, if you have an interest in
pursuing this effort. Thanks.

cheers,
suresh

---

From: Tim Chown <[email-masked]>
Date: Thu, 12 May 2005 21:40:03 +0100

> pursuing this effort. Thanks.

For info, if you try to join you get:

"Your message to [email-masked] has NOT been sent, please note that the
 address for this list is [email-masked].  You should use this
 address to send mail to this list.
 
 You will need to resend your message to: [email-masked]
 
 Note:  This address contains people external to Cisco Systems, Inc. so
 do not send anything to this list that should be treated as confidential
 Cisco information."

-- 
Tim/::1

---

From: Alain Durand <[email-masked]>
Date: Thu, 12 May 2005 14:43:48 -0700

Could you please elaborate on what you are trying to accomplish?

      - Alain.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 27 May 2005 16:07:38 -0700

> Could you please elaborate on what you are trying to accomplish?

Fixing the concerns that caused people to want the existing doc moved to
experimental. 

Tony