diff options
Diffstat (limited to 'doc/rfc/rfc6540.txt')
| -rw-r--r-- | doc/rfc/rfc6540.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc6540.txt b/doc/rfc/rfc6540.txt new file mode 100644 index 0000000..912d91a --- /dev/null +++ b/doc/rfc/rfc6540.txt @@ -0,0 +1,339 @@ + + + + + + +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, + 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 + 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. + + + +George, et al. Best Current Practice [Page 4] + +RFC 6540 IPv6-Required April 2012 + + +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. + + + + + +George, et al. Best Current Practice [Page 5] + +RFC 6540 IPv6-Required April 2012 + + +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 + + + + + + + + + + + + +George, et al. Best Current Practice [Page 6] + |