IPv6 Support Required for All IP-Capable Nodes
RFC 6540
Document | Type |
RFC - Best Current Practice
(April 2012; No errata)
Also known as BCP 177
|
|
---|---|---|---|
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 6540 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Jari Arkko | ||
IESG note | Julien Laganier (julien.ietf@gmail.com) is the document shepherd. | ||
Send notices to | (None) |
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 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to 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 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. 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 However, the IPv6 deployment necessary to reduce reliance on IPv4 has been hampered by a lack of ubiquitous hardware and software support throughout the industry. Many vendors, especially in the consumer space, have continued to view IPv6 support as optional. Even today, they are still selling "IP-capable" or "Internet-Capable" devices that are not IPv6-capable, which has continued to push out the point at which the natural hardware refresh cycle will significantlyShow full document text