Document Action: 'Reasons to Move NAT-PT to Historic Status' to Informational RFC
The IESG <iesg-secretary@ietf.org> Sun, 18 March 2007 15:21 UTC
Return-path: <ietf-announce-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSxCO-0002KQ-Gb; Sun, 18 Mar 2007 11:21:32 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSxCM-0002J6-Qu for ietf-announce@ietf.org; Sun, 18 Mar 2007 11:21:30 -0400
Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HSxBx-0007b9-3F for ietf-announce@ietf.org; Sun, 18 Mar 2007 11:21:30 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 089FD2AD34; Sun, 18 Mar 2007 15:20:35 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HSxBS-0002dR-PE; Sun, 18 Mar 2007 11:20:34 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1HSxBS-0002dR-PE@stiedprstage1.ietf.org>
Date: Sun, 18 Mar 2007 11:20:34 -0400
X-Spam-Score: -2.8 (--)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: v6ops mailing list <v6ops@ops.ietf.org>, Internet Architecture Board <iab@iab.org>, v6ops chair <v6ops-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Reasons to Move NAT-PT to Historic Status' to Informational RFC
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Errors-To: ietf-announce-bounces@ietf.org
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 mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce