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

From: "Elwyn Davies" <[email-masked]>
Date: Sun, 10 Oct 2004 10:16:04 +0200

Three points:
- The object of the draft was to summarize in one place all the problems
with NAT-PT rather than being yet another delta on previous work.  The
introduction notes that several of the points are indeed generic address
translation problems.  This doesn't make them any less relevant.

- The draft is specifically targeting the NAT-PT = SIIT + DNS-ALG solution
intended for use as a generic inter-cloud translator.  It is clear to me
that a 'cut down' form has a use as a legacy v4 'server adaptor' front end
where there is only one v4 address (or maybe a server cluster) on one side,
it only has to handle a pre-defined set of protocols, and it doesn't need a
DNS-ALG.  I think this should be the subject of a separate draft.

- The fundamental point is whether v6ops should still be continuing to
support a technology which will, if widely deployed, effectively stifle
innovation in v6 networks.  The need for applications to be aware that
NAT-PT exists effectively condemns v6 to be just v4 with larger addresses at
the application level. Is this what is wanted? Or should we really be trying
to put the architectural flexibility back into the Internet?

It would be useful to see Shivkumar's use cases so that they could be
considered for inclusion in the relevant transition analysis.  If people are
using NAT-PT in a particular way then we need to give them a workable
alternative before ditching NAT-PT.

Regards,
Elwyn

> -----Original Message-----
> From: Sham Chakravorty [mailto:[email-masked]] 
> Sent: 09 October 2004 18:35
> To: 'Brian E Carpenter'; 'Senthil Sivakumar'
> Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn 
> [HAL02:0S00:EXCH]
> Subject: 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: [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
> 
> 
> > 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: <[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-de
> precate-00.txt
> >http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de
> precate-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-s
ites.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: Tim Chown <[email-masked]>
Date: Sun, 10 Oct 2004 10:22:19 +0100

On Sun, Oct 10, 2004 at 10:16:04AM +0200, Elwyn Davies wrote:
>    considered  for  inclusion  in  the  relevant transition analysis.  If
>    people  are using NAT-PT in a particular way then we need to give them
>    a workable alternative before ditching NAT-PT.

I think this is key - the enterprise analysis in v6ops is happening now.
However,

	a) noone is commenting on the work

	b) at present, there is no cited case for NAT-PT in the solutions

I would thus strongly urge those who feel NAT-PT is important to state the
scenarios and cases where it should be recommended.   It is not at all clear
what those cases are at present.

Tim