idnits 2.17.1 draft-ietf-intarea-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 -- The document date (December 8, 2011) is 4494 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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-03 -- 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 (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area Working Group W. George 3 Internet-Draft Time Warner Cable 4 Intended status: BCP C. Donley 5 Expires: June 10, 2012 Cablelabs 6 C. Liljenstolpe 7 Telstra 8 L. Howard 9 Time Warner Cable 10 December 8, 2011 12 IPv6 Support Required for all IP-capable Nodes 13 draft-ietf-intarea-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 advises 19 that IPv6 support is no longer considered optional. It also cautions 20 that there are places in existing IETF documents where the term "IP" 21 is used in a way that could be misunderstood by implementers as the 22 term "IP" becomes a generic which can mean IPv4 + IPv6, IPv6-only, or 23 IPv4-only, depending on context and application. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 10, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Clarifications and Recommendation . . . . . . . . . . . . . . . 4 61 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 IP version 4 (IPv4) has served to connect public and private hosts 70 all over the world for over 30 years. However, due to the success of 71 the Internet in finding new and innovative uses for IP networking, 72 billions of hosts are now connected via the Internet and requiring 73 unique addressing. This demand has led to the exhaustion of the IANA 74 global pool of unique IPv4 addresses [IANA-exhaust], and will be 75 followed by the exhaustion of the free pools for each Regional 76 Internet Registry (RIR), the first of which is APNIC [APNIC-exhaust]. 77 While transition technologies and other means to extend the lifespan 78 of 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 [RFC6269] and 82 [I-D.donley-nat444-impacts] for some discussion on this topic. 84 IPv6 [RFC1883] was proposed in 1995 as, among other things, a 85 solution to the limitations on globally unique addressing that IPv4's 86 32-bit addressing space represented, and has been under continuous 87 refinement (e.g., [RFC2460]) and deployment ever since. The 88 exhaustion of IPv4 and the continued growth of the internet worldwide 89 has created the driver for widespread IPv6 deployment. 91 However, the IPv6 deployment necessary to reduce reliance on IPv4 has 92 been hampered by a lack of ubiquitous hardware and software support 93 throughout the industry. Many vendors, especially in the consumer 94 space have continued to view IPv6 support as optional. Even today 95 they are still selling "IP capable" or "Internet Capable" devices 96 which are not IPv6-capable, which has continued to push out the point 97 at which the natural hardware refresh cycle will significantly 98 increase IPv6 support in the average home or enterprise network. 99 They are also choosing not to update existing software to enable IPv6 100 support on software-updatable devices, which is a problem because it 101 is not realistic to expect that the hardware refresh cycle will 102 single-handedly purge IPv4-only devices from the active network in a 103 reasonable amount of time. This is a significant problem, especially 104 in the consumer space, where the network operator often has no 105 control over the hardware the consumer chooses to use. For the same 106 reason that the average consumer is not making a purchasing decision 107 based on the presence of IPv6 support in their Internet-capable 108 devices and services, consumers are unlikely to replace their still- 109 functional Internet-capable devices simply to add IPv6 support - they 110 don't know or don't care about IPv6, they simply want their devices 111 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 2. Clarifications and Recommendation 125 To ensure interoperability and proper function after IPv4 exhaustion, 126 support for IPv6 is virtually a requirement. Rather than update the 127 existing IPv4 protocol specification standards to include IPv6, IETF 128 has defined a completely separate set of standalone documents which 129 cover IPv6. Therefore, implementers are cautioned that a distinction 130 must be made between IPv4 and IPv6 in some IETF documents where IP is 131 used generically. Current requirements for IPv6 support can be found 132 in [RFC4294], soon to be updated by [I-D.ietf-6man-node-req-bis] and 133 in [RFC6204]. Each of these documents contains specific information, 134 requirements, and references to other draft and proposed standards 135 governing many aspects of IPv6 implementation. 137 Many of IETF's early documents use the generic term "IP" synonymously 138 with the more specific "IPv4." Some examples of this potential 139 confusion can be found in [RFC1812], especially sections 1, 2, and 4. 140 Since RFC1812 is an IPv4 router specification, the generic use of IP 141 in this standard may cause confusion as the term "IP" can now be 142 interpreted to mean: IPv4 + IPv6, IPv6-only, or IPv4-only. 143 Additionally, [RFC1122], is no longer a complete definition of "IP" 144 or the Internet Protocol suite by itself, because it does not include 145 IPv6. For example, section 3.1 does not contain references to the 146 IPv6 equivalent standards for the Internet layer, section 3.2 is a 147 protocol walk-through for IPv4 only, and section 3.2.1.1 explicitly 148 requires an IP datagram whose version number is not 4 to be 149 discarded, which would be detrimental to IPv6 forwarding. Additional 150 instances of this type of problem exist that are not discussed here. 151 Since existing RFCs say "IP" in places where they may mean IPv4, 152 implementers are cautioned to ensure that they know whether a given 153 standard is inclusive or exclusive of IPv6. To ensure 154 interoperability, implementers building IP nodes will need to support 155 both IPv4 and IPv6. If the standard does not include an integral 156 definition of both IPv4 and IPv6, implementers need to use the other 157 informative references in this document as a companion guideline for 158 proper IPv6 implementations. 160 To ensure interoperability and flexibility, the best practice is: 162 New IP implementations must support IPv6. 164 Updates to current IP implementations should support IPv6. 166 IPv6 support must be equivalent or better in quality and 167 functionality when compared to IPv4 support in a new or updated IP 168 implementation. 170 New and updated IP Networking implementations should support IPv4 171 and IPv6 coexistence (dual-stack), but must not require IPv4 for 172 proper and complete function. 174 Implementers are encouraged to update existing hardware and 175 software to enable IPv6 wherever technically feasible. 177 3. Acknowledgements 179 Thanks to the following people for their reviews and comments: Marla 180 Azinger, Brian Carpenter, Victor Kuarsingh, Jari Arkko, Scott Brim, 181 Margaret Wasserman, Joe Touch, Fred Baker, Benson Schliesser, Eric 182 Rosen, David Harrington, Wesley Eddy. 184 4. IANA Considerations 186 This memo includes no request to IANA. 188 5. Security Considerations 190 There are no direct security considerations generated by this 191 document, but existing documented security considerations for 192 implementing IPv6 will apply. 194 6. Informative References 196 [APNIC-exhaust] 197 APNIC, "APNIC Press Release", 2011, . 202 [I-D.donley-nat444-impacts] 203 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 204 Colorado, "Assessing the Impact of Carrier-Grade NAT on 205 Network Applications", draft-donley-nat444-impacts-03 206 (work in progress), November 2011. 208 [I-D.ietf-6man-node-req-bis] 209 Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 210 Requirements", draft-ietf-6man-node-req-bis-11 (work in 211 progress), May 2011. 213 [IANA-exhaust] 214 IANA, "IANA address allocation", 2011, . 218 [RFC1122] Braden, R., "Requirements for Internet Hosts - 219 Communication Layers", STD 3, RFC 1122, October 1989. 221 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 222 RFC 1812, June 1995. 224 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 225 (IPv6) Specification", RFC 1883, December 1995. 227 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 228 (IPv6) Specification", RFC 2460, December 1998. 230 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 231 April 2006. 233 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 234 Troan, "Basic Requirements for IPv6 Customer Edge 235 Routers", RFC 6204, April 2011. 237 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 238 Roberts, "Issues with IP Address Sharing", RFC 6269, 239 June 2011. 241 Authors' Addresses 243 Wesley George 244 Time Warner Cable 245 13820 Sunrise Valley Drive 246 Herndon, VA 20171 247 US 249 Phone: +1 703-561-2540 250 Email: wesley.george@twcable.com 251 Chris Donley 252 Cablelabs 253 858 Coal Creek Circle 254 Louisville, CO 80027 255 US 257 Phone: +1-303-661-9100 258 Email: C.Donley@cablelabs.com 260 Christopher Liljenstolpe 261 Telstra 262 Level 32/242 Exhibition Street 263 Melbourne, VIC 3000 264 AU 266 Phone: +61-3-8647-6389 267 Email: cdl@asgaard.org 269 Lee Howard 270 Time Warner Cable 271 13820 Sunrise Valley Drive 272 Herndon, VA 20171 273 US 275 Phone: +1-703-345-3513 276 Email: lee.howard@twcable.com