The IESG has approved 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 is the product of the IPv6 Operations Working Group. This document also reclassifies RFC 2766 from Proposed Standard to Historic status. The IESG contact persons are David Kessens and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to-historic-00.txt Technical Summary This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status. Working Group Summary The v6ops working group reached consensus on this document. Protocol Quality David Kessens reviewed this document for the IESG Note to RFC Editor In header: OLD: Updates: 2766 (if approved) NEW: Obsoletes: 2766 In '6. Security Considerations': OLD: o Section 2.1 discusses how IPsec AH (transport and tunnel mode) and IPsec ESP transport mode are broken by NAT-PT (when IPSEC UDP encapsulation is not used [RFC3498]); and authentication and encryption are generally incompatible with NAT-PT. NEW: o Section 2.1 discusses how IPsec AH (transport and tunnel mode) and IPsec ESP transport mode are broken by NAT-PT (when IPsec UDP encapsulation is not used [RFC3498]); and authentication and encryption are generally incompatible with NAT-PT. In section '8. Conclusion', first paragraph: OLD: This document has discussed a number of significant issues with NAT-PT as defined in [RFC2766]. From a deployment perspective, 3GPP networks are currently the only 'standardised' scenario where an IPv6-only host communicates with an IPv4-only host using NAT-PT as described in the 3GPP IPv6 transition analysis [RFC4215], but NAT-PT has seen some limited usage for other purposes. NEW: This document has discussed a number of significant issues with NAT-PT as defined in [RFC2766]. From a deployment perspective, 3GPP networks are currently the only 'standardised' scenario where NAT-PT is envisaged as a potential mechanism to allow communication between an IPv6-only host and an IPv4-only host as discussed in the 3GPP IPv6 transition analysis [RFC4215], but RFC4215 recommends that the generic form of NAT-PT should not be used, recommends that modified forms should only be used under strict conditions and documents a number of caveats and security issues specific to 3GPP. In addition, NAT-PT has seen some limited usage for other purposes. In section '8. Conclusion', second paragraph: OLD: It appears that alternatives to NAT-PT exist to cover the circumstances where NAT-PT has been suggested as a solution, such as the use of tunneling and header compression in 3GPP scenarios. NEW: It appears that alternatives to NAT-PT exist to cover the circumstances where NAT-PT has been suggested as a solution, such as the use of application proxies in 3GPP scenarios [RFC4215]. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
