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

From: Senthil Sivakumar <[email-masked]>
Date: Sun, 10 Oct 2004 10:05:20 -0700

At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote:

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

I am fine with summarizing the issues in one draft. But the draft points 
out those as reasons to deprecate
which is what I am pointing out.

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

While I agree with you the cut-down solution does not need a DNS-ALG, I 
don't think it has to handle a
specific set of protocols. I could still be a generic purpose translator 
for facilitating transition. I am attaching
a document which was one of the use case scenario we are aware of.

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

I am not understanding why you say applications have to aware of existence 
of NAT-PT.

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

Exactly. We should not prematurely deprecate the solution without an 
alternative in place.

Thnks
Senthil

>Regards,
>Elwyn
>
> > -----Original Message-----
> > From: Sham Chakravorty 
> [<mailto:[email-masked]>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]>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>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>http://w 
> ww.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>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>http://www.ietf.org/shadow.html 
>
> > >> or
> > >>
> > 
> <<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>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: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Oct 2004 13:43:41 +0200

> 1. Renumber all private IPv4 addressing to be compatible;
> 2. Implement a proxy service at the ingress/egress of each private network;
> 3. Leave the private IPv4 interface unchanged and implement a new IPv6 interface (dualstack)
> on end-systems or
> 4. Leave the private IPv4 interface unchanged and implement double Network Address
> Translation (NAT).
> Of these options, the first was considered un-realistic. The second can be unscalable for
> ingress flows and imposes topology restrictions. 

Exactly the same concerns arise for NAT-PT, and it isn't at all clear that
scaling is any worse in the case of a proxy. Highly scaleable proxies
are common today.

> The third may involve applications on legacy
> systems that cannot migrate to a dual stack IPv4/IPv6 environment.

Nevertheless, it is the preferred strategy whenever it can be applied -
what we are talking about is how to catch the cases where this is simply
impossible.

> As a result, the XXXX
> architecture is based on the fourth option of double-NAT by implementing NAT-PT. This does not prevent the deployment of the third option where feasible. ………

But you have another option that will allow legacy to speak to legacy -
an IPv4-in-IPv6 tunnel. That's a no-brainer that we haven't really
discussed much, and as far as I can see it can do everything double-NAT-PT
can do.

    Brian

Senthil Sivakumar wrote:
>> - 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.
> 
> 
>> 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?
> 
> 
> I am not understanding why you say applications have to aware of 
> existence of NAT-PT.
> 
> 
>> 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.
> 
> 
>> > [<mailto:[email-masked]>mailto:[email-masked]] 
>> On Behalf
>> > Of Brian E Carpenter
>> >>         "FILE 
>> /internet-drafts/draft-aoun-v6ops-natpt-deprecate-00.txt".
>> >>

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 11 Oct 2004 06:57:42 -0700 (PDT)

Folks,

As Senthil points out, the assumption that NAT-PT deployment will stifle
innovation in v6 seems flawed. NAT-PT is a transition mechanism which is
essential for wider V6 deployment. Without NAT-PT, you will see bigger
resistance to deploying V6 . You need NAT-PT for legacy applications (ex:
e-mail, ftp) to work as is across V4 and V6 realms. No change to end-hosts or
applications. This is the attraction of NAT-PT. This is not the same as the
proxy solution that will require applications to be changed/recompiled. 

cheers,
suresh

> ATTACHMENT part 2 application/msword name=nat-pt-scenario.doc;
x-mac-type=42494E41; x-mac-creator=4D535744

=====

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Oct 2004 08:27:29 +0300 (EEST)

This is a fundamental deployment argument than one about NAT-PT, but 
nevertheless I guess this should be said..

On Mon, 11 Oct 2004, Pyda Srisuresh wrote:
> e-mail, ftp) to work as is across V4 and V6 realms. 

This ('NAT-PT.. essential for wider V6 deployment') may or may not be
true if you assume that there will be strong incentives for deploying
IPv6-only systems which need to talk to a vast majority of v4 systems
in the near future.  If that's not the case, it's certainly not
correct -- you can deploy IPv6 as dual-stack without any need for
NAT-PT.  And dual-stack is definitely the simplest way to deploy IPv6.

> No change to end-hosts or

You don't need to change end-hosts or applications (in the manner you
probably mean) if you deploy dual-stack.  If you deploy v6-only, you 
need to change end-hosts MORE than with dual-stack.

I have the feeling that most typical applications applications already
support proxies or have inherent support for middleboxes (e.g., http,
smtp, dns, ftp).  Changes are only necessary if one would like to
pursue a generic 'SOCKS' -like approach for IPv6 deployment, but that
has not gotten much deployment AFAICS.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 12 Oct 2004 07:02:21 -0700 (PDT)

> nevertheless I guess this should be said..
[suresh] Thanks. Hence the argument for not deprecating it.

> in the near future. 

[suresh] Not sure what you meant. I am not making any assumptions about the
size of deployments, given the early stage yet for V6. I am merely refering to
the likely scenario of V6-only and V4-only nodes. 

>                     If that's not the case, it's certainly not

