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:brc@xxxxxxxxxxxxxx] > Sent: Wednesday, February 28, 2007 8:24 AM > To: ietf@xxxxxxxx > Cc: v6ops@xxxxxxxxxxxx > 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 > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf >
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf