Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status
draft-ietf-v6ops-natpt-to-historic-00

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    v6ops mailing list <v6ops@ops.ietf.org>, 
    v6ops chair <v6ops-chairs@tools.ietf.org>
Subject: Document Action: 'Reasons to Move NAT-PT to Historic 
         Status' to Informational RFC 

The IESG has approved the following document:

- 'Reasons to Move NAT-PT to Historic Status '
   <draft-ietf-v6ops-natpt-to-historic-01.txt> as an Informational RFC

This document is the product of the IPv6 Operations Working Group. 

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-01.txt

Ballot Text

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].

RFC Editor Note