[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
I am really not sure why you insist all the people don't need it.
It's so dangerous assertion. Are you trying to search for 100%
completed transition tool ? As you know, it is not possible.
Again, NAT-PT is one of transition mechanisms.
Daniel (Soohong Daniel Park)
Mobile Platform Lab. Samsung Electronics.
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Pekka Savola
> Sent: Friday, October 15, 2004 2:13 AM
> To: Pyda Srisuresh
> Cc: Senthil Sivakumar; Elwyn Davies; 'Sham Chakravorty'; 'Brian E
> Carpenter'; Cedric Aoun; 'V6OPS'
> Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>
>
> 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".
>
> NAT-PT like translation needs to be the last choice, not to dictate or
> give inappropriate direction to the deployment.
>
> > > 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
>
>
>