[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
--- Elwyn Davies <elwynd@nortelnetworks.com> 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.
>
[suresh] As Soohong and others pointed out, supporting all V6 features was not
the goal of NAT-PT. Making large no. of legacy apps work between V4 and V6
realms was the goal of NAT-PT. I..e, be a transition tool between v4 legacy and
V6. Large number of commonly used apps work as is, with no change. But, not all
of them. This has been a known limitation with NATs in general, NAT-PT
included.
> 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.
[Suresh] If proxies are used in your enterprise and your apps (TCP and UDP)
are all redone to work through proxies, you can be proxy happy. But, that is
not a universal case. There are several setups where there is no proxy support
and apps are not redone to be proxy-friendly (i.e.,apps do not use proxy).
This is the scenario that NAT-PT addresses.
>
> 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!
[suresh] You miles may vary on the transition mechanims you choose to go with.
NAT-PT is a transition mechanism that addresses real scenarios not addressed by
others. Denying the real scenarios or deprecating NAT-PT is not a smart move to
transition, IMHO.
>
> Regards,
> Elwyn
>
regards,
suresh
> > -----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
> >
> >
> >
> > =====
> >
> >
> >
>
=====