Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt

From: "Elwyn Davies" <[email-masked]>
Date: Mon, 11 Oct 2004 19:24:33 +0200

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:[email-masked]] 
> 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 <[email-masked]> 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:[email-masked]>mailto:[email-masked]]
> > > > 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: [email-masked]
> > > > 
> [<mailto:[email-masked]>mailto:[email-masked]] 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: <[email-masked]>
> > > > >> Reply-To: <[email-masked]>
> > > > >> Date: Tue, 21 Sep 2004 21:38:33 +0200
> > > > >> To: <[email-masked]>
> > > > >> 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
> > > > >> [email-masked] 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:
> > > >>         [email-masked].
> > > >> 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
> 
> 
> 
> =====
> 
> 
>

---

From: Soohong Daniel Park <[email-masked]>
Date: Tue, 12 Oct 2004 09:18:55 +0900

RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txtIt was not the original goal of NAT-PT to support all of the IPv6 features.
It is one of possible transition mechanisms althouth there are several
restrictions originated from the traditional NAT architecture.

Nevertheless, I know several sites are using NAT-PT efficiently on their use cases.

     Daniel (Soohong Daniel Park)
     Mobile Platform Lab. Samsung Electronics. 

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Elwyn Davies
  Sent: Tuesday, October 12, 2004 2:25 AM
  To: 'Pyda Srisuresh'; Senthil Sivakumar
  Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Cedric Aoun; 'V6OPS'
  Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt

  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

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 12 Oct 2004 06:38:46 -0700 (PDT)

> 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.

> 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.

> 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.
> Elwyn

regards,
suresh

=====

---

From: Tim Chown <[email-masked]>
Date: Fri, 15 Oct 2004 14:46:23 +0100

>  Nevertheless,  I  know  several  sites are using NAT-PT efficiently on

It would be interesting, with the enterprise analysis in mind, to know
why these sites used NAT-PT, and what they could not solve in other ways.

We used to run NAT-PT, but no longer do.

As Pekka points out, we should also consider how IPv4 and IPv6 will be
adopted.  IPv4 may remain the protocol to access legacy apps (like web,
mail, ftp).  But these are also the ones that lend themselves to natural 
proxying (and sure FTP proxies are rare, but so are NAT-PT boxes :).
IPv6 may become more popular for specific new applications, which do not
require access to IPv4 services, as Pekka is hinting.

Suresh wrote:
>  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
>  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.

Proxies can be deployed transparently.  SMTP naturally so, Web caches also,
there doesn't necessarily have to be any client side alterations.

Tim

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Wed, 20 Oct 2004 11:37:27 +0300

Hello,

in Asia there seem to be emerging _large_ IPv6 only networks that may
need some connectivity to the IPv4 Internet. Example of these is for
instance is CNGI. They have been extensively looking for a NAT-PT type
solution and are considering to use NAT-PT. I think we should have some
sort of proposal what to do if we decide that NAT-PT is not the way to
go. 

I wish the people that are involved in these projects would speak up and
explain their requirements.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Oct 2004 10:59:00 +0200

Hi,

Agree, is better to heard the people that is doing that.

Probably I'm one of those ;-)

We are deploying networks for 5.000 IPv6 sites (not a joke !). At the time
being dual stack, but the aim in a short term is to disable IPv4 from the
access and core network.

As today we need still dual stack in the hosts because there may be some
specific applications that could still be only IPv4, it seems to us that
NAT-PT is a bad solution, as probably will fail for those applications,
unless they are the typical HTTP applications, and in that case, we don't
need NAT-PT (it can be done with a much more simple proxy !).

So looking for simplicity, we use a proxy for all the "old" IPv4 traffic, so
in our network (core and access) we only see IPv6 as much as possible.

Alternatively for those applications that are still not ported, we use an
automatic 4in6 tunneling mechanism from the "client" to the other host (if
is located inside of our network), or from the client to the "border" of our
network (the point where we connect to Internet), if the other host is
located outside our network.

DSTM may be a good candidate.

I only see NAT-PT useful if the host can't be upgraded to IPv6 (dual stack
actually) and the translation is simple and don't break anything, which may
be easy because old IPv4-only devices should not use non-translatable header
fields, BUT may be not the case also ;-)

A very convenient alternative could be that the 4in6 tunneling for those
devices is done by the border device (IPv6 router of the network ?). I think
this will alleviate any need for NAT-PT. I'm missing any possible scenario
where this couldn't work ?

Regards,
Jordi

