idnits 2.17.1 draft-george-ipv6-required-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1122, updated by this document, for RFC5378 checks: 1989-10-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2011) is 4802 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-01 == Outdated reference: A later version (-11) exists of draft-ietf-6man-node-req-bis-07 -- Obsolete informational reference (is this intentional?): RFC 1883 (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. George 3 Internet-Draft Sprint 4 Updates: 1812, 1122, 4084 C. Donley 5 (if approved) Cablelabs 6 Intended status: Standards Track C. Liljenstolpe 7 Expires: September 5, 2011 Telstra 8 L. Howard 9 Time Warner Cable 10 March 4, 2011 12 IPv6 Support Required for all IP-capable nodes 13 draft-george-ipv6-required-01 15 Abstract 17 Given the global lack of available IPv4 space, and limitations in 18 IPv4 extension and transition technologies, this document deprecates 19 the concept that an IP-capable node MAY support IPv4 _only_, and 20 redefines an IP-capable node as one which supports either IPv6 _only_ 21 or IPv4/IPv6 dual-stack. This document updates RFC1812, 1122 and 22 4084 to reflect the change in requirements. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 5, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 60 2. Requirements and Recommendation . . . . . . . . . . . . . . . . 4 61 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 66 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 IP version 4 (IPv4) has served to connect public and private hosts 72 all over the world for over 30 years. However, due to the success of 73 the Internet in finding new and innovative uses for IP networking, 74 billions of hosts are now connected via the Internet and requiring 75 unique addressing. This demand has led to the exhaustion of the IANA 76 [IANA-exhaust] global pool of unique IPv4 addresses. While 77 transition technologies and other means to extend the lifespan of 78 IPv4 do exist, nearly all of them come with tradeoffs that prevent 79 them from being optimal long-term solutions when compared with 80 deployment of IP version 6 (IPv6) as a means to allow continued 81 growth on the Internet. See 82 [I-D.ietf-intarea-shared-addressing-issues] and 83 [I-D.donley-nat444-impacts] for some discussion on this topic. 85 IPv6 was proposed in 1995 [RFC1883] as, among other things, a 86 solution to the limitations on globally unique addressing that IPv4's 87 32-bit addressing space represented, and has been under continuous 88 refinement and deployment ever since. [RFC2460]. The exhaustion of 89 IPv4 and the continued growth of the internet worldwide has created 90 the driver for widespread IPv6 deployment. 92 However, the IPv6 deployment necessary to reduce reliance on IPv4 has 93 been hampered by a lack of ubiquitous hardware and software support 94 throughout the industry. Many vendors, especially in the consumer 95 space have continued to view IPv6 support as optional. Even today 96 they are still selling "IP capable" or "Internet Capable" devices 97 which are not IPv6-capable, which has continued to push out the point 98 at which the natural hardware refresh cycle will significantly 99 increase IPv6 support. They are also choosing not to update existing 100 software to enable IPv6 support on software-updatable devices, which 101 is a problem because it is not realistic to expect that the hardware 102 refresh cycle will single-handedly purge IPv4-only devices from the 103 active network in a reasonable amount of time. This is a significant 104 problem, especially in the consumer space, where the network operator 105 often has no control over the hardware the consumer chooses to use. 106 For the same reason that the average consumer is not making a 107 purchasing decision based on the presence of IPv6 support in their 108 Internet-capable devices and services, consumers are unlikely to 109 replace their still-functional Internet-capable devices simply to add 110 IPv6 support - they don't know or don't care about IPv6, they simply 111 want their devices to work as advertised. 113 This lack of support is making the eventual IPv6 transition 114 considerably more difficult, and drives the need for expensive and 115 complicated transition technologies to extend the life of IPv4-only 116 devices as well as eventually to interwork IPv4-only and IPv6-only 117 hosts. While IPv4 is expected to coexist on the Internet with IPv6 118 for many years, a transition from IPv4 as the dominant Internet 119 Protocol towards IPv6 as the dominant Internet Protocol will need to 120 occur. The sooner the majority of devices support IPv6, the less 121 protracted this transition period will be. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Requirements and Recommendation 131 This draft updates the following documents: 133 Updates [RFC1812] to note that IP nodes SHOULD no longer support IPv4 134 only. This is to ensure that those using it as a guideline for IP 135 implementations use the other informative references in this document 136 as a guideline for proper IPv6 implementations. 138 Updates [RFC1122] to redefine generic "IP" support to include and 139 require IPv6 for IP-capable nodes and routers. 141 Updates [RFC4084] to move "Version Support" from Section 4, 142 "Additional Terminology" to Section 2, "General Terminology." This 143 is to reflect the idea that version support is now critical to 144 defining the types of IP service, especially with respect to Full 145 Internet Connectivity. 147 From a practical perspective, the requirements proposed by this draft 148 mean that: 150 New IP implementations MUST support IPv6. 152 Current IP implementations SHOULD support IPv6. 154 IPv6 support MUST be equivalent in quality and functionality to 155 IPv4 support. 157 Helpful informative references can be found in [RFC4294], soon to 158 be updated by [I-D.ietf-6man-node-req-bis] and 159 [I-D.ietf-v6ops-ipv6-cpe-router] 161 Current and new IP Networking implementations SHOULD support IPv4 162 and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for 163 proper and complete function. 165 It is expected that many existing devices and implementations will 166 not be able to support IPv6 for one or more valid technical 167 reasons, but for maximum flexibility and compatibility, a best 168 effort SHOULD be made to update existing hardware and software to 169 enable IPv6 support. 171 Within the IETF, further development on protocols and applications 172 _exclusive_ to IPv4 SHOULD cease, except for vital operational or 173 security issues. This will enable IETF WGs to concentrate on 174 additional refinements and enhancements to IP version 6, with the 175 goal of bringing IPv6 to parity with IPv4 in function, support, and 176 deployment. This does not mean that future work SHOULD NOT have 177 support for IPv4, merely that it MUST happen as a part of an IP 178 version-agnostic implementation, or as an implementation that 179 explicitly supports both IPv4 and IPv6. New features and protocols 180 SHOULD NOT be introduced for use as IPv4-only unless they are 181 specifically in support of IPv6 transition or IPv4-IPv6 interworking. 182 A comprehensive list of these parity items and enhancements is 183 outside the scope of this document, but this document recommends that 184 the charters and work items of currently active IETF Working Groups 185 (WGs) be evaluated to ensure that they are supporting the goal of 186 full parity for IPv6. 188 3. Acknowledgements 190 Thanks to the following people for their reviews and comments: Marla 191 Azinger, Brian Carpenter, Victor Kuarsingh. 193 4. IANA Considerations 195 This memo includes no request to IANA. 197 5. Security Considerations 199 There are no direct security considerations generated by this 200 document, but existing documented security considerations for 201 implementing IPv6 will apply. 203 6. References 205 6.1. Normative References 207 [RFC1122] Braden, R., "Requirements for Internet Hosts - 208 Communication Layers", STD 3, RFC 1122, October 1989. 210 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 211 RFC 1812, June 1995. 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997. 216 [RFC4084] Klensin, J., "Terminology for Describing Internet 217 Connectivity", BCP 104, RFC 4084, May 2005. 219 6.2. Informative References 221 [I-D.donley-nat444-impacts] 222 Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A., 223 and V. Ganti, "Assessing the Impact of NAT444 on Network 224 Applications", draft-donley-nat444-impacts-01 (work in 225 progress), October 2010. 227 [I-D.ietf-6man-node-req-bis] 228 Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 229 Requirements RFC 4294-bis", 230 draft-ietf-6man-node-req-bis-07 (work in progress), 231 December 2010. 233 [I-D.ietf-intarea-shared-addressing-issues] 234 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 235 Roberts, "Issues with IP Address Sharing", 236 draft-ietf-intarea-shared-addressing-issues-05 (work in 237 progress), March 2011. 239 [I-D.ietf-v6ops-ipv6-cpe-router] 240 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 241 Troan, "Basic Requirements for IPv6 Customer Edge 242 Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in 243 progress), December 2010. 245 [IANA-exhaust] 246 IANA, "IANA address allocation", 2011, . 250 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 251 (IPv6) Specification", RFC 1883, December 1995. 253 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 254 (IPv6) Specification", RFC 2460, December 1998. 256 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 257 April 2006. 259 Authors' Addresses 261 Wesley George 262 Sprint 263 12000 Sunrise Valley Drive 264 Reston, VA 20196 265 US 267 Phone: +1 703-592-4847 268 Email: wesley.e.george@sprint.com 270 Chris Donley 271 Cablelabs 272 858 Coal Creek Circle 273 Louisville, CO 80027 274 US 276 Phone: +1-303-661-9100 277 Email: C.Donley@cablelabs.com 279 Christopher Liljenstolpe 280 Telstra 281 Level 32/242 Exhibition Street 282 Melbourne, VIC 3000 283 AU 285 Phone: +61-3-8647-6389 286 Email: cdl@asgaard.org 288 Lee Howard 289 Time Warner Cable 290 13241 Woodland Park Road 291 Herndon, VA 20171 292 US 294 Phone: +1-703-345-3513 295 Email: lee.howard@twcable.com