BEST CURRENT PRACTICE

Internet Engineering Task Force (IETF) W. George Request for Comments: 6540 Time Warner Cable BCP: 177 C. Donley Category: Best Current Practice CableLabs ISSN: 2070-1721 C. Liljenstolpe Big Switch Networks L. Howard Time Warner Cable April 2012 IPv6 Support Required for All IP-Capable Nodes Abstract Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6540. George, et al. Best Current Practice [Page 1]

RFC 6540 IPv6-Required April 2012 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ....................................................2 2. Clarifications and Recommendation ...............................3 3. Acknowledgements ................................................4 4. Security Considerations .........................................5 5. Informative References ..........................................5 1 . Introduction IANA-EXHAUST], and will be followed by the exhaustion of the free pools for each Regional Internet Registry (RIR), the first of which is APNIC [APNIC-EXHAUST]. While transition technologies and other means to extend the lifespan of IPv4 do exist, nearly all of them come with trade-offs that prevent them from being optimal long-term solutions when compared with deployment of IP version 6 (IPv6) as a means to allow continued growth on the Internet. See [RFC6269] and [NAT444-IMPACTS] for some discussion on this topic. IPv6 [RFC1883] was proposed in 1995 as, among other things, a solution to the limitations on globally unique addressing that IPv4's 32-bit addressing space represented, and has been under continuous refinement (e.g., [RFC2460]) and deployment ever since. The exhaustion of IPv4 and the continued growth of the Internet worldwide have created the driver for widespread IPv6 deployment. George, et al. Best Current Practice [Page 2]

RFC 6540 IPv6-Required April 2012 2 . Clarifications and Recommendation RFC6204] and [RFC6434]. Each of these documents contains specific information, requirements, and references to other Draft and Proposed Standards governing many aspects of IPv6 implementation. George, et al. Best Current Practice [Page 3]

RFC 6540 IPv6-Required April 2012 RFC1812], especially in Sections 1, 2, and 4. Since RFC 1812 is an IPv4 router specification, the generic use of IP in this standard may cause confusion as the term "IP" can now be interpreted to mean IPv4 + IPv6, IPv6-only, or IPv4-only. Additionally, [RFC1122] is no longer a complete definition of "IP" or the Internet Protocol suite by itself, because it does not include IPv6. For example, Section 3.1 does not contain references to the equivalent standards for IPv6 for the Internet layer, Section 3.2 is a protocol walk-through for IPv4 only, and Section 3.2.1.1 explicitly requires that an IP datagram whose version number is not 4 be discarded, which would be detrimental to IPv6 forwarding. Additional instances of this type of problem exist that are not discussed here. Since existing RFCs say "IP" in places where they may mean IPv4, implementers are cautioned to ensure that they know whether a given standard is inclusive or exclusive of IPv6. To ensure interoperability, implementers building IP nodes will need to support both IPv4 and IPv6. If the standard does not include an integral definition of both IPv4 and IPv6, implementers need to use the other informative references in this document as companion guidelines for proper IPv6 implementations. To ensure interoperability and flexibility, the best practices are as follows: o New IP implementations must support IPv6. o Updates to current IP implementations should support IPv6. o IPv6 support must be equivalent or better in quality and functionality when compared to IPv4 support in a new or updated IP implementation. o New and updated IP networking implementations should support IPv4 and IPv6 coexistence (dual-stack), but must not require IPv4 for proper and complete function. o Implementers are encouraged to update existing hardware and software to enable IPv6 wherever technically feasible. 3 . Acknowledgements George, et al. Best Current Practice [Page 4]