idnits 2.17.1 draft-george-ipv6-support-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 (January 6, 2014) is 3763 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) ** Downref: Normative reference to an Informational RFC: RFC 3789 ** Downref: Normative reference to an Informational RFC: RFC 3790 ** Downref: Normative reference to an Informational RFC: RFC 3791 ** Downref: Normative reference to an Informational RFC: RFC 3792 ** Downref: Normative reference to an Informational RFC: RFC 3793 ** Downref: Normative reference to an Informational RFC: RFC 3794 ** Downref: Normative reference to an Informational RFC: RFC 3795 ** Downref: Normative reference to an Informational RFC: RFC 3796 == Outdated reference: A later version (-05) exists of draft-george-mpls-ipv6-only-gap-02 == Outdated reference: A later version (-09) exists of draft-ietf-sunset4-gapanalysis-03 == Outdated reference: A later version (-03) exists of draft-klatsky-dispatch-ipv6-impact-ipv4-02 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. George 3 Internet-Draft L. Howard 4 Intended status: Best Current Practice Time Warner Cable 5 Expires: July 10, 2014 January 6, 2014 7 IPv6 Support Within IETF work 8 draft-george-ipv6-support-02 10 Abstract 12 This document recommends that IETF formally require its standards 13 work to be IP version agnostic or to explicitly include support for 14 IPv6, with some exceptions. It further recommends that IETF revisit 15 and update the previous attempts to review existing standards for 16 IPv6 compliance. It makes this recommendation in order to ensure 17 that it is possible to operate without dependencies on IPv4. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 10, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. IPv6-only operation . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Functional Parity with IPv4 . . . . . . . . . . . . . . . 3 57 2.2. IPv4 Sunset . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. IETF Actions . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Requirements and Recommendations . . . . . . . . . . . . . . 6 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 8.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 [RFC6540] gives guidance to implementers that in order to ensure 71 interoperability and proper function after IPv4 exhaustion, IP- 72 capable devices need to support IPv6, and cannot be reliant on IPv4, 73 because global IPv4 exhaustion creates many circumstances where the 74 use of IPv6 will no longer be optional. Since this is an IETF Best 75 Current Practice recommendation, it is imperative that the results of 76 IETF efforts enable implementers to follow that recommendation. This 77 document provides recommendations and guidance as to how IETF itself 78 should handle future work as it relates to Internet Protocol 79 versions, and discusses the need for gap analyses on existing work. 81 When considering support for IPv4 vs IPv6 within IETF work, the 82 general goal is to provide tools that enable networks and 83 applications to operate seamlessly in any combination of IPv4-only, 84 dual-stack, or IPv6-only as their needs dictate. However, as the 85 IPv4 to IPv6 transition continues, it will become increasingly 86 difficult to ensure interoperability and backward compatibility with 87 IPv4-only networks and applications. As IPv6 deployment grows, IETF 88 will naturally focus on features and protocols that enhance and 89 extend IPv6, along with continuing work on items that are IP version 90 agnostic. New features and protocols will not typically be 91 introduced for use as IPv4-only. However, as of this document's 92 writing, there is no formal requirement for all IETF work to support 93 IPv6, either implicitly by being network-layer agnostic or explicitly 94 by having an IPv6-specific implementation. Additionally, although 95 reviews in RFC's 3789 [RFC3789] through RFC3796 ensured that IETF 96 standards then in use could support IPv6, no IETF-wide effort has 97 been undertaken to ensure that the issues identified in those drafts 98 are all addressed, nor to ensure that standards written after RFC3100 99 (where the previous review efforts stopped) function properly on 100 IPv6-only networks. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. IPv6-only operation 110 At this document's writing, IPv6 has seen significant deployment. 111 Most of these deployments are dual-stack, with IPv4 and IPv6 112 coexisting on the same networks. However, dual-stack is a waypoint 113 in the transition from IPv4 to IPv6. The eventual end state is 114 networks and end points that are IPv6-only. Some operators may take 115 a long time to turn off IPv4, if they ever do, but the IETF must make 116 sure that its standards can be deployed by even the first operators 117 to turn off IPv4. Problems (and solutions) should be identified 118 before they are encountered by the earliest adopters. 120 2.1. Functional Parity with IPv4 122 In order for IPv6-only operation to be realistic, IPv6 MUST have at 123 least functional parity with IPv4. "Functional parity" means that 124 any function that IPv4 enabled MUST also be enabled by IPv6. This 125 does not mean that every feature that exists in IPv4 will exist in 126 IPv6; different features may enable the same function. For instance, 127 IPv4 supports some features that are no longer in use. In some cases 128 it has not been practical to remove them in IPv4, or even to declare 129 them historic, but it is unnecessary to carry them forward into IPv6. 130 IPv6 also eliminates the need for some features that exist in IPv4; 131 no effort to create unneeded features is required. Functional parity 132 does not mean that all functions in IPv6 must also be possible in 133 IPv4. Indeed, with IPv6 becoming the predominant protocol, new 134 functionality should be developed in IPv6, and IETF effort SHOULD NOT 135 be spent retrofitting features into the legacy protocol. The key at 136 this point is to ensure that existing standards and protocols have 137 been actively reviewed, and any parity gaps either identified so that 138 they can be fixed, or documented as unnecessary to address because it 139 is unused or superseded by other features. 141 2.2. IPv4 Sunset 143 Somewhat distinct from identifying the needed features for IPv6-only 144 functional parity is the effort to identify what is necessary to 145 disable or sunset IPv4 in a given network. Since many of the 146 protocols in use today were designed to be fault-tolerant and very 147 robust, actually removing them from a network once they are no longer 148 needed is sometimes complex. Many implementations may not even have 149 "off switches" because the assumption was that they would never be 150 switched off in a normal network implementation. The Sunset4 Working 151 Group was chartered to address these issues: 153 "The Working Group will point out specific areas of concern, provide 154 recommendations, and standardize protocols that facilitate the 155 graceful "sunsetting" of the IPv4 Internet in areas where IPv6 has 156 been deployed. This includes the act of shutting down IPv4 itself, 157 as well as the ability of IPv6-only portions of the Internet to 158 continue to connect with portions of the Internet that remain 159 IPv4-only. ... Disabling IPv4 in applications, hosts, and networks is 160 new territory for much of the Internet today, and it is expected that 161 problems will be uncovered including those related to basic IPv4 162 functionality, interoperability, as well as potential security 163 concerns. The working group will report on common issues, provide 164 recommendations, and, when necessary, protocol extensions in order to 165 facilitate disabling IPv4 in networks where IPv6 has been deployed." 167 3. IETF Actions 169 In addition to a requirement for IPv6 support in the following 170 section, this document recommends two major actions: 172 First, the IETF must review RFCs 3789-3796 to ensure that any gaps in 173 specifications identified in these documents and still in active use 174 have been updated as necessary to enable operation in IPv6-only 175 environments (or if no longer in use, are declared historic). A 176 document updating each of the below area-specific RFCs to identify 177 which gaps have been addressed and which ones are either still 178 outstanding or are now irrelevant may be an appropriate way to track 179 this activity. 181 o Internet Area [RFC3790] 183 o Routing Area [RFC3791] 185 o Security Area [RFC3792] 187 o Sub-IP Area [RFC3793] 188 o Transport Area [RFC3794] 190 o Applications Area [RFC3795] 192 o Operations and Management Area [RFC3796] 194 Second, the IETF must review documents written after the existing 195 review stopped (according to RFC 3790, this review stopped with 196 approximately RFC 3100) to identify specifications where IPv6-only 197 operation is not possible, and update them as necessary and 198 appropriate, or document why an identified gap is not an issue i.e. 199 not necessary for functional parity with IPv4. 201 This represents a significant amount of work in addition to IETF's 202 existing workload, and there are basically two options for how to 203 accomplish this significant document review. If existing IETF 204 resources are to take on this work, one method would be for Area 205 Directors to charter their existing Working Groups to undertake this 206 review for relevant work, and charter their Directorates or other 207 volunteers to review work that is not within the charter of any 208 active Working Group. Another method would be to charter one (new or 209 existing) Working Group or directorate to oversee this activity, with 210 the assumption that the WG or directorate will pull in expertise from 211 other areas and WGs as needed. The alternative is to use a similar 212 model to the previous analysis in RFCs 3789-3796, in which ISOC 213 funded dedicated resources whose primary duty was to complete this 214 document audit. 216 RFC3789 [RFC3789] section 2 provides some guidance on methodology 217 that can serve as a useful starting point for this effort. 219 "To perform this study, each class of IETF standards are 220 investigated in order of maturity: Full, Draft, and Proposed, as 221 well as Experimental. Informational and BCP RFCs are not 222 addressed. RFCs that have been obsoleted by either newer versions 223 or because they have transitioned through the standards process 224 are not covered. RFCs which have been classified as Historic are 225 also not included." 227 This document does not recommend excluding Informational and BCP RFCs 228 as the previous effort did, due to changes in the way that these 229 documents are used and their relative importance in the RFC Series. 230 Instead, any documents that are still active (i.e. not declared 231 historic or obsolete) and the product of IETF consensus (i.e. not a 232 product of the ISE Series) should be included. In addition, the 233 reviews undertaken by RFC 3789-96 were looking for "IPv4 dependency" 234 or "usage of IPv4 addresses in standards". This document recommends 235 a slightly more specific set of criteria for review: review should 236 include consideration of whether the specification can operate in an 237 environment without IPv4. Reviews should include guidance on the use 238 of 32-bit identifiers that are commonly populated by IPv4 addresses. 239 Reviews should include consideration of protocols on which 240 specifications depend or interact, to identify indirect dependencies 241 on IPv4. Finally, reviews should consider how to migrate from an 242 IPv4 environment to an IPv6 environment. 244 By necessity, this sort of gap analysis work is already happening in 245 several places, e.g. draft-ietf-sunset4-gapanalysis 246 [I-D.ietf-sunset4-gapanalysis], draft-george-mpls-ipv6-only-gap 247 [I-D.george-mpls-ipv6-only-gap], and draft-klatsky-dispatch-ipv6 248 -impact-ipv4 [I-D.klatsky-dispatch-ipv6-impact-ipv4]. These efforts 249 are limited in scope, but may serve as a model for the larger effort 250 necessary. 252 4. Requirements and Recommendations 254 While the primary goal of this effort is to ensure that existing IETF 255 work has been properly evaluated and updated for IPv6-only support, 256 ongoing focus is required for future work, whether via IESG 257 evaluation, individual document reviews, or future WG charters. Due 258 to the existing operational base of IPv4, it is not realistic to 259 completely bar further work on IPv4 within the IETF at this time, nor 260 to formally declare it historic. Until the time when IPv4 is no 261 longer in wide use and/or declared historic, the IETF needs to 262 continue to update IPv4-only protocols and features for vital 263 operational or security issues. Similarly, the IETF needs to 264 complete the work related to IPv4-to-IPv6 transition tools for 265 migrating more traffic to IPv6. As the transition to IPv6-capable 266 networks accelerates, it is also likely that some changes may be 267 necessary in IPv4 protocols to facilitate decommissioning IPv4 in a 268 way that does not create unacceptable impact to applications or 269 users. These sorts of IPv4-focused activities, in support of 270 security, transition, and decommissioning, should continue, 271 accompanied by problem statements based on operational experience. 272 Generally the focus should move away from IPv4-only work. 274 IETF should make updates to IPv4 protocols and features to 275 facilitate IPv4 decommissioning 277 IETF work SHOULD explicitly support IPv6 or SHOULD be IP version 278 agnostic (because it is implemented above the network layer), 279 except IPv4-specific transition or address-sharing technologies. 281 IETF SHOULD NOT initiate new IPv4 extension technology 282 development. 284 IETF work SHOULD function completely on IPv6-only nodes and 285 networks, unless consensus exists that it is unnecessary to use a 286 given feature or protocol on IPv6-only networks. 288 IETF SHOULD identify and update IPv4-only protocols and 289 applications to support IPv6 unless consensus exists that it is 290 unnecessary for a given feature or protocol. 292 5. Acknowledgements 294 Thanks to the following people for their comments: Jari Arkko, Ralph 295 Droms, Scott Brim, Margaret Wasserman, Brian Haberman. Thanks also 296 to Randy Bush, Mark Townsley, and Dan Wing for their discussion in 297 IntArea WG at IETF 81 in Taipei, TW regarding transition 298 technologies, IPv4 life extension, and IPv6 support. 300 6. IANA Considerations 302 This memo includes no request to IANA. 304 7. Security Considerations 306 This document generates no new security considerations because it is 307 not defining a new protocol. As existing work is analyzed for its 308 ability to operate properly on IPv6-only networks, new security 309 issues may be identified. 311 8. References 313 8.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, March 1997. 318 [RFC3789] Nesser, P. and A. Bergstrom, "Introduction to the Survey 319 of IPv4 Addresses in Currently Deployed IETF Standards 320 Track and Experimental Documents", RFC 3789, June 2004. 322 [RFC3790] Mickles, C. and P. Nesser, "Survey of IPv4 Addresses in 323 Currently Deployed IETF Internet Area Standards Track and 324 Experimental Documents", RFC 3790, June 2004. 326 [RFC3791] Olvera, C. and P. Nesser, "Survey of IPv4 Addresses in 327 Currently Deployed IETF Routing Area Standards Track and 328 Experimental Documents", RFC 3791, June 2004. 330 [RFC3792] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 331 Currently Deployed IETF Security Area Standards Track and 332 Experimental Documents", RFC 3792, June 2004. 334 [RFC3793] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 335 Currently Deployed IETF Sub-IP Area Standards Track and 336 Experimental Documents", RFC 3793, June 2004. 338 [RFC3794] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 339 Currently Deployed IETF Transport Area Standards Track and 340 Experimental Documents", RFC 3794, June 2004. 342 [RFC3795] Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in 343 Currently Deployed IETF Application Area Standards Track 344 and Experimental Documents", RFC 3795, June 2004. 346 [RFC3796] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 347 Currently Deployed IETF Operations & Management Area 348 Standards Track and Experimental Documents", RFC 3796, 349 June 2004. 351 8.2. Informative References 353 [I-D.george-mpls-ipv6-only-gap] 354 George, W., Pignataro, C., Asati, R., Raza, K., Bonica, 355 R., Papneja, R., Dhody, D., and V. Manral, "Gap Analysis 356 for Operating IPv6-only MPLS Networks", draft-george-mpls- 357 ipv6-only-gap-02 (work in progress), October 2013. 359 [I-D.ietf-sunset4-gapanalysis] 360 Dionne, J., Perreault, S., Tsou, T., and C. Zhou, "Gap 361 Analysis for IPv4 Sunset", draft-ietf- 362 sunset4-gapanalysis-03 (work in progress), July 2013. 364 [I-D.klatsky-dispatch-ipv6-impact-ipv4] 365 Klatsky, C., Shekh-Yusef, R., Hutton, A., and G. 366 Salgueiro, "Interoperability Impacts of IPv6 Interworking 367 with Existing IPv4 SIP Implementations", draft-klatsky- 368 dispatch-ipv6-impact-ipv4-02 (work in progress), October 369 2013. 371 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 372 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 373 RFC 6540, April 2012. 375 Authors' Addresses 377 Wesley George 378 Time Warner Cable 379 13820 Sunrise Valley Drive 380 Herndon, VA 20171 381 US 383 Phone: +1 703-561-2540 384 Email: wesley.george@twcable.com 386 Lee Howard 387 Time Warner Cable 388 13820 Sunrise Valley Drive 389 Herndon, VA 20171 390 US 392 Phone: +1-703-345-3513 393 Email: lee.howard@twcable.com