[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
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
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
>>
>