[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> -----Original Message-----
> From: Sham Chakravorty [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] 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
> 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
> >> 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
> >> 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:
>>         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: nat-pt-scenario.doc
Description: MS-Word document