[suresh] You might refer comments from Steve Klynsma & Jim Bound - about
difficulties the defence dept faces to transition to dual stacks. It just goes
to show that the IETF can only offer transition mechanims, but not mandate one.
When the choices are comprehensive, the customers will pick the one that best
suits their environment.

> need to change end-hosts MORE than with dual-stack.
[suresh] Please see my comment above.

> smtp, dns, ftp).
 
[suresh] Disagree with your comment about proxies. What did you mean by
"inherent support for middleboxes"? Middleboxes refer to many things including
proxies, NATs and NAT-PTs.
 
>                  Changes are only necessary if one would like to

[suresh] I cant quite parse what you are saying here. Please see my earlier
comments about deployment scenarios and need to have a comprehensive choices
for users to transition to. It would be a mistake for the IETF to deprecate
NAT-PT. As vendors had done in the past, vendors will deploy solutions that
fits customer needs, irrespective of what the IETF does. It would help if the
IETF was not oblivion to real-world customer needs. 

regards,
suresh

=====

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Oct 2004 20:12:57 +0300 (EEST)

> When the choices are comprehensive, the customers will pick the one that best

Such networks are likely to require something like tunneling or
translation, yes.  But the real problem with NAT-PT is that all the
people who don't need it, and shouldn't need it were they to deploy
IPv6 as dual-stack, want to try to fit it in their deployment plans
because, "well, it exists.. so there must be some use for it for us
here".

NAT-PT like translation needs to be the last choice, not to dictate or
give inappropriate direction to the deployment.

> proxies, NATs and NAT-PTs.

Web proxies are common.  FTP proxies are common.  Mail submission (a
function of SMTP) is submitted to a 'proxy'.  DNS lookups are usually
done from a recursive name server.

Lots of protocols are already using explicit middleboxes such as 
recursive DNS servers, web proxies, etc. -- that's a good thing.  
Leveraging these for transition makes great deal of sense.

NAT-PT (and NAT) try to act as a middlebox transparently, without the
consent of the host or the application.  This causes a lot of
problems.  Explicit middleboxes, above, do not have this problem.

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 14 Oct 2004 12:18:27 -0700 (PDT)

> give inappropriate direction to the deployment.
[suresh] I agree. My point is simply that deprecating or not identifying NAT-PT
as a solution in the scenarios it really is the only option would be a
diservice to the transition strategy and wouldnt be the right thing to do for
the IETF. 

> Web proxies are common.  FTP proxies are common.  Mail submission (a

[Suresh] Web proxies are relatively more common. Even these are not universal.
Certainly not with the customers I had talked to. As for FTP proxies, these are
relatively rare, in my experience.

> done from a recursive name server.
[Suresh] So, how does that eliminate the need for NAT-PT?

> recursive DNS servers, web proxies, etc. -- that's a good thing.

[suresh] Hmm... I wouldnt call the DNS servers middleboxes. They simply provide
a namelookup service. Middleboxes are assumed to be in the end-2-end path and
perform packet forwarding.
  
> Leveraging these for transition makes great deal of sense.

[Suresh] As I said earlier, if a customer has the proxy servers for all the
applications he uses, that is not an issue.
 
> problems.  Explicit middleboxes, above, do not have this problem.

[suresh] I understand what you say. Transparancy provided by NAT-PT is
desirable in certain scenarios as was described in 2766. It is not evenryone's
cup of tea. Midcom extension to such a middlebox can help more applications use
the NAT-PT middlebox effectively. 

regards,
suresh

=====

---

From: Senthil Sivakumar <[email-masked]>
Date: Thu, 14 Oct 2004 15:09:08 -0700

>because, "well, it exists.. so there must be some use for it for us

We all agree that NAT-PT should not be used when it does not have to be
and I think there are enough documents out there to describe all the
issues with NAT-PT.  But we should not discount the fact that there
are use case scenarios and this is a real life use case scenarios.

>give inappropriate direction to the deployment.

Nevertheless, it has to be a choice. Most of the people agree that it is the
last choice.

Senthil

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 15 Oct 2004 09:42:12 +0900

I am really not sure why you insist all the people don't need it. 
It's so dangerous assertion. Are you trying to search for 100% 
completed transition tool ? As you know, it is not possible.
Again, NAT-PT is one of transition mechanisms. 

     Daniel (Soohong Daniel Park)
     Mobile Platform Lab. Samsung Electronics.

> [mailto:[email-masked]]On Behalf Of Pekka Savola
> Sent: Friday, October 15, 2004 2:13 AM
> To: Pyda Srisuresh
> Cc: Senthil Sivakumar; Elwyn Davies; 'Sham Chakravorty'; 'Brian E 
> Carpenter'; Cedric Aoun; 'V6OPS'

---

From: Tim Chown <[email-masked]>
Date: Fri, 15 Oct 2004 14:30:38 +0100

> discussed much, and as far as I can see it can do everything double-NAT-PT

As an aside, I think this is being covered in the zero-config tunnelling
discussions now, which I feel is important (i.e. automatic IPv4-in-IPv6
tunnelling).

Tim

---

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

> discussions now, which I feel is important (i.e. automatic IPv4-in-IPv6

I was actually thinking of a configured router-to-router 4-in-6
tunnel as an alternative to double-NAT-PT, but of course an automatic
one would be even nicer.

    Brian