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

From: "Bound, Jim" <[email-masked]>
Date: Sun, 10 Oct 2004 10:20:57 -0400

I agree with Tim below and key point Elwyn made regarding stifling IPv6
deployment.  NAT-PT should be deprecated and SIIT should be left as tool
to build translation when no other choice is possible.  

Lets also be clear about proxies to they are a performance nightmare
worse than NAT and will not solve the E2E security trust problem, when
IPsec is used, unless a decrypt engine is supported on the inbound and
encrypt engine on the outbound.  I can get into more technical details
if we must but I think that should be clear.  Proxies should also not be
elevated as a solution for IPv6 either I detest them as bas as NAT.

But, a use case is as follows:

Premise 1:
Embedded hardware system cannot be upgraded to be IPv6 capable, which
means can support a dual stack.  Reasons could be it uses ASIC IP stack
technology, or the download software or firmware simply cannot add a new
stack to create an IPv6 capable node.

Premise 2:
The network function or applicability to the user provided by the IPv4
legacy system is absolutely required for operations and must be
supported as legacy system.

Premise 3:
The new IPv6 capable systems simply have no more IPv4 addresses to
communicate with the legacy IPv4 system above.

Premise 4:
The new IPv6 capable systems network simply is unable to receive IPv4
packets from any legacy system.

/jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tim Chown
> Sent: Sunday, October 10, 2004 5:22 AM
> To: 'V6OPS'
> Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> 
> On Sun, Oct 10, 2004 at 10:16:04AM +0200, Elwyn Davies wrote:
> > 
> >    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.
> 
> 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
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 10 Oct 2004 15:53:22 -0400

the other important point of this discussion is if users have deployed
NAT-PT and why?  What we do not want is for NAT-PT to be used if it does
not have to be intially when the dual stacked consensus view of this WG
can be accomplished.  Also with NAT-PT the user has no chance to begin
adopting an E2E encrypted trust model using IPsec.   Also it will break
hopes of real  QOS from use of IPv6 QOS label and where all data is
encrypted as peeking at transport layer data is history once the payload
is encrypted E2E.  This is a very important discussion for the WG I
think is my input.
 
/jim

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Senthil Sivakumar
	Sent: Sunday, October 10, 2004 1:05 PM
	To: Elwyn Davies
	Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Cedric Aoun;
