idnits 2.17.1 draft-george-ipv6-required-02.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 (June 1, 2011) is 4706 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 -- 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) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 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 Time Warner Cable 4 Updates: 1812, 1122, 4084 C. Donley 5 (if approved) Cablelabs 6 Intended status: Standards Track C. Liljenstolpe 7 Expires: December 3, 2011 Telstra 8 L. Howard 9 Time Warner Cable 10 June 1, 2011 12 IPv6 Support Required for all IP-capable nodes 13 draft-george-ipv6-required-02 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 December 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 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 global pool of unique IPv4 addresses [IANA-exhaust], and will be 77 followed by the exhaustion of the free pools for each Regional 78 Internet Registry (RIR), the first of which is APNIC [APNIC-exhaust]. 79 While transition technologies and other means to extend the lifespan 80 of IPv4 do exist, nearly all of them come with tradeoffs that prevent 81 them from being optimal long-term solutions when compared with 82 deployment of IP version 6 (IPv6) as a means to allow continued 83 growth on the Internet. See 84 [I-D.ietf-intarea-shared-addressing-issues] and 85 [I-D.donley-nat444-impacts] for some discussion on this topic. 87 IPv6 [RFC1883] was proposed in 1995 as, among other things, a 88 solution to the limitations on globally unique addressing that IPv4's 89 32-bit addressing space represented, and has been under continuous 90 refinement and deployment ever since. [RFC2460]. The exhaustion of 91 IPv4 and the continued growth of the internet worldwide has created 92 the driver for widespread IPv6 deployment. 94 However, the IPv6 deployment necessary to reduce reliance on IPv4 has 95 been hampered by a lack of ubiquitous hardware and software support 96 throughout the industry. Many vendors, especially in the consumer 97 space have continued to view IPv6 support as optional. Even today 98 they are still selling "IP capable" or "Internet Capable" devices 99 which are not IPv6-capable, which has continued to push out the point 100 at which the natural hardware refresh cycle will significantly 101 increase IPv6 support in the average home or enterprise network. 102 They are also choosing not to update existing software to enable IPv6 103 support on software-updatable devices, which is a problem because it 104 is not realistic to expect that the hardware refresh cycle will 105 single-handedly purge IPv4-only devices from the active network in a 106 reasonable amount of time. This is a significant problem, especially 107 in the consumer space, where the network operator often has no 108 control over the hardware the consumer chooses to use. For the same 109 reason that the average consumer is not making a purchasing decision 110 based on the presence of IPv6 support in their Internet-capable 111 devices and services, consumers are unlikely to replace their still- 112 functional Internet-capable devices simply to add IPv6 support - they 113 don't know or don't care about IPv6, they simply want their devices 114 to work as advertised. 116 This lack of support is making the eventual IPv6 transition 117 considerably more difficult, and drives the need for expensive and 118 complicated transition technologies to extend the life of IPv4-only 119 devices as well as eventually to interwork IPv4-only and IPv6-only 120 hosts. While IPv4 is expected to coexist on the Internet with IPv6 121 for many years, a transition from IPv4 as the dominant Internet 122 Protocol towards IPv6 as the dominant Internet Protocol will need to 123 occur. The sooner the majority of devices support IPv6, the less 124 protracted this transition period will be. 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 2. Requirements and Recommendation 134 This draft updates the following documents: 136 Updates [RFC1812] to note that IP nodes SHOULD no longer support IPv4 137 only. This is to ensure that those using it as a guideline for IP 138 implementations use the other informative references in this document 139 as a guideline for proper IPv6 implementations. 141 Updates [RFC1122] to redefine generic "IP" support to include and 142 require IPv6 for IP-capable nodes and routers. 144 Updates [RFC4084] to move "Version Support" from Section 4, 145 "Additional Terminology" to Section 2, "General Terminology." This 146 is to reflect the idea that version support is now critical to 147 defining the types of IP service, especially with respect to Full 148 Internet Connectivity. 150 From a practical perspective, the requirements proposed by this draft 151 mean that: 153 New IP implementations MUST support IPv6. 155 Current IP implementations SHOULD support IPv6. 157 IPv6 support MUST be equivalent or better in quality and 158 functionality when compared to IPv4 support in an IP 159 implementation. 161 Helpful informative references can be found in [RFC4294], soon to 162 be updated by [I-D.ietf-6man-node-req-bis] and in [RFC6204] 163 Current and new IP Networking implementations SHOULD support IPv4 164 and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for 165 proper and complete function. 167 It is expected that many existing devices and implementations will 168 not be able to support IPv6 for one or more valid technical 169 reasons, but for maximum flexibility and compatibility, a best 170 effort SHOULD be made to update existing hardware and software to 171 enable IPv6 support. 173 3. Acknowledgements 175 Thanks to the following people for their reviews and comments: Marla 176 Azinger, Brian Carpenter, Victor Kuarsingh, Jari Arkko, Scott Brim, 177 Margaret Wasserman, Joe Touch 179 4. IANA Considerations 181 This memo includes no request to IANA. 183 5. Security Considerations 185 There are no direct security considerations generated by this 186 document, but existing documented security considerations for 187 implementing IPv6 will apply. 189 6. References 191 6.1. Normative References 193 [RFC1122] Braden, R., "Requirements for Internet Hosts - 194 Communication Layers", STD 3, RFC 1122, October 1989. 196 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 197 RFC 1812, June 1995. 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 202 [RFC4084] Klensin, J., "Terminology for Describing Internet 203 Connectivity", BCP 104, RFC 4084, May 2005. 205 6.2. Informative References 207 [APNIC-exhaust] 208 APNIC, "APNIC Press Release", 2011, . 213 [I-D.donley-nat444-impacts] 214 Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A., 215 and V. Ganti, "Assessing the Impact of NAT444 on Network 216 Applications", draft-donley-nat444-impacts-01 (work in 217 progress), October 2010. 219 [I-D.ietf-6man-node-req-bis] 220 Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 221 Requirements", draft-ietf-6man-node-req-bis-11 (work in 222 progress), May 2011. 224 [I-D.ietf-intarea-shared-addressing-issues] 225 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 226 Roberts, "Issues with IP Address Sharing", 227 draft-ietf-intarea-shared-addressing-issues-05 (work in 228 progress), March 2011. 230 [IANA-exhaust] 231 IANA, "IANA address allocation", 2011, . 235 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 236 (IPv6) Specification", RFC 1883, December 1995. 238 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 239 (IPv6) Specification", RFC 2460, December 1998. 241 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 242 April 2006. 244 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 245 Troan, "Basic Requirements for IPv6 Customer Edge 246 Routers", RFC 6204, April 2011. 248 Authors' Addresses 250 Wesley George 251 Time Warner Cable 252 13820 Sunrise Valley Drive 253 Herndon, VA 20171 254 US 256 Phone: +1 703-561-2540 257 Email: wesley.george@twcable.com 259 Chris Donley 260 Cablelabs 261 858 Coal Creek Circle 262 Louisville, CO 80027 263 US 265 Phone: +1-303-661-9100 266 Email: C.Donley@cablelabs.com 268 Christopher Liljenstolpe 269 Telstra 270 Level 32/242 Exhibition Street 271 Melbourne, VIC 3000 272 AU 274 Phone: +61-3-8647-6389 275 Email: cdl@asgaard.org 277 Lee Howard 278 Time Warner Cable 279 13820 Sunrise Valley Drive 280 Herndon, VA 20171 281 US 283 Phone: +1-703-345-3513 284 Email: lee.howard@twcable.com