--- 1/draft-ietf-intarea-ipv6-required-01.txt 2011-12-08 18:13:59.070756034 +0100 +++ 2/draft-ietf-intarea-ipv6-required-02.txt 2011-12-08 18:13:59.086755142 +0100 @@ -1,102 +1,99 @@ 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: January 12, 2012 Telstra +Intended status: BCP C. Donley +Expires: June 10, 2012 Cablelabs + C. Liljenstolpe + Telstra L. Howard Time Warner Cable - July 11, 2011 + December 8, 2011 - IPv6 Support Required for all IP-capable nodes - draft-ietf-intarea-ipv6-required-01 + IPv6 Support Required for all IP-capable Nodes + draft-ietf-intarea-ipv6-required-02 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. + 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 which can mean IPv4 + IPv6, IPv6-only, or + IPv4-only, depending on context and application. 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 January 12, 2012. + This Internet-Draft will expire on June 10, 2012. 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 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 + 2. Clarifications and Recommendation . . . . . . . . . . . . . . . 4 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 - 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 + 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 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 + growth on the Internet. See [RFC6269] 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. + refinement (e.g., [RFC2460]) and deployment ever since. 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 @@ -116,170 +113,138 @@ 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 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], especially sections 1, 2, and 4 which use the - generic "IP" synonymously with the more specific "IPv4." Since - RFC1812 is an IPv4 router specification, the generic use of IP in - this standard may cause confusion as IP is redefined to mean IPv4 + - IPv6. This proposed update is not intended to change the existing - technical interpretation of RFC1812 to include IPv6 in its - implementation details. Rather, it is intended to ensure that those - using RFC1812 as a guideline for IP implementations understand that - IP nodes SHOULD NOT support IPv4 only, and that they should use the - other informative references in this document as a companion - guideline for proper IPv6 implementations. - - Updates [RFC1122] to clarify that this document, especially in - section 3, primarily discusses IPv4 where it uses the more generic - term "IP" and is no longer a complete definition of "IP" or the - Internet Protocol suite by itself. For example, section 3.1 does not - contain references to the IPv6 equivalent standards for the Internet - layer, section 3.2 is a protocol walk-through for IPv4 only; section - 3.2.1.1 explicitly requires an IP datagram whose version number is - not 4 to be discarded, which would be detrimental to IPv6 forwarding. - However, portions of RFC1122 refer to the Internet Layer and IP more - in terms of its function and are less version-specific, such as - Section 1.1.3. In these cases, it is possible to redefine generic - "IP" support to include and require IPv6 for IP-capable nodes and - routers. +2. Clarifications and Recommendation - 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. + 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, IETF + has defined a completely separate set of standalone documents which + cover IPv6. Therefore, implementers are cautioned that a distinction + must be made between IPv4 and IPv6 in some IETF documents where IP is + used generically. Current requirements for IPv6 support can be found + in [RFC4294], soon to be updated by [I-D.ietf-6man-node-req-bis] and + in [RFC6204]. Each of these documents contains specific information, + requirements, and references to other draft and proposed standards + governing many aspects of IPv6 implementation. - Rather than update the existing IPv4 protocol specification standards - to include IPv6, IETF has defined a completely separate set of - standalone documents which cover IPv6. Therefore, the above-listed - standards are not being updated to include the complete technical - details of IPv6, but to identify that a distinction must be made - between IPv4 and IPv6 in some places where IP is used generically. - Current requirements for IPv6 support can be found in [RFC4294], soon - to be updated by [I-D.ietf-6man-node-req-bis] and in [RFC6204]. Each - of these documents contains specific information, requirements, and - references to other draft and proposed standards governing many - aspects of IPv6 implementation. + Many of 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 sections 1, 2, and 4. + Since RFC1812 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 + IPv6 equivalent standards for the Internet layer, section 3.2 is a + protocol walk-through for IPv4 only, and section 3.2.1.1 explicitly + requires an IP datagram whose version number is not 4 to 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 a companion guideline for + proper IPv6 implementations. - From a practical perspective, the requirements proposed by this draft - mean that: + To ensure interoperability and flexibility, the best practice is: - New IP implementations MUST support IPv6. + New IP implementations must support IPv6. - Current IP implementations SHOULD support IPv6. + Updates to 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 + IPv6 support must be equivalent or better in quality and + functionality when compared to IPv4 support in a new or updated IP implementation. - Current and new IP Networking implementations SHOULD support IPv4 - and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for + New and updated 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. + 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 + Margaret Wasserman, Joe Touch, Fred Baker, Benson Schliesser, Eric + Rosen, David Harrington, Wesley Eddy. 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. - -6.2. Informative References +6. Informative References [APNIC-exhaust] APNIC, "APNIC Press Release", 2011, . [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. + 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] 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, . + [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. + [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. + [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. + Roberts, "Issues with IP Address Sharing", RFC 6269, + 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