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(_at_)zurich(_dot_)ibm(_dot_)com]
Sent: Wednesday, February 28, 2007 8:24 AM
To: ietf(_at_)ietf(_dot_)org
Cc: v6ops(_at_)ops(_dot_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf