Movatterモバイル変換

Internet Engineering Task Force (IETF)                         W. GeorgeRequest for Comments: 6540                             Time Warner CableBCP: 177                                                       C. DonleyCategory: Best Current Practice                                CableLabsISSN: 2070-1721                                          C. Liljenstolpe                                                     Big Switch Networks                                                               L. Howard                                                       Time Warner Cable                                                              April 2012IPv6 Support Required for All IP-Capable NodesAbstract   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 inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc6540.George, et al.            Best Current Practice                 [Page 1]

RFC 6540                      IPv6-Required                   April 2012Copyright Notice   Copyright (c) 2012 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1. Introduction ....................................................22. Clarifications and Recommendation ...............................33. Acknowledgements ................................................44. Security Considerations .........................................55. Informative References ..........................................51.  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 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.George, et al.            Best Current Practice                 [Page 3]

RFC 6540                      IPv6-Required                   April 2012   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   Sections1,2, and4.  SinceRFC 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, andSection 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.George, et al.            Best Current Practice                 [Page 4]

RFC 6540                      IPv6-Required                   April 20124.  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.George, et al.            Best Current Practice                 [Page 5]

RFC 6540                      IPv6-Required                   April 2012Authors' 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.comGeorge, et al.            Best Current Practice                 [Page 6]