draft-ietf-intarea-ipv6-required-02.txt   rfc6540.txt 
Internet Area Working Group W. George Internet Engineering Task Force (IETF) W. George
Internet-Draft Time Warner Cable Request for Comments: 6540 Time Warner Cable
Intended status: BCP C. Donley BCP: 177 C. Donley
Expires: June 10, 2012 Cablelabs Category: Best Current Practice CableLabs
C. Liljenstolpe ISSN: 2070-1721 C. Liljenstolpe
Telstra Big Switch Networks
L. Howard L. Howard
Time Warner Cable Time Warner Cable
December 8, 2011 April 2012
IPv6 Support Required for all IP-capable Nodes IPv6 Support Required for All IP-Capable Nodes
draft-ietf-intarea-ipv6-required-02
Abstract Abstract
Given the global lack of available IPv4 space, and limitations in Given the global lack of available IPv4 space, and limitations in
IPv4 extension and transition technologies, this document advises IPv4 extension and transition technologies, this document advises
that IPv6 support is no longer considered optional. It also cautions that IPv6 support is no longer considered optional. It also cautions
that there are places in existing IETF documents where the term "IP" 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 is used in a way that could be misunderstood by implementers as the
term "IP" becomes a generic which can mean IPv4 + IPv6, IPv6-only, or term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or
IPv4-only, depending on context and application. IPv4-only, depending on context and application.
Status of this Memo 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 This memo documents an Internet Best Current Practice.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 10, 2012. 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 Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Clarifications and Recommendation . . . . . . . . . . . . . . . 4 2. Clarifications and Recommendation ...............................3
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 3. Acknowledgements ................................................4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations .........................................5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Informative References ..........................................5
6. Informative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
IP version 4 (IPv4) has served to connect public and private hosts 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 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, the Internet in finding new and innovative uses for IP networking,
billions of hosts are now connected via the Internet and requiring billions of hosts are now connected via the Internet and require
unique addressing. This demand has led to the exhaustion of the IANA unique addressing. This demand has led to the exhaustion of the IANA
global pool of unique IPv4 addresses [IANA-exhaust], and will be global pool of unique IPv4 addresses [IANA-EXHAUST], and will be
followed by the exhaustion of the free pools for each Regional followed by the exhaustion of the free pools for each Regional
Internet Registry (RIR), the first of which is APNIC [APNIC-exhaust]. Internet Registry (RIR), the first of which is APNIC [APNIC-EXHAUST].
While transition technologies and other means to extend the lifespan While transition technologies and other means to extend the lifespan
of IPv4 do exist, nearly all of them come with tradeoffs that prevent of IPv4 do exist, nearly all of them come with trade-offs that
them from being optimal long-term solutions when compared with prevent them from being optimal long-term solutions when compared
deployment of IP version 6 (IPv6) as a means to allow continued with deployment of IP version 6 (IPv6) as a means to allow continued
growth on the Internet. See [RFC6269] and growth on the Internet. See [RFC6269] and [NAT444-IMPACTS] for some
[I-D.donley-nat444-impacts] for some discussion on this topic. discussion on this topic.
IPv6 [RFC1883] was proposed in 1995 as, among other things, a IPv6 [RFC1883] was proposed in 1995 as, among other things, a
solution to the limitations on globally unique addressing that IPv4's solution to the limitations on globally unique addressing that IPv4's
32-bit addressing space represented, and has been under continuous 32-bit addressing space represented, and has been under continuous
refinement (e.g., [RFC2460]) and deployment ever since. The refinement (e.g., [RFC2460]) and deployment ever since. The
exhaustion of IPv4 and the continued growth of the internet worldwide exhaustion of IPv4 and the continued growth of the Internet worldwide
has created the driver for widespread IPv6 deployment. have created the driver for widespread IPv6 deployment.
However, the IPv6 deployment necessary to reduce reliance on IPv4 has However, the IPv6 deployment necessary to reduce reliance on IPv4 has
been hampered by a lack of ubiquitous hardware and software support been hampered by a lack of ubiquitous hardware and software support
throughout the industry. Many vendors, especially in the consumer throughout the industry. Many vendors, especially in the consumer
space have continued to view IPv6 support as optional. Even today space, have continued to view IPv6 support as optional. Even today,
they are still selling "IP capable" or "Internet Capable" devices they are still selling "IP-capable" or "Internet-Capable" devices
which are not IPv6-capable, which has continued to push out the point that are not IPv6-capable, which has continued to push out the point
at which the natural hardware refresh cycle will significantly at which the natural hardware refresh cycle will significantly
increase IPv6 support in the average home or enterprise network. increase IPv6 support in the average home or enterprise network.
They are also choosing not to update existing software to enable IPv6 They are also choosing not to update existing software to enable IPv6
support on software-updatable devices, which is a problem because it support on software-updatable devices, which is a problem because it
is not realistic to expect that the hardware refresh cycle will is not realistic to expect that the hardware refresh cycle will
single-handedly purge IPv4-only devices from the active network in a single-handedly purge IPv4-only devices from the active network in a
reasonable amount of time. This is a significant problem, especially reasonable amount of time. This is a significant problem, especially
in the consumer space, where the network operator often has no in the consumer space, where the network operator often has no
control over the hardware the consumer chooses to use. For the same control over the hardware the consumer chooses to use. For the same
reason that the average consumer is not making a purchasing decision reason that the average consumer is not making a purchasing decision
based on the presence of IPv6 support in their Internet-capable based on the presence of IPv6 support in their Internet-capable
devices and services, consumers are unlikely to replace their still- devices and services, consumers are unlikely to replace their still-
functional Internet-capable devices simply to add IPv6 support - they functional Internet-capable devices simply to add IPv6 support --
don't know or don't care about IPv6, they simply want their devices they don't know or don't care about IPv6; they simply want their
to work as advertised. devices to work as advertised.
This lack of support is making the eventual IPv6 transition This lack of support is making the eventual IPv6 transition
considerably more difficult, and drives the need for expensive and considerably more difficult, and drives the need for expensive and
complicated transition technologies to extend the life of IPv4-only complicated transition technologies to extend the life of IPv4-only
devices as well as eventually to interwork IPv4-only and IPv6-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 hosts. While IPv4 is expected to coexist on the Internet with IPv6
for many years, a transition from IPv4 as the dominant Internet for many years, a transition from IPv4 as the dominant Internet
Protocol towards IPv6 as the dominant Internet Protocol will need to Protocol version towards IPv6 as the dominant Internet Protocol
occur. The sooner the majority of devices support IPv6, the less version will need to occur. The sooner the majority of devices
protracted this transition period will be. support IPv6, the less protracted this transition period will be.
2. Clarifications and Recommendation 2. Clarifications and Recommendation
To ensure interoperability and proper function after IPv4 exhaustion, To ensure interoperability and proper function after IPv4 exhaustion,
support for IPv6 is virtually a requirement. Rather than update the support for IPv6 is virtually a requirement. Rather than update the
existing IPv4 protocol specification standards to include IPv6, IETF existing IPv4 protocol specification standards to include IPv6, the
has defined a completely separate set of standalone documents which IETF has defined a completely separate set of standalone documents
cover IPv6. Therefore, implementers are cautioned that a distinction that cover IPv6. Therefore, implementers are cautioned that a
must be made between IPv4 and IPv6 in some IETF documents where IP is distinction must be made between IPv4 and IPv6 in some IETF documents
used generically. Current requirements for IPv6 support can be found where the term "IP" is used generically. Current requirements for
in [RFC4294], soon to be updated by [I-D.ietf-6man-node-req-bis] and IPv6 support can be found in [RFC6204] and [RFC6434]. Each of these
in [RFC6204]. Each of these documents contains specific information, documents contains specific information, requirements, and references
requirements, and references to other draft and proposed standards to other Draft and Proposed Standards governing many aspects of IPv6
governing many aspects of IPv6 implementation. implementation.
Many of IETF's early documents use the generic term "IP" synonymously Many of the IETF's early documents use the generic term "IP"
with the more specific "IPv4." Some examples of this potential synonymously with the more specific "IPv4". Some examples of this
confusion can be found in [RFC1812], especially sections 1, 2, and 4. potential confusion can be found in [RFC1812], especially in
Since RFC1812 is an IPv4 router specification, the generic use of IP Sections 1, 2, and 4. Since RFC 1812 is an IPv4 router
in this standard may cause confusion as the term "IP" can now be specification, the generic use of IP in this standard may cause
interpreted to mean: IPv4 + IPv6, IPv6-only, or IPv4-only. confusion as the term "IP" can now be interpreted to mean
Additionally, [RFC1122], is no longer a complete definition of "IP" IPv4 + IPv6, IPv6-only, or IPv4-only. Additionally, [RFC1122] is no
or the Internet Protocol suite by itself, because it does not include longer a complete definition of "IP" or the Internet Protocol suite
IPv6. For example, section 3.1 does not contain references to the by itself, because it does not include IPv6. For example,
IPv6 equivalent standards for the Internet layer, section 3.2 is a Section 3.1 does not contain references to the equivalent standards
protocol walk-through for IPv4 only, and section 3.2.1.1 explicitly for IPv6 for the Internet layer, Section 3.2 is a protocol
requires an IP datagram whose version number is not 4 to be walk-through for IPv4 only, and Section 3.2.1.1 explicitly requires
discarded, which would be detrimental to IPv6 forwarding. Additional that an IP datagram whose version number is not 4 be discarded, which
instances of this type of problem exist that are not discussed here. would be detrimental to IPv6 forwarding. Additional instances of
Since existing RFCs say "IP" in places where they may mean IPv4, 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 implementers are cautioned to ensure that they know whether a given
standard is inclusive or exclusive of IPv6. To ensure standard is inclusive or exclusive of IPv6. To ensure
interoperability, implementers building IP nodes will need to support interoperability, implementers building IP nodes will need to support
both IPv4 and IPv6. If the standard does not include an integral both IPv4 and IPv6. If the standard does not include an integral
definition of both IPv4 and IPv6, implementers need to use the other definition of both IPv4 and IPv6, implementers need to use the other
informative references in this document as a companion guideline for informative references in this document as companion guidelines for
proper IPv6 implementations. proper IPv6 implementations.
To ensure interoperability and flexibility, the best practice is: To ensure interoperability and flexibility, the best practices are as
follows:
New IP implementations must support IPv6. o New IP implementations must support IPv6.
Updates to current IP implementations should support IPv6. o Updates to current IP implementations should support IPv6.
IPv6 support must be equivalent or better in quality and o IPv6 support must be equivalent or better in quality and
functionality when compared to IPv4 support in a new or updated IP functionality when compared to IPv4 support in a new or updated IP
implementation. implementation.
New and updated IP Networking implementations should support IPv4 o New and updated IP networking implementations should support IPv4
and IPv6 coexistence (dual-stack), but must not require IPv4 for and IPv6 coexistence (dual-stack), but must not require IPv4 for
proper and complete function. proper and complete function.
Implementers are encouraged to update existing hardware and o Implementers are encouraged to update existing hardware and
software to enable IPv6 wherever technically feasible. software to enable IPv6 wherever technically feasible.
3. Acknowledgements 3. Acknowledgements
Thanks to the following people for their reviews and comments: Marla Thanks to the following people for their reviews and comments: Marla
Azinger, Brian Carpenter, Victor Kuarsingh, Jari Arkko, Scott Brim, Azinger, Brian Carpenter, Victor Kuarsingh, Jari Arkko, Scott Brim,
Margaret Wasserman, Joe Touch, Fred Baker, Benson Schliesser, Eric Margaret Wasserman, Joe Touch, Fred Baker, Benson Schliesser, Eric
Rosen, David Harrington, Wesley Eddy. Rosen, David Harrington, and Wesley Eddy.
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations 4. Security Considerations
There are no direct security considerations generated by this There are no direct security considerations generated by this
document, but existing documented security considerations for document, but existing documented security considerations for
implementing IPv6 will apply. implementing IPv6 will apply.
6. Informative References 5. Informative References
[APNIC-exhaust] [APNIC-EXHAUST]
APNIC, "APNIC Press Release", 2011, <http://www.apnic.net/ APNIC, "APNIC Press Release - Key Turning Point in Asia
__data/assets/pdf_file/0018/33246/ Pacific IPv4 Exhaustion", April 2011, <http://
www.apnic.net/__data/assets/pdf_file/0018/33246/
Key-Turning-Point-in-Asia-Pacific-IPv4- Key-Turning-Point-in-Asia-Pacific-IPv4-
Exhaustion_English.pdf >. Exhaustion_English.pdf>.
[I-D.donley-nat444-impacts]
Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U.
Colorado, "Assessing the Impact of Carrier-Grade NAT on
Network Applications", draft-donley-nat444-impacts-03
(work in progress), November 2011.
[I-D.ietf-6man-node-req-bis] [IANA-EXHAUST]
Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node IANA, "IANA IPv4 Address Space Registry",
Requirements", draft-ietf-6man-node-req-bis-11 (work in <http://www.iana.org/assignments/ipv4-address-space>.
progress), May 2011.
[IANA-exhaust] [NAT444-IMPACTS]
IANA, "IANA address allocation", 2011, <http:// Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J.
www.iana.org/assignments/ipv4-address-space/ Doshi, "Assessing the Impact of Carrier-Grade NAT on
ipv4-address-space.xml>. Network Applications", Work in Progress, November 2011.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995. RFC 1812, June 1995.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995. (IPv6) Specification", RFC 1883, December 1995.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (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. [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge Troan, Ed., "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011. Routers", RFC 6204, April 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
Roberts, "Issues with IP Address Sharing", RFC 6269, P. Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011. June 2011.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011.
Authors' Addresses Authors' Addresses
Wesley George Wesley George
Time Warner Cable Time Warner Cable
13820 Sunrise Valley Drive 13820 Sunrise Valley Drive
Herndon, VA 20171 Herndon, VA 20171
US US
Phone: +1 703-561-2540 Phone: +1 703-561-2540
Email: wesley.george@twcable.com EMail: wesley.george@twcable.com
Chris Donley Chris Donley
Cablelabs CableLabs
858 Coal Creek Circle 858 Coal Creek Circle
Louisville, CO 80027 Louisville, CO 80027
US US
Phone: +1-303-661-9100 Phone: +1-303-661-9100
Email: C.Donley@cablelabs.com EMail: C.Donley@cablelabs.com
Christopher Liljenstolpe Christopher Liljenstolpe
Telstra Big Switch Networks
Level 32/242 Exhibition Street 430 Cowper St.
Melbourne, VIC 3000 Palo Alto, CA 94301
AU US
Phone: +61-3-8647-6389 EMail: cdl@asgaard.org
Email: cdl@asgaard.org
Lee Howard Lee Howard
Time Warner Cable Time Warner Cable
13820 Sunrise Valley Drive 13820 Sunrise Valley Drive
Herndon, VA 20171 Herndon, VA 20171
US US
Phone: +1-703-345-3513 Phone: +1-703-345-3513
Email: lee.howard@twcable.com EMail: lee.howard@twcable.com
 End of changes. 47 change blocks. 
124 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/