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

[Pyda Srisuresh <srisuresh@yahoo.com>]

--- Pekka Savola <pekkas@netcore.fi> 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".
> 
> NAT-PT like translation needs to be the last choice, not to dictate or
> give inappropriate direction to the deployment.
> 
[suresh] I agree. My point is simply that deprecating or not identifying NAT-PT
as a solution in the scenarios it really is the only option would be a
diservice to the transition strategy and wouldnt be the right thing to do for
the IETF. 

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

[Suresh] Web proxies are relatively more common. Even these are not universal.
Certainly not with the customers I had talked to. As for FTP proxies, these are
relatively rare, in my experience.

> function of SMTP) is submitted to a 'proxy'.  DNS lookups are usually
> done from a recursive name server.
> 
[Suresh] So, how does that eliminate the need for NAT-PT?

> Lots of protocols are already using explicit middleboxes such as 
> recursive DNS servers, web proxies, etc. -- that's a good thing.

[suresh] Hmm... I wouldnt call the DNS servers middleboxes. They simply provide
a namelookup service. Middleboxes are assumed to be in the end-2-end path and
perform packet forwarding.
  
> Leveraging these for transition makes great deal of sense.
>

[Suresh] As I said earlier, if a customer has the proxy servers for all the
applications he uses, that is not an issue.
 
> 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.
>

[suresh] I understand what you say. Transparancy provided by NAT-PT is
desirable in certain scenarios as was described in 2766. It is not evenryone's
cup of tea. Midcom extension to such a middlebox can help more applications use
the NAT-PT middlebox effectively. 

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

regards,
suresh

=====