Subject: Re: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC

From: Elwyn Davies <[email-masked]>
Date: Wed, 28 Feb 2007 19:31:42 +0000

Hallam-Baker, Phillip wrote:
> The core assumption here seems to be that NAT is a bad thing so lets get rid of NAT rather than trying to make NAT work.
>   
NAT-PT is not NAT.  It does a whole lot more, but it *cannot* do what it 
claims to do completely, because the semantics on the two sides are 
different, unlike NAT.  Dual stack is a better way forwards for the 
general case.
If you read carefully the draft suggests that there may be scenarios in 
which a modified form of NAT-PT might be useful, so it is hardly extreme 
NAT bashing.
> 3) Exactly why should an application be invited to care about this issue?
>
>   
Because whether the packets pass through a NAT-PT or otherwise affects 
what the application might expect from the network.

NAT does, for better or for worse, solve some real problems.
NAT-PT makes new problems: Not good news for a transition mechanism and 
it militates against future improvements to IPv6.

/Elwyn

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Feb 2007 13:48:54 -0800

On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote:

> The core assumption here seems to be that NAT is a bad thing so  
> lets get rid of NAT rather than trying to make NAT work.
> ...
> The only protocol which really cares about the source and  
> destination IP addresses is IPSEC and we have discovered that is a  
> design error.

I guess you haven't been around the applications that have trouble  
with this very much. Any client-server application works fine across  
a NAT, as long as it is the client that initiates the connection. I  
refer you to the history of RSIP, the complexities of peer2peer  
applications, Melinda Shore's frequent attempts at a generalized  
firewall traversal methodology, and all the other places in which  
applications that require a means of connecting to a device that has  
no address in your favored address space at the time you want to  
connect to it.

Dismissing the notion using a bunch of fallacies isn't a very strong  
argument.