IPv6 Required: IPv6 Support Required for All IP-Capable Nodes
IPv6 support is no longer optional: new IP implementations must support it and must not require IPv4.
George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, DOI 10.17487/RFC6540, April 2012, <https://www.rfc-editor.org/info/rfc6540>.
@misc{rfc6540,
series = {Request for Comments},
number = 6540,
howpublished = {RFC 6540},
publisher = {RFC Editor},
doi = {10.17487/RFC6540},
url = {https://www.rfc-editor.org/info/rfc6540},
author = {W. George and C. Donley and C. Liljenstolpe and L. Howard},
title = {{IPv6 Support Required for All IP-Capable Nodes}},
pagetotal = 6,
year = 2012,
month = apr,
} RFC text
Contents
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.
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.
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 significantly
increase IPv6 support in the average home or enterprise network.
They are also choosing not to update existing software to enable IPv6
support on software-updatable devices, which is a problem because it
is not realistic to expect that the hardware refresh cycle will
single-handedly purge IPv4-only devices from the active network in a
reasonable amount of time. This is a significant problem, especially
in the consumer space, where the network operator often has no
control over the hardware the consumer chooses to use. For the same
reason that the average consumer is not making a purchasing decision
based on the presence of IPv6 support in their Internet-capable
devices and services, consumers are unlikely to replace their still-
functional Internet-capable devices simply to add IPv6 support --
they don't know or don't care about IPv6; they simply want their
devices to work as advertised.
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.
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
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.
4. Security Considerations
There are no direct security considerations generated by this
document, but existing documented security considerations for
implementing IPv6 will apply.
5. Informative References
[APNIC-EXHAUST]
APNIC, "APNIC Press Release - Key Turning Point in Asia
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>.
[IANA-EXHAUST]
IANA, "IANA IPv4 Address Space Registry",
<http://www.iana.org/assignments/ipv4-address-space>.
[NAT444-IMPACTS]
Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J.
Doshi, "Assessing the Impact of Carrier-Grade NAT on
Network Applications", Work in Progress, November 2011.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, Ed., "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011.
Authors' Addresses
Wesley George
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
US
Phone: +1 703-561-2540
EMail: wesley.george@twcable.com
Chris Donley
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
US
Phone: +1-303-661-9100
EMail: C.Donley@cablelabs.com
Christopher Liljenstolpe
Big Switch Networks
430 Cowper St.
Palo Alto, CA 94301
US
EMail: cdl@asgaard.org
Lee Howard
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
US
Phone: +1-703-345-3513
EMail: lee.howard@twcable.com
AI ELI5
On this page
§1Why IPv6 Can No Longer Be Optional
RFC 6540 is a Best Current Practice (BCP 177). It observes that IPv4 has connected hosts for over 30 years, but billions of hosts now need unique addresses. The IANA global pool of IPv4 addresses has been exhausted, and the free pool of each Regional Internet Registry will follow, starting with APNIC.
Transition technologies that stretch the life of IPv4 exist, but nearly all come with trade-offs that make them worse long-term answers than deploying IPv6. The RFC points to RFC 6269 for discussion of the issues with address sharing.
The old addresses ran out, and patches to make them last longer all have downsides. The new addresses are the lasting fix.
§2The Deployment Problem
IPv6 was proposed in 1995 in RFC 1883 and has been refined since, for example in RFC 2460. Yet deployment has been held back by uneven hardware and software support. Many vendors, especially in the consumer space, treat IPv6 as optional and still sell "IP-capable" or "Internet-Capable" devices without it. They also choose not to update the software on devices that could be updated.
The RFC argues the hardware refresh cycle alone will not fix this in a reasonable time. Consumers do not buy based on IPv6 support and will not replace working devices just to add it, and the network operator often has no control over what the consumer buys. The lack of support makes the transition harder and drives the need for expensive, complicated technologies to keep IPv4-only devices going and to interwork IPv4-only and IPv6-only hosts. IPv4 is expected to coexist with IPv6 for many years, but the sooner most devices support IPv6, the shorter the transition.
Shops keep selling gadgets that only know the old addresses, and people keep using them. That makes the switch slower and costlier.
§3When "IP" Means IPv4
The IETF wrote IPv6 as a completely separate set of standalone documents rather than updating the IPv4 specifications. Many early documents use "IP" to mean IPv4, so today "IP" could mean IPv4 plus IPv6, IPv6 only, or IPv4 only.
The RFC gives examples. RFC 1812, an IPv4 router specification, uses generic "IP" in Sections 1, 2 and 4. RFC 1122 is no longer a complete definition of the Internet protocol suite because it omits IPv6: Section 3.2 is an IPv4-only walk-through, and Section 3.2.1.1 explicitly requires discarding an IP datagram whose version number is not 4, which would be harmful to IPv6 forwarding.
Implementers are therefore cautioned to know whether a given standard includes or excludes IPv6, and to use the informative references as companion guidelines when it does not define both. Current IPv6 requirements are in RFC 6204 and RFC 6434.
Old rulebooks say just "IP" when they only mean the old kind. Builders have to check which kind a rule is really about.
§4The Best Practices
The RFC lists five practices:
- New IP implementations must support IPv6.
- Updates to current IP implementations should support IPv6.
- IPv6 support must be equivalent or better in quality and functionality than IPv4 support in a new or updated implementation.
- New and updated IP networking implementations should support IPv4 and IPv6 coexistence (dual-stack), but must not require IPv4 for proper and complete function.
- Implementers are encouraged to update existing hardware and software to enable IPv6 wherever technically feasible.
To ensure interoperability, implementers building IP nodes need to support both IPv4 and IPv6.
New gadgets must speak the new address language, and it must work as well as the old one. They should not need the old one to work.
- New implementationsMust support IPv6.
- UpdatesShould support IPv6.
- QualityIPv6 must be equivalent or better than IPv4.
- Dual-stackShould coexist with IPv4, but must not require IPv4.
- Existing gearUpdate to enable IPv6 where technically feasible.
§5Security Considerations
The document generates no direct security considerations. The existing, documented security considerations for implementing IPv6 apply.
The RFC is advisory guidance and defines no protocol messages, formats or registries.
This note adds no new safety rules. The usual safety advice for the new addresses still applies.