Internet Area Working Group W. George
Internet-Draft Time Warner Cable
Updates: 1812, 1122, 4084 C. Donley
(if approved) Cablelabs
Intended status: Standards Track C. Liljenstolpe
Expires: December 18, 2011 Telstra
L. Howard
Time Warner Cable
June 16, 2011
IPv6 Support Required for all IP-capable nodes
draft-ietf-intarea-ipv6-required-00
Abstract
Given the global lack of available IPv4 space, and limitations in
IPv4 extension and transition technologies, this document deprecates
the concept that an IP-capable node MAY support IPv4 _only_, and
redefines an IP-capable node as one which supports either IPv6 _only_
or IPv4/IPv6 dual-stack. This document updates RFC1812, RFC1122 and
RFC4084 to reflect the change in requirements.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2011.
Copyright Notice
Copyright (c) 2011 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
George, et al. Expires December 18, 2011 [Page 1]
Internet-Draft IPv6-required June 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. Requirements and Recommendation . . . . . . . . . . . . . . . . 4
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
George, et al. Expires December 18, 2011 [Page 2]
Internet-Draft IPv6-required June 2011
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 requiring
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 tradeoffs 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
[I-D.ietf-intarea-shared-addressing-issues] and
[I-D.donley-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 and deployment ever since. [RFC2460]. The exhaustion of
IPv4 and the continued growth of the internet worldwide has 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
which 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
George, et al. Expires December 18, 2011 [Page 3]
Internet-Draft IPv6-required June 2011
considerably more difficult, and drives the need for expensive and
complicated transition technologies to extend the life of IPv4-only
devices as well as eventually to 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 towards IPv6 as the dominant Internet Protocol will need to
occur. The sooner the majority of devices support IPv6, the less
protracted this transition period will be.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Requirements and Recommendation
This draft updates the following documents:
Updates [RFC1812] to note that IP nodes SHOULD no longer support IPv4
only. This is to ensure that those using it as a guideline for IP
implementations use the other informative references in this document
as a guideline for proper IPv6 implementations.
Updates [RFC1122] to redefine generic "IP" support to include and
require IPv6 for IP-capable nodes and routers.
Updates [RFC4084] to move "Version Support" from Section 4,
"Additional Terminology" to Section 2, "General Terminology." This
is to reflect the idea that version support is now critical to
defining the types of IP service, especially with respect to Full
Internet Connectivity.
From a practical perspective, the requirements proposed by this draft
mean that:
New IP implementations MUST support IPv6.
Current IP implementations SHOULD support IPv6.
IPv6 support MUST be equivalent or better in quality and
functionality when compared to IPv4 support in an IP
implementation.
Helpful informative references can be found in [RFC4294], soon to
be updated by [I-D.ietf-6man-node-req-bis] and in [RFC6204]
George, et al. Expires December 18, 2011 [Page 4]
Internet-Draft IPv6-required June 2011
Current and new IP Networking implementations SHOULD support IPv4
and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for
proper and complete function.
It is expected that many existing devices and implementations will
not be able to support IPv6 for one or more valid technical
reasons, but for maximum flexibility and compatibility, a best
effort SHOULD be made to update existing hardware and software to
enable IPv6 support.
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
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
There are no direct security considerations generated by this
document, but existing documented security considerations for
implementing IPv6 will apply.
6. References
6.1. Normative References
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4084] Klensin, J., "Terminology for Describing Internet
Connectivity", BCP 104, RFC 4084, May 2005.
George, et al. Expires December 18, 2011 [Page 5]
Internet-Draft IPv6-required June 2011
6.2. Informative References
[APNIC-exhaust]
APNIC, "APNIC Press Release", 2011, <http://www.apnic.net/
__data/assets/pdf_file/0018/33246/
Key-Turning-Point-in-Asia-Pacific-IPv4-
Exhaustion_English.pdf >.
[I-D.donley-nat444-impacts]
Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A.,
and V. Ganti, "Assessing the Impact of NAT444 on Network
Applications", draft-donley-nat444-impacts-01 (work in
progress), October 2010.
[I-D.ietf-6man-node-req-bis]
Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", draft-ietf-6man-node-req-bis-11 (work in
progress), May 2011.
[I-D.ietf-intarea-shared-addressing-issues]
Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing",
draft-ietf-intarea-shared-addressing-issues-05 (work in
progress), March 2011.
[IANA-exhaust]
IANA, "IANA address allocation", 2011, <http://
www.iana.org/assignments/ipv4-address-space/
ipv4-address-space.xml>.
[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.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
George, et al. Expires December 18, 2011 [Page 6]
Internet-Draft IPv6-required June 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
Telstra
Level 32/242 Exhibition Street
Melbourne, VIC 3000
AU
Phone: +61-3-8647-6389
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
George, et al. Expires December 18, 2011 [Page 7]
