RE: NAT-PT: To deprecate or not to deprecate: the question for next w eek's v6ops discussion

["Tony Hain" <alh-ietf@tndh.net>]

FWIW: like it or not we need a function that deals with IPv6-only devices
talking to IPv4-only legacy devices. That is the useful function of NAT-PT
and it works as well as IPv4-IPv4 nat as long as it is parked as close to
the IPv4-only device as possible. The DNS-ALG shouldn't be there because it
decreases the overall network value by confusing the IPv6 device. As such
the deprecate NAT-PT / NAT-PTbis effort needs to simply focus on removing
the DNS cruft. 

Legislating how people run their networks is not the job of the IETF.
Documenting how to get their job done efficiently is something the IETF can
and should do as creator of the tool set. The most we can do is document the
failings of nat as a technology, and refuse to standardize on an IPv6-IPv6
version. To some degree the NAP document is specifically trying to make the
case that mangling headers is not required once IPv4 is out of the
environment, and that all of the 'other marketed uses' of the technology are
possible using IPv6. If there are missing uses, or clearer language that
will make the case, please send text. 

Tony 

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
> Of EricLKlein
> Sent: Saturday, November 06, 2004 12:23 AM
> To: v6ops@ops.ietf.org
> Subject: Re: NAT-PT: To deprecate or not to deprecate: the question for
> next w eek's v6ops discussion
> 
> From: "Alain Durand"
> > I think this is the crux of the issue. NAT-PT is not just NAT for v4 to
> > v6.
> > Because of its design, it adds new issue to the plate of NAT.
> >
> > IMHO, the way forward is not to pretend any translation v6->v4 is bad,
> > but to declare
> > that the specific method described in RFC2766 is problematic and thus
> > should be deprecated.
> >
> > If real need for v6 to v4 (and vice versa) emerge, it will be time to
> > look again at the issue,
> > maybe resurrect my NAT64 and NAT46 proposals or design something else.
> >
> 
> 
> I tend to disagree.
> 
> To borrow somthing Tony said in another thread:
> "The IETF needs to be about developing a
> growing and vibrant Internet, so resisting the inevitable change is
> counter
> productive. In that light, it is time to remove the special status of
> separate working groups for IPv6, and make it the default IP protocol for
> all IETF work. "
> 
> Since we as a WG have decided to depriciate NAT and not support (allow) it
> into IPv6 I think it is time that we just say that it is not supported and
> start killing it off once and for all. Otherwise we will always have to
> work
> the old NAT space and functions into the IPv6 space.
> 
> I understand the need for a transition mechanisim, but I do not feel that
> it
> is strongly stated enough the NAT is out. Not even the why you don't need
> NAT draft (draft-vandevelde-v6ops-nap-00) tries to do that.
> 
> We need to start pushing the new standards out to the market ASAP, or we
> will be trying to back fix all sorts of propritary fixes (like the DHCPv6
> issue) and will run out of addresses in the existing space ling before we
> get real acceptance of IPv6.
> 
> Eric
>