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

["Zhenyu Wu" <y030729@njupt.edu.cn>]

It just goes to show that the IETF can only offer transition mechanisms, but not
mandate one. When the choices are comprehensive, the customers will pick the one
that best suits their environment.

Disagree with your comment about proxies. What did you mean by "inherent support
for middleboxes"? Middleboxes refer to many things including proxies, NATs and
NAT-PTs
We are all talking about wheather the NAT-PT should be chosen. But there are lots
of transimisms besides NAT-PT, do you think they are all helpful to a special
circumstance? A special transition mechanism solves a special condition, if there
a mechanism that can replace NAT-PT much better, we can consider to deprecate it.

Best,




>From: Senthil Sivakumar <ssenthil@cisco.com>
>Reply-To: 
>To: Pekka Savola <pekkas@netcore.fi>
>Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>Date:Thu, 14 Oct 2004 15:09:08 -0700
>
>At 08:12 PM 10/14/2004 +0300, Pekka Savola wrote:
> >On Tue, 12 Oct 2004, Pyda Srisuresh wrote:
> > > >                     If that's not the case, it's certainly not
> > > > correct -- you can deploy IPv6 as dual-stack without any need for
> > > > NAT-PT.  And dual-stack is definitely the simplest way to deploy IPv6.
> > >
> > > [suresh] You might refer comments from Steve Klynsma & Jim Bound - about
> > > difficulties the defence dept faces to transition to dual stacks. It 
> > just goes
> > > to show that the IETF can only offer transition mechanims, but not 
> > mandate one.
> > > When the choices are comprehensive, the customers will pick the one 
> > that best
> > > suits their environment.
> >
> >Such networks are likely to require something like tunneling or
> >translation, yes.  But the real problem with NAT-PT is that all the
> >people who don't need it, and shouldn't need it were they to deploy
> >IPv6 as dual-stack, want to try to fit it in their deployment plans
> >because, "well, it exists.. so there must be some use for it for us
> >here".
> 
> We all agree that NAT-PT should not be used when it does not have to be
> and I think there are enough documents out there to describe all the
> issues with NAT-PT.  But we should not discount the fact that there
> are use case scenarios and this is a real life use case scenarios.
> 
> 
> 
> >NAT-PT like translation needs to be the last choice, not to dictate or
> >give inappropriate direction to the deployment.
> 
> Nevertheless, it has to be a choice. Most of the people agree that it is the
> last choice.
> 
> Senthil
> 
> > > > I have the feeling that most typical applications applications already
> > > > support proxies or have inherent support for middleboxes (e.g., http,
> > > > smtp, dns, ftp).
> > >
> > > [suresh] Disagree with your comment about proxies. What did you mean by
> > > "inherent support for middleboxes"? Middleboxes refer to many things 
> > including
> > > proxies, NATs and NAT-PTs.
> >
> >Web proxies are common.  FTP proxies are common.  Mail submission (a
> >function of SMTP) is submitted to a 'proxy'.  DNS lookups are usually
> >done from a recursive name server.
> >
> >Lots of protocols are already using explicit middleboxes such as
> >recursive DNS servers, web proxies, etc. -- that's a good thing.
> >Leveraging these for transition makes great deal of sense.
> >
> >NAT-PT (and NAT) try to act as a middlebox transparently, without the
> >consent of the host or the application.  This causes a lot of
> >problems.  Explicit middleboxes, above, do not have this problem.
> >
> >--
> >Pekka Savola                 "You each name yourselves king, yet the
> >Netcore Oy                    kingdom bleeds."
> >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
>