'V6OPS'
	Subject: RE: FW: I-D
ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt

	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 
		
		> 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 
		> 
		> [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: "Zhenyu Wu" <[email-masked]>
Date: Tue, 12 Oct 2004 09:43:33 +0800

>From: Soohong Daniel Park <[email-masked]>
>Reply-To: 
>To: Elwyn Davies <[email-masked]>,
'Pyda Srisuresh' <[email-masked]>, Senthil Sivakumar <[email-masked]>
>Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>Date:Tue, 12 Oct 2004 09:18:55 +0900
>
>RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txtIt was not the original
goal of NAT-PT to support all of the IPv6 features.

>It is one of possible transition mechanisms althouth there are several
>restrictions originated from the traditional NAT architecture.
>
>Nevertheless, I know several sites are using NAT-PT efficiently on their use
cases.

I agree. NAT-PT is only a transiton mechanism. We use it to solve one
scenario(NAT), at last we will use the IPv6 and its new features. I don't think
restictions such as E2E should be considered more.

>     Daniel (Soohong Daniel Park)
>     Mobile Platform Lab. Samsung Electronics. 
>
>  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Elwyn Davies
>  Sent: Tuesday, October 12, 2004 2:25 AM
>  To: 'Pyda Srisuresh'; Senthil Sivakumar
>  Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Cedric Aoun; 'V6OPS'
>  Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>
>
>  That NAT-PT may stifle innovation is not an assumption but a deduction.  As is
pointed out in the draft, NAT-PT cannot support all of the current features of v6
(eg flow labels, MIPv6) and is unlikely to support any new features.  If the
NAT-PT boxes operate autonomously (without something like STUN, midcom or nsis to
help), then all applications may well have to decide to just use the subset of
features supported by NAT-PT.  If they can detect that there is a NAT-PT box in
the way then special case code may be needed for destinations accessed through the
NAT-PT to limit the capabilities used.
>
>  However if a proxy is used, all the special casing can be confined to the proxy
- the original application should be able to work untramelled (i.e. as if working
on a pure native v6 network when communicating with v6 addresses - v4
functionality is unchanged).  Hence I think the situation as regards extra code is
exactly the reverse of what you say: applications operating with proxies can be
unaware and unchanged; applications operating through NAT-PT may need special case
coding.
>
>  The lack of compelling use cases for NAT-PT indicates that it isn't an
essential mechanism. Apart from a very limited set of cases dual-stack + tunelling
solves working across multiple realms.  We need to get the message out that NAT-PT
is not a good thing and that there are other, better solutions.  That is the way
to overcome resistance!
>  > From: Pyda Srisuresh [mailto:[email-masked]] 
>  > Sent: 11 October 2004 14:58 
>  > To: Senthil Sivakumar; Davies, Elwyn [HAL02:0S00:EXCH] 
>  > Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Aoun, Cedric 
>  > [ADC:7Q30:EXCH]; 'V6OPS' 
>  > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt 
>  > 
>  > 
>  > 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 
>  > 
>  > 
>  > --- Senthil Sivakumar <[email-masked]> wrote: 
>  > 
>  > 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. 
>  > > 
>  > > 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. 
>  > > 
>  > 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. 
>  > > 
>  > > 
>  > analysis.  If people 
>  > > >are using NAT-PT in a particular way then we need to give 
>  > them a workable 
>  > > >alternative before ditching NAT-PT. 
>  > > 
>  > > > > From: Sham Chakravorty 
>  > > > [<mailto:[email-masked]>mailto:[email-masked]] 
>  > > > > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn 
>  > > > > [HAL02:0S00:EXCH] 
>  > > > > Subject: RE: FW: I-D 
>  > > > > 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 
>  > [<mailto:[email-masked]>mailto:[email-masked]] On 
>  > > > Behalf 
>  > > > > Of Brian E Carpenter 
>  > > > > > The point I am trying to stress is deprecating this would 
>  > > > > leave us with no 
>  > > > > workable 
>  > > > > > 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. 
>  > > > > > attributing them to NAT-PT is not correct.  Those should be 
>  > > > > categorized 
>  > > > > > as generic address 
>  > > > > > translation issues. 
>  > > > > > 
>  > > > > >          ports) in packet payloads or which apply integrity 
>  > > > > mechanisms 
>  > > > > >       *  Requirement for applications to use keep alive 
>  > > > > mechanisms to 
>  > > > > >          workaround connectivity issues caused by premature 
>  > > > > NAT-PT state 
>  > > > > >        *  Inability to redirect packet fragments after the 
>  > > > > first with 
>  > > > > >    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 
>  > > > > >          address retention between sessions.  The user 
>  > > > > traffic will be 
>  > > > > >          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 
>  > > > > >       *  Creation of a DOS threat relating to exhaustion of 
>  > > > > memory and 
>  > > > > > 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 
>  > > > > > 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 
>  > > > > > 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 
>  > > > > > 
>  > > > > >> 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 
>  > > > > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt 
>  > > > > >> 
>  > > > > >>         Title           : Reasons to Deprecate NAT-PT 
>  > > > > >>    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 
>  > <<http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-d 
>  > e>http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de 
>  > > 
>  > > > 
>  > > > > precate-00.txt 
>  > > > > 
>  > ><http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-d 
>  > e>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://w 
>  ww1.ietf.org/mailman/listinfo/I-D-announce 
>  > > 
>  > > > 
>  > > > > >> Internet-Drafts are also available by anonymous FTP. Login 
>  > > > > with the 
>  > > > > >> username 
>  > > > > >> "anonymous" and a password of your e-mail address. After 
>  > > > > logging in, 
>  > > > > >>         "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.h 
>  > tml>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 
>  > > > >> 
>  > > > >> 
>  > > > >> 
>  > > > >> 
>  > > > >> NOTE:   The mail server at ietf.org can return the document in 
>  > > ATTACHMENT part 2 application/msword name=nat-pt-scenario.doc; 
>  > x-mac-type=42494E41; x-mac-creator=4D535744 
>  > 
>  > 
>  > 
>  > ===== 
>  > 
>  > 
>  >

---

From: Senthil Sivakumar <[email-masked]>
Date: Tue, 12 Oct 2004 10:18:54 -0700

