[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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-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
> > > >> 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://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:
> > >> 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
=====