Internet Engineering Task Force W. George Internet-Draft Sprint Updates: 1812, 1122 C. Donley (if approved) Cablelabs Intended status: Standards Track C. Liljenstolpe Expires: July 10, 2011 Telstra L. Howard Time Warner Cable January 6, 2011 IPv6 Support Required for all IP-capable nodes draft-george-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 and 1122 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 July 10, 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 July 10, 2011 [Page 1] Internet-Draft IPv6-required January 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 . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 George, et al. Expires July 10, 2011 [Page 2] Internet-Draft IPv6-required January 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 [IANA-exhaust] global pool of unique IPv4 addresses. 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 [I-D.ietf-intarea-shared-addressing-issues]and I-D.donley- nat444-impacts [I-D.donley-nat444-impacts] for some discussion on this topic. [add'l informative citations needed] IPv6 was proposed in 1995 [RFC 1883 [RFC1883]] 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. [RFC 2460 [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 of those who are deploying IPv6 have been forced to fund the initial IPv6 implementations for their vendors, because the vendor continued to view IPv6 support as optional. This added burden on the early adopters, plus the high cost of replacing installed-base that does not currently support IPv6 has been a significant barrier to wider deployment of IPv6. Even today, many vendors, especially in the consumer space are still selling "IP capable" devices which are not IPv6-capable, and are choosing not to update existing software to enable IPv6 support on software-updatable devices. 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, especially in the consumer space, where the operator often has no control over the hardware the consumer chooses to use. 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 George, et al. Expires July 10, 2011 [Page 3] Internet-Draft IPv6-required January 2011 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 RFC 1812 [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. This draft also updates RFC 1122 [RFC1122] to redefine generic "IP" support to include and require IPv6 for IP-capable nodes and routers. From a practical perspective, the requirements proposed by this draft mean that: New IP implementations MUST support IPv6, and current IP implementations SHOULD support IPv6. Helpful informative references can be found in RFC 4294 [RFC4294], and I-D.ietf-v6ops-ipv6-cpe-router [I-D.ietf-v6ops-ipv6-cpe-router] 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. Within the IETF, further protocol development on applications _exclusive_ to IPv4 SHOULD cease in order to concentrate on additional refinements and enhancements to IP version 6, with the goal of bringing IPv6 to complete parity with IPv4. This does not mean that further work SHOULD NOT have support for IPv4, merely that it MUST happen as a part of an IP version-agnostic implementation, or as an implementation that explicitly supports both IPv4 and IPv6. New features and protocols SHOULD NOT be introduced for use as IPv4- George, et al. Expires July 10, 2011 [Page 4] Internet-Draft IPv6-required January 2011 only unless they are specifically in support of IPv6 transition or IPv4-IPv6 interworking. A comprehensive list of these parity items and enhancements is outside the scope of this document, but this document recommends that the charters and work items of currently active IETF Working Groups (WGs) be evaluated to ensure that they are supporting the goal of full parity for IPv6. 3. Acknowledgements Thanks to Marla Azinger and Victor Kuarsingh for their additional review of the proto-draft. 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. 6.2. Informative References [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-intarea-shared-addressing-issues] George, et al. Expires July 10, 2011 [Page 5] Internet-Draft IPv6-required January 2011 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", draft-ietf-intarea-shared-addressing-issues-02 (work in progress), October 2010. [I-D.ietf-v6ops-ipv6-cpe-router] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in progress), December 2010. [IANA-exhaust] IANA, "IANA address allocation", 2011, . [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. Authors' Addresses Wesley George Sprint 12000 Sunrise Valley Drive Reston, VA 20196 US Phone: +1 703-592-4847 Email: wesley.e.george@sprint.com Chris Donley Cablelabs 858 Coal Creek Circle Louisville, CO 80027 US Phone: +1-303-661-9100 Email: C.Donley@cablelabs.com George, et al. Expires July 10, 2011 [Page 6] Internet-Draft IPv6-required January 2011 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 13241 Woodland Park Road Herndon, VA 20171 US Phone: +1-703-345-3513 Email: lee.howard@twcable.com George, et al. Expires July 10, 2011 [Page 7]