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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 28 Feb 2007 08:02:40 -0800

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 last time I heard that it was in IPSEC "One objection is that IPSEC is not NAT-friendly, some of us consider that a feature not a bug". The result was an IPSEC specification that does not work half as well for the user as tunnelling over SSL or SSH. I am guaranteed to be able to use that type of VPN in a hotel room with no problems whatsoever.

The questions that I would like to see answered that I don't see in the document are

1) What is the deployment strategy for IPv6 without NAT?
2) Are people actually using or deploying NAT-PT?
3) Exactly why should an application be invited to care about this issue?

By deployment strategy I mean a complete marketing plan for IPv6 that provides both a powerful incentive for a network to transition from IPv4 to IPv6 and technical infrastructure that makes the process entirely transparent to the customers and users served.

What is the pain point that IPv6 addresses? IPv4 address exhaustion is not an effective pain point. ISPs that get worried about that can solve their difficulties at least cost by hoarding IPv4 allocation. Scarcity then becomes an advantage to them as it disadvantages their competition.

On (3) I see no value whatsoever in the assumption that the source and destination IP addresses remain invariant as a packet moves. It does not hold for IPv4 networks for a start. Yes, I do know the history here and the end-to-end principle. Dave Clark is one of the most pragmatic people I know, the end to end principle was proposed to solve problems, not create them.

The only protocol which really cares about the source and destination IP addresses is IPSEC and we have discovered that is a design error. 

There is certainly still a port multiplexing issue but this can be finessed if we abolish the concept of well known ports.

In short before the draft is approved there should be an artchitecture on the table that does make the IPv4 to IPv6 transition plausible. Killing NAT-PT at this point would be a mistake because it would create the false impression that NAT is going away which it isn't.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Wednesday, February 28, 2007 8:24 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Last Call: draft-ietf-v6ops-natpt-to-historic 
> (Reasons to Move NAT-PT to Historic Status) to Informational RFC
> 
> I think it's important to publish this document, to make it 
> clear why NAT-PT is a solution of very dubious value.
> 
>      Brian
> 
> On 2007-02-27 20:14, The IESG wrote:
> > The IESG has received a request from the IPv6 Operations WG 
> (v6ops) to 
> > consider the following document:
> > 
> > - 'Reasons to Move NAT-PT to Historic Status '
> >    <draft-ietf-v6ops-natpt-to-historic-00.txt> as an 
> Informational RFC
> > 
> > This document recommends that the IESG reclassifies RFC 2766 from 
> > Standards Track to Experimental status.
> > 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Feb 2007 11:37:19 -0500

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <[email-masked]> writes:

    Hallam-Baker,> The core assumption here seems to be that NAT is a
    Hallam-Baker,> bad thing so lets get rid of NAT rather than trying
    Hallam-Baker,> to make NAT work.  

I disagree with this characterization of the document.  I think it is
more like we have existing NAT mechanisms; we have strategies for
making them work.  Dual stack nodes is a better way forward than
creating a new NAT mechanism to move from IPV6 to IPV4 and trying to
make that (with a different set of problems than traditional NAT)
work.

I don't think this document is anti-NAT.  Can you help me understand
why I'm wrong or reconsider how much of your argument still applies?

---

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

> 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: Elwyn Davies <[email-masked]>
Date: Wed, 28 Feb 2007 19:31:42 +0000

/Elwyn

---

From: David Conrad <[email-masked]>
Date: Wed, 28 Feb 2007 11:35:43 -0800

Sam,

On Feb 28, 2007, at 8:37 AM, Sam Hartman wrote:
> I think it is

Doesn't dual stack rely on the assumption that IPv4 is available?

Based on current projections, in a smallish number of years (more  
than 2, less than 10), the free pool for IPv4 will be exhausted.  I  
have some skepticism, perhaps unjustified, that IPv6 will be  
ubiquitous in that timeframe.  As such, it would appear there needs  
to be some sort of solution that will allow IPv6-only sites to talk  
to IPv4-only sites.  What is the IETF suggesting?

Thanks,
-drc

---

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.