[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
- To: ssenthil@cisco.com
- Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
- From: "Zhenyu Wu" <y030729@njupt.edu.cn>
- Date: Fri, 15 Oct 2004 09:59:41 +0800
- Cc: Pyda@njupt.edu.cn, Srisuresh@njupt.edu.cn, srisuresh@yahoo.com, Elwyn@njupt.edu.cn, Davies@njupt.edu.cn, elwynd@nortelnetworks.com, schakra@mitre.org, brc@zurich.ibm.com, Cedric@njupt.edu.cn, Aoun@njupt.edu.cn, cedric.aoun@nortelnetworks.com, v6ops@ops.ietf.org
- Reply-to: "Zhenyu Wu" <y030729@njupt.edu.cn>
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
>
>
>