The deployments that I am aware of use the legacy apps like FTP, Telnet and 
HTTP and
they have not modified their apps to work with NAT-PT. If flow labels and 
MIPv6 and
end-to-end security are important to them they would not be using NAT-PT.
That is why we have an applicability statement suggesting where NAT-PT 
could be used.
I am pretty sure any presented use cases can be shrugged off by saying not 
compelling enough
and suggesting alternatives. As people pointed out proxies are not a viable 
solution in all cases.

Thanks
Senthil

At 07:24 PM 10/11/2004 +0200, Elwyn Davies wrote:

>That NAT-PT may stifle innovation is not an assumption but a 
>deduction.  As is pointed out in the draft, NAT-PT cannot support all of 
>the current features of v6 (eg flow labels, MIPv6) and is unlikely to 
>support any new features.  If the NAT-PT boxes operate autonomously 
>(without something like STUN, midcom or nsis to help), then all 
>applications may well have to decide to just use the subset of features 
>supported by NAT-PT.  If they can detect that there is a NAT-PT box in the 
>way then special case code may be needed for destinations accessed through 
>the NAT-PT to limit the capabilities used.
>
>However if a proxy is used, all the special casing can be confined to the 
>proxy - the original application should be able to work untramelled (i.e. 
>as if working on a pure native v6 network when communicating with v6 
>addresses - v4 functionality is unchanged).  Hence I think the situation 
>as regards extra code is exactly the reverse of what you say: applications 
>operating with proxies can be unaware and unchanged; applications 
>operating through NAT-PT may need special case coding.
>
>essential mechanism. Apart from a very limited set of cases dual-stack + 
>tunelling solves working across multiple realms.  We need to get the 
>message out that NAT-PT is not a good thing and that there are other, 
>better solutions.  That is the way to overcome resistance!
>
>Regards,
>Elwyn
>
> > From: Pyda Srisuresh 
> [<mailto:[email-masked]>mailto:[email-masked]]
> [<<mailto:[email-masked]>mailto:[email-masked]>mailto:[email-masked]]
> [<<mailto:[email-masked]>mailto:[email-masked]>mailto:[email-masked]] 
> On
> > > > Behalf
> > > > > Of Brian E Carpenter
> <<<http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-d>http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-d 
>
> > 
> e><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-d>http://w 
> ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-d
> > e><http://w>http://w
> <<https://www1.ietf.org/mailman/listinfo/I-D-announce>https://www1.ietf.org/mailman/listinfo/I-D-announce>https://w 
>
> <<<http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.h 
>
> > tml><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-sites.txt><ftp://ftp.ietf.org/>ftp://ftp.ietf.org/
> > >
> > > >
> > > >ietf/1shadow-s
> > > >ites.txt
> > > > >>
> > > > >>
> > > > >>
> > > > >>

---

From: "Zhenyu Wu" <[email-masked]>
Date: Fri, 15 Oct 2004 09:59:41 +0800

We are all talking about wheather the NAT-PT should be chosen. But there are lots
of transimisms besides NAT-PT, do you think they are all helpful to a special
circumstance? A special transition mechanism solves a special condition, if there
a mechanism that can replace NAT-PT much better, we can consider to deprecate it.

Best,

>From: Senthil Sivakumar <[email-masked]>
>Reply-To: 
>To: Pekka Savola <[email-masked]>
>Date:Thu, 14 Oct 2004 15:09:08 -0700
>
>At 08:12 PM 10/14/2004 +0300, Pekka Savola wrote:
> >On Tue, 12 Oct 2004, Pyda Srisuresh wrote:
> > > >                     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.
> > >
> > > [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.
> >
> >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".
> 
> 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.
> 
> 
> 
> >NAT-PT like translation needs to be the last choice, not to dictate or
> >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
> 
> > > > I have the feeling that most typical applications applications already
> > > > support proxies or have inherent support for middleboxes (e.g., http,
> > > > 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.
> >
> >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.
> >
> >--
> >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: "Zhenyu Wu" <[email-masked]>
Date: Fri, 15 Oct 2004 10:01:57 +0800

It just goes to show that the IETF can only offer transition mechanisms, but not
mandate one. When the choices are comprehensive, the customers will pick the one
that best suits their environment.

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
We are all talking about wheather the NAT-PT should be chosen. But there are lots
of transimisms besides NAT-PT, do you think they are all helpful to a special
circumstance? A special transition mechanism solves a special condition, if there
a mechanism that can replace NAT-PT much better, we can consider to deprecate it.

Best,