> De: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
> Responder a: [email-masked]
> Fecha: Wed, 20 Oct 2004 11:37:27 +0300
> Para: "'V6OPS'" <[email-masked]>
> Asunto: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> 
> Hello,
> 

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Oct 2004 16:08:28 +0200

Jordi, are you using ayiya for this deployment? If so, what's
your experience?

    Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Oct 2004 16:30:23 +0200

Hi Brian,

No at the time being. May be in the future, if there are interoperable
implementations ;-)

But my feeling is that it can be done in a much more simply way. Actually in
our case all the users in the 5.000 sites are already "authenticated" so
that will fall in the scope of the zeroconfiguration tunneling protocol that
has been submitted yesterday to the ID editor. I will upload it somewhere
else in case is not published already.

Regards,
Jordi

> De: Brian E Carpenter <[email-masked]>
> Organización: IBM
> Fecha: Wed, 20 Oct 2004 16:08:28 +0200
> Para: [email-masked]
> CC: [email-masked]
> Asunto: Re: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> 
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be aware
>> that any disclosure, copying, distribution or use of the contents of this
>> information, including attached files, is prohibited.
>> 
>> 
>> 
>> 
> 
>

---

From: "Liu Min" <[email-masked]>
Date: Thu, 21 Oct 2004 11:12:29 +0800

As far as I know, there will be a specific project to research and develop
high performance IPv4/IPv6 translation gateway in CNGI. Because there are
fewer IPv6 applications and resources than IPv4 in the current Internet, it
is difficult to persuade people to use IPv6.Most IPv6 users want to access
IPv4 resources. In order to spread IPv6, we must tell the users that they
can access all IPv4 resources. In addition, they can do what they can not do
by IPv4, such as p2p applications (Many people only have private IPv4
addresses). 

Best Wishes,

Liu Min
 
Institute of Computing Technology
Chinese Academy of Sciences
Tel: (86-10) 6256 5533-9240 
E-mail: [email-masked]

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Soininen Jonne (Nokia-NET/Helsinki)
> Sent: Wednesday, October 20, 2004 4:37 PM
> To: 'V6OPS'
> Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> 
> Hello,
> 
> > >  Nevertheless,  I  know  several  sites are using NAT-PT efficiently
on
> > >  their use cases.
> > >  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
changed/recompiled.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Oct 2004 07:24:52 +0300 (EEST)

> by IPv4, such as p2p applications (Many people only have private IPv4

What I don't understand in your comment is why you implicitly assume
that the IPv6 users would not have IPv4 access at all, and therefore
their IPv6 access must be able to react all the IPv4 services.

AFAICS, there is nothing stopping from deploying IPv4 w/ private
addresses alongside with IPv6, and IPv6 could even be used dominantly
in the network (if that's felt to be desirable for a political
reasons, or to gain experience) if the typically used services such as
HTTP, SMTP, DNS, etc. could be proxied by ALGs at the border.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Gert Doering <[email-masked]>
Date: Thu, 21 Oct 2004 08:33:43 +0200

Hi,

> HTTP, SMTP, DNS, etc. could be proxied by ALGs at the border.

I'm not sure if this is *better* than IPv6-only with NAT-PT at the border.

If the network is large enough, the effort for maintaining IPv4 addresses
and a dual-stack network infrastructure can be significantly higher than
for an IPv6-only network.

IPv4 with private addresses uses NAT, IPv6->IPv4 uses NAT-PT - both are
evil, can't say one of them is "worse".

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  66629  (65398)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Oct 2004 10:51:57 +0300 (EEST)

> evil, can't say one of them is "worse".

That's a valid argument, though I'd be interested in hearing more
detailed analysis on the actual amount of added maintenance due to
[private] v4.  [I also argue that you'll have to waste more energy
trying to get things to work completely in a v6-only environment than
just running v4 where needed.]

However, my main argument in this kind of situation is that we might
not want to proliferate the v4 NAT behaviour to v6->v4 NAT behaviour.  
As soon as we start doing NAT-PT people that are using IPv6-ony start
expecting that their applications will work through the NAT-PT.  For
example, their peer-to-peer application.  This results in either a LOT 
of code in NAT-PT, and/or a lot of code in the applications.

(This is discussed a bit in the nat-pt deprecation draft.)

And what I'd like to avoid is requiring IPv6 applications to deal with
NATs.  But if we do NAT-PT and the like, that seems inevitable and a
major benefit of IPv6 applications goes away.

Hence, I think there is some weight in trying to keep IPv6 free of
generic translators such as NAT-PT, or IPv6 NAT which would break some
applications.  (Application proxies are already designed with those
applications in mind, so those are OK.)