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,
datatracker.ietf.org