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!
Regards,
Elwyn
> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@yahoo.com]
> 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 <ssenthil@cisco.com> wrote:
>
> > 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:schakra@mitre.org>mailto:schakra@mitre.org]
> > > > 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: owner-v6ops@ops.ietf.org
> > > >
> [<mailto:owner-v6ops@ops.ietf.org>mailto:owner-v6ops@ops.ietf.org] 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: <Internet-Drafts@ietf.org>
> > > > >> Reply-To: <internet-drafts@ietf.org>
> > > > >> Date: Tue, 21 Sep 2004 21:38:33 +0200
> > > > >> To: <i-d-announce@ietf.org>
> > > > >> 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-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
> > > > >> i-d-announce-request@ietf.org 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
> >
> > >
> > > > >> 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.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
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Internet-Drafts can also be obtained by e-mail.
> > > >>
> > > >> Send a message to:
> > > >> mailserv@ietf.org.
> > > >> 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
> > > >>
> > > >
> > >
> > >
> >
>
> > ATTACHMENT part 2 application/msword name=nat-pt-scenario.doc;
> x-mac-type=42494E41; x-mac-creator=4D535744
>
>
>
> =====
>
>
>