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
George, et al. Best Current Practice [Page 1]
RFC 6540 IPv6-Required April 2012
Copyright Notice
1. Introduction
IP version 4 (IPv4) has served to connect public and private hosts all over the world for over 30 years. However, due to the success of the Internet in finding new and innovative uses for IP networking, billions of hosts are now connected via the Internet and require unique addressing. This demand has led to the exhaustion of the IANA global pool of unique IPv4 addresses [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.
George, et al. Best Current Practice [Page 2]
RFC 6540 IPv6-Required April 2012
This lack of support is making the eventual IPv6 transition considerably more difficult, and drives the need for expensive and complicated transition technologies to extend the life of IPv4-only devices as well as to eventually interwork IPv4-only and IPv6-only hosts. While IPv4 is expected to coexist on the Internet with IPv6 for many years, a transition from IPv4 as the dominant Internet Protocol version towards IPv6 as the dominant Internet Protocol version will need to occur. The sooner the majority of devices support IPv6, the less protracted this transition period will be.
2. Clarifications and Recommendation
To ensure interoperability and proper function after IPv4 exhaustion, support for IPv6 is virtually a requirement. Rather than update the existing IPv4 protocol specification standards to include IPv6, the IETF has defined a completely separate set of standalone documents that cover IPv6. Therefore, implementers are cautioned that a distinction must be made between IPv4 and IPv6 in some IETF documents where the term "IP" is used generically. Current requirements for IPv6 support can be found in [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. Many of the IETF's early documents use the generic term "IP" synonymously with the more specific "IPv4". Some examples of this potential confusion can be found in [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.
George, et al. Best Current Practice [Page 3]
RFC 6540 IPv6-Required April 2012
To ensure interoperability and flexibility, the best practices are as follows:
3. Acknowledgements
Thanks to the following people for their reviews and comments: Marla Azinger, Brian Carpenter, Victor Kuarsingh, Jari Arkko, Scott Brim, Margaret Wasserman, Joe Touch, Fred Baker, Benson Schliesser, Eric Rosen, David Harrington, and Wesley Eddy.
George, et al. Best Current Practice [Page 4]
RFC 6540 IPv6-Required April 2012 4. Security ConsiderationsThere are no direct security considerations generated by this document, but existing documented security considerations for implementing IPv6 will apply.
5. Informative References
[APNIC-EXHAUST]
Pacific IPv4 Exhaustion", April 2011, <http://
www.apnic.net/__data/assets/pdf_file/0018/33246/
Key-Turning-Point-in-Asia-Pacific-IPv4-
Exhaustion_English.pdf>.
George, et al. Best Current Practice [Page 5]
RFC 6540 IPv6-Required April 2012
Authors' Addresses