idnits 2.17.1 draft-iab-protocol-transitions-08.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 (March 8, 2017) is 2605 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4632' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC7230' is defined on line 601, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-tls-grease-00 -- Obsolete informational reference (is this intentional?): RFC 1883 (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 1933 (Obsoleted by RFC 2893) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2145 (Obsoleted by RFC 7230) -- Obsolete informational reference (is this intentional?): RFC 2893 (Obsoleted by RFC 4213) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board D. Thaler, Ed. 3 Internet-Draft Microsoft 4 Intended status: Informational March 8, 2017 5 Expires: September 9, 2017 7 Planning for Protocol Adoption and Subsequent Transitions 8 draft-iab-protocol-transitions-08.txt 10 Abstract 12 Over the many years since the introduction of the Internet Protocol, 13 we have seen a number of transitions throughout the protocol stack, 14 such as deploying a new protocol, or updating or replacing an 15 existing protocol. Many protocols and technologies were not designed 16 to enable smooth transition to alternatives or to easily deploy 17 extensions, and thus some transitions, such as the introduction of 18 IPv6, have been difficult. This document attempts to summarize some 19 basic principles to enable future transitions, and also summarizes 20 what makes for a good transition plan. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 9, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Transition vs. Co-existence . . . . . . . . . . . . . . . . . 5 59 4. Translation/Adaptation Location . . . . . . . . . . . . . . . 6 60 5. Transition Plans . . . . . . . . . . . . . . . . . . . . . . 7 61 5.1. Understanding of Existing Deployment . . . . . . . . . . 7 62 5.2. Explanation of Incentives . . . . . . . . . . . . . . . . 7 63 5.3. Description of Phases and Proposed Criteria . . . . . . . 8 64 5.4. Measurement of Success . . . . . . . . . . . . . . . . . 8 65 5.5. Contingency Planning . . . . . . . . . . . . . . . . . . 8 66 5.6. Communicating the Plan . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 10. IAB Members at the Time of This Writing . . . . . . . . . . . 10 72 11. Informative References . . . . . . . . . . . . . . . . . . . 10 73 Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 14 74 A.1. Explicit Congestion Notification . . . . . . . . . . . . 14 75 A.2. Internationalized Domain Names . . . . . . . . . . . . . 15 76 A.3. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 A.4. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 A.4.1. Protocol Versioning, Extensions and 'Grease' . . . . 20 79 A.4.2. Limits on Changes in Major Versions . . . . . . . . . 20 80 A.4.3. Planning for Replacement . . . . . . . . . . . . . . 21 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 83 1. Introduction 85 A "transition" is the process or period of changing from one state or 86 condition to another. There are several types of such transitions, 87 including both technical transitions (e.g., changing protocols or 88 deploying an extension) and organizational transitions (e.g., 89 changing what organization manages a web site). This document 90 focuses solely on technical transitions, although some principles 91 might apply to other types as well. 93 In this document we use the term transition generically to apply to 94 any of: 96 o adoption of a new protocol where none existed before, 97 o deployment of a new protocol that obsoletes a previous protocol, 99 o deployment of a updated version of an existing protocol, or 101 o decommissioning of an obsolete protocol. 103 There have been many IETF and IAB RFCs and IAB statements discussing 104 transitions of various sorts. Most are protocol-specific documents 105 about specific transitions. For example, some relevant ones in which 106 the IAB has been involved include: 108 o IAB RFC 3424 [RFC3424] recommended that any technology for so- 109 called "unilateral self-address fixing (UNSAF)" across NATs 110 include an exit strategy to transition away from such a mechanism. 111 Since the IESG, not the IAB, approves IETF documents, the IESG 112 thus became the body to enforce (or not) such a requirement. 114 o IAB RFC 4690 [RFC4690] gave recommendations around 115 internationalized domain names. It discussed issues around the 116 process of transitioning to new versions of Unicode, and this 117 resulted in the creation of the IETF Precis WG to address this 118 problem. 120 o The IAB statement on "Follow-up-work on NAT-PT" 121 [IabIpv6TransitionStatement] pointed out gaps at the time in 122 transitioning to IPv6, and this resulted in the rechartering of 123 the IETF Behave WG to solve this problem. 125 More recently, the IAB has done work on more generally applicable 126 principles, including two RFCs. 128 IAB RFC 5218 [RFC5218] on "What Makes for a Successful Protocol?" 129 studied specifically what factors contribute to, and detract from, 130 the success of a protocol and it made a number of recommendations. 131 It discussed two types of transitions: "initial success" (the 132 transition to the technology) and extensibility (the transition to 133 updated versions of it). The principles and recommendations in that 134 document are generally applicable to all technical transitions. Some 135 important principles included: 137 1. Incentive: Transition is easiest when the benefits come to those 138 bearing the costs. That is, the benefits should outweigh the 139 costs at *each* entity. Some successful cases did this by 140 providing incentives (e.g., tax breaks), or by reducing costs 141 (e.g., freely available source), or by imposing costs of not 142 transitioning (e.g., regulation), or even by narrowing the 143 scenarios of applicability to just the cases where benefits do 144 outweigh costs at all relevant entities. 146 2. Incremental Deployability: Backwards compatibility makes 147 transition easier. Furthermore, transition is easiest when 148 changing only one entity still benefits that entity. In the 149 easiest case, the benefit immediately outweighs the cost and so 150 entities are naturally incented to transition. More commonly, 151 the benefits only outweigh the costs once a significant number of 152 other entities also transition. Unfortunately, in such cases, 153 the natural incentive is often to delay transitioning. 155 3. Total Cost: It is import to consider costs that go beyond the 156 core hardware and software, such as operational tools and 157 processes, personnel training, business model (accounting/ 158 billing) dependencies, and legal (regulation, patents, etc.) 159 costs. 161 4. Extensibility: Design for extensibility [RFC6709] so that things 162 can be fixed up later. 164 IAB RFC 7305 [RFC7305] reported on a IAB workshop on Internet 165 Technology Adoption and Transition (ITAT). Like RFC 5218, this 166 workshop also discussed economic aspects of transition, not just 167 technical aspects. Some important observations included: 169 1. Early-Adopter Incentives: Part of Bitcoin's strategy was extra 170 incentives for early adopters compared to late adopters. That 171 is, providing a long-term advantage to early adopters can help 172 stimulate transition even when the initial costs outweigh the 173 initial benefit. 175 2. Policy Partners: Policy-making organizations of various sorts 176 (RIRs, ICANN, etc.) can be important partners in enabling and 177 facilitating transition. 179 The remainder of this document continues the discussion started in 180 those two RFCs and provides some additional thoughts on the topic of 181 transition strategies and plans. 183 2. Extensibility 185 Many protocols are designed to be extensible, using mechanisms such 186 as options, version negotiation, etc., to ease the transition to new 187 features. However, implementations often succumb to commercial 188 pressures to ignore this flexibility in favor of performance or 189 economy, and as a result such extension mechanisms (e.g., IPv6 Hop- 190 by-Hop Options) often experience problems in practice once they begin 191 to be used. In other cases, a mechanism might be put into a protocol 192 for future use without having an adequate sense of how it will be 193 used, which causes problems later (e.g., SNMP's original 'security' 194 field, or the IPv6 Flow Label). Thus, designers need to consider 195 whether it would be easier to transition to a new protocol than it 196 would be to ensure that an extension point is correctly specified and 197 implemented such that it would be available when needed. 199 A protocol that plans for its own eventual replacement during its 200 design makes later transitions easier. Developing and testing a 201 design for the technical mechanisms needed to signal or negotiate a 202 replacement is essential in such a plan. 204 When there is interest in translation between a new mechanism and an 205 old one, complexity of such translation must also be considered. The 206 major challenge in translation is for semantic differences. Often, 207 syntactic differences can be translated seamlessly; semantic ones 208 almost never. Hence when designing for translatability, syntactic 209 and semantic differences should be clearly documented. 211 See RFC 3692 [RFC3692] and RFC 6709 [RFC6709] for more discussion of 212 design considerations for protocol extensions. 214 3. Transition vs. Co-existence 216 There is an important distinction between a strict "flag-day" style 217 transition where an old mechanism is immediately replaced with a new 218 mechanism, vs. a looser co-existence based approach where transition 219 proceeds in stages where a new mechanism is first added alongside an 220 existing one for some overlap period, and then the old mechanism is 221 removed at a later stage. 223 When a new mechanism is backwards compatible with an existing 224 mechanism, transition is easiest because different parties can 225 transition at different times. However, when no backwards 226 compatibility exists such as in the IPv4 to IPv6 transition, a 227 transition plan must choose either a "flag day" or a period of co- 228 existence. When a large number of entities are involved, a flag day 229 becomes impractical or even impossible. Coexistence, on the other 230 hand, involves additional costs of maintaining two separate 231 mechanisms during the overlap period which could be quite long. 232 Furthermore, the longer the overlap period, the more the old 233 mechanism might get further deployment and thus increase the overall 234 pain of transition. 236 Often the decision between a "flag day" and a sustained co-existence 237 period may be complicated when differing incentives are involved 238 (e.g., see the case studies in the Appendix). 240 Some new protocols or protocol versions are developed with the intent 241 of never retiring the protocol they intend to replace. Such a 242 protocol might only aim to address a subset of the use cases for 243 which an original is used. For these protocols, coexistence is the 244 end state. 246 Indefinite coexistence as an approach could be viable if removal of 247 the existing protocol is not an urgent goal. It might also be 248 necessary for "wildly successful" protocols that have more disparate 249 uses than can reasonably be considered during the design of a 250 replacement. For example, HTTP/2 does not aspire to cause the 251 eventual decommissioning of HTTP/1.1 for these reasons. 253 4. Translation/Adaptation Location 255 A translation or adaptation mechanism is often required if the old 256 and new mechanisms are not interoperable. Care must be taken when 257 determining whether one will work and where such a translator is best 258 placed. 260 A translation mechanism may not work for every use case. For 261 example, if a translation from one protocol (or protocol version) to 262 another produces indeterminate results, translation will not work 263 reliably. In addition, if translation always produces a downgraded 264 protocol result, the incentive considerations in Section 5.2 will be 265 relevant. 267 Requiring a translator in the middle of the path can hamper end-to- 268 end security and reliability. For example, see the discussion of 269 network-based filtering in [RFC7754]. 271 On the other hand, requiring a translation layer within an endpoint 272 can be a resource issue in some cases, such as if the endpoint could 273 be a constrained node [RFC7228]. 275 In addition, when a translator is within an endpoint, it can can 276 attempt to hide the difference between an older protocol and a newer 277 protocol, either by exposing one of the two sets of behavior to 278 applications and internally mapping it to the other set of behavior, 279 or by exposing a higher level of abstraction which is then 280 alternatively mapped to either one depending on detecting which is 281 needed. In contrast, when a translator is in the middle of the path, 282 typically only the first approach can be done since the middle of the 283 path is typically unable to provide a higher level of abstraction. 285 Any transition strategy for a non-backward-compatible mechanism 286 should include a discussion of where it is placed and a rationale. 287 The transition plan should also consider the transition away from the 288 use of translation and adaptation technologies. 290 5. Transition Plans 292 A review of the case studies described in Appendix A suggests that a 293 good transition plan includes at least the following components: an 294 understanding of what is already deployed and in use, an explanation 295 of incentives for each entity involved, a description of the phases 296 of the transition along with a proposed criteria for each phase, a 297 method for measuring the transition's success, a contingency plan for 298 failure of the transition, and an effective method for communicating 299 the plan to the entities involved and incorporating their feedback 300 thereon. We recommend that such criteria be considered when 301 evaluating proposals to transition to new or updated protocols. Each 302 of these components is discussed in the subsections below. 304 5.1. Understanding of Existing Deployment 306 Often an existing mechanism has variations in implementations and 307 operational deployments. For example, a specification might include 308 optional behaviors that may or may not be implemented or deployed. 309 In addition, there may also be implementations or deployments that 310 deviate from, or include vendor-specific extensions to, various 311 aspects of a specification. It is important when considering a 312 transition to understand what variations one is intending to 313 transition from or co-exist with, since the technical and non- 314 technical issues may vary greatly as a result. 316 5.2. Explanation of Incentives 318 A transition plan should explain the incentives to each involved 319 entity to support the transition. Note here that many entities other 320 than the endpoint applications and their users may be affected, and 321 the barriers to transition may be nontechnical as well as technical. 322 When considering these incentives, also consider network operations 323 tools, practices, and processes, personnel training, accounting and 324 billing dependencies, and legal and regulatory incentives. 326 If there is opposition to a particular new protocol (e.g., from 327 another standards organization, or a government, or some other 328 affected entity), various non-technical issues arise that should be 329 part of what is planned and dealt with. Similarly, if there are 330 significant costs or other disincentives, the plan needs to consider 331 how to overcome them. 333 It's worth noting that an analysis of incentives can be difficult and 334 at times led astray by wishful thinking, as opposed to adequately 335 considering economic realities. Thus, honestly considering any 336 barriers to transition, and justifying one's conclusions about 337 others' incentives, are key to a successful analysis. 339 5.3. Description of Phases and Proposed Criteria 341 Transition phases might include pilot/experimental deployment, 342 coexistence, deprecation, and removal phases for a transition from 343 one technology to another incompatible one. 345 Timelines are notoriously difficult to predict and impossible to 346 impose on uncoordinated transitions at the scale of the Internet, but 347 rough estimates can sometimes help all involved entities to 348 understand the intended duration of each phase. More often, it is 349 useful to provide criteria that must be met in order to move to the 350 next phase. For example, is removal scheduled for a particular date 351 (e.g., FCC regulation to discontinue analog TV broadcasts in the U.S. 352 by June 12, 2009)? Or is removal to be based on the use of the old 353 mechanism falling below a specified level? Or some other criteria? 355 As one example, RFC 5211 [RFC5211] proposed a transition plan for 356 IPv6 that included a proposed timeline, and criteria specific to each 357 phase. While the timeline was not accurately followed, the phases 358 and timeline did serve as inputs to the World IPv6 Day and World IPv6 359 Launch events. 361 5.4. Measurement of Success 363 The degree of deployment of a given protocol or feature at a given 364 phase in its transition can be measured differently, depending on its 365 design. For example, server-side protocols and options which 366 identify themselves through a versioning or negotiation mechanism can 367 be discovered through active Internet measurement studies. 369 5.5. Contingency Planning 371 A contingency plan can be as simple as providing for indefinite 372 coexistence between an old and new protocol, or for reverting to the 373 old protocol until an updated version of the new protocol is 374 available. Such a plan is useful in the event that unforeseen 375 problems are discovered during deployment, so that such problems can 376 be quickly mitigated. 378 For example, World IPv6 Day included a contingency plan which was to 379 revert to the original state at the end of the day. After 380 discovering no issues, some participants found that this contingency 381 plan was unnecessary and kept the new state. 383 5.6. Communicating the Plan 385 Many of the entities involved in a protocol transition may not be 386 aware of the IETF or the RFC series, so dissemination through other 387 channels is key for sufficiently broad communication of the 388 transition plan. While flag days are impractical at Internet scale, 389 coordinated "events" such as World IPv6 Launch may improve general 390 awareness of an ongoing transition. 392 Also, there is often a need for an entity facilitating the transition 393 through advocacy and focus. Such an entity, independent of the IETF, 394 can be key in communicating the plan and its progress. 396 Some transitions have a risk of breaking backwards compatibility for 397 some fraction of users. In such a case, when a transition affects 398 competing entities facing the risk of losing customers to each other, 399 there is an economic disincentive to transition. Thus, one role for 400 a facilitating entity is to get competitors to transition during the 401 same timeframe, so as to mitigate this fear. For example, the 402 success of World IPv6 Launch was largely due to ISOC playing this 403 role. 405 6. Security Considerations 407 This document discusses attributes of protocol transitions. Some 408 types of transition can adversely affect security or privacy. For 409 example, requiring a translator in the middle of the path may hamper 410 end-to-end security and privacy, since it creates an attractive 411 target. For further discussion of some of these issues, see 412 Section 5 of [RFC7754]. 414 In addition, coexistence of two protocols in general increases risk 415 in the sense that it doubles the attack surface and allows attacks 416 that exploit the weaker of the two protocols by claiming not to 417 understand the stronger one. 419 7. IANA Considerations 421 This document requires no actions by the IANA. 423 8. Conclusion 425 This document summarized the set of issues that should be considered 426 by protocol designers and deployers to facilitate such transition and 427 provides pointers to previous work (e.g., [RFC3692], [RFC6709]) that 428 provided detailed design guidelines. This document also covered what 429 makes for a good transition plan, and includes several case studies 430 that provide examples. As more experience is gained over time on how 431 to successfully apply these principles and design effective 432 transition plans, we encourage the community to share such learnings 433 with the IETF community and on the architecture-discuss@ietf.org 434 mailing list so that any future document on this topic can leverage 435 such experience. 437 9. Acknowledgements 439 This document is a product of the IAB Stack Evolution Program, with 440 input from many others. In particular, Mark Nottingham, Dave 441 Crocker, Eliot Lear, Joe Touch, Cameron Byrne, John Klensin, Patrik 442 Faltstrom, the IETF Applications Area WG, and others provided helpful 443 input on this document. 445 10. IAB Members at the Time of This Writing 447 Jari Arkko 448 Ralph Droms 449 Ted Hardie 450 Joe Hildebrand 451 Russ Housley 452 Lee Howard 453 Erik Nordmark 454 Robert Sparks 455 Andrew Sullivan 456 Dave Thaler 457 Martin Thomson 458 Brian Trammell 459 Suzanne Woolf 461 11. Informative References 463 [HTTP0.9] Tim Berners-Lee, "The Original HTTP as defined in 1991", 464 1991, . 467 [I-D.ietf-tls-grease] 468 Benjamin, D., "Applying GREASE to TLS Extensibility", 469 draft-ietf-tls-grease-00 (work in progress), January 2017. 471 [IabIpv6TransitionStatement] 472 IAB, "Follow-up work on NAT-PT", October 2007, 473 . 476 [IPv6Survey2011] 477 Botterman, M., "IPv6 Deployment Survey", 2011, 478 . 481 [IPv6Survey2015] 482 British Telecommunications, "IPv6 Industry Survey Report", 483 August 2015, . 486 [PAM2015] Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., 487 Fairhurst, G., and R. Scheffenegger, "Enabling Internet- 488 Wide Deployment of Explicit Congestion Notification", 489 Proceedings of PAM 2015, 2015, . 492 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 493 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, 494 December 1995, . 496 [RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 497 IPv6 Hosts and Routers", RFC 1933, DOI 10.17487/RFC1933, 498 April 1996, . 500 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 501 Transfer Protocol -- HTTP/1.0", RFC 1945, 502 DOI 10.17487/RFC1945, May 1996, 503 . 505 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. 506 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 507 RFC 2068, DOI 10.17487/RFC2068, January 1997, 508 . 510 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Frystyk, "Use 511 and Interpretation of HTTP Version Numbers", RFC 2145, 512 DOI 10.17487/RFC2145, May 1997, 513 . 515 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 516 IPv6 Hosts and Routers", RFC 2893, DOI 10.17487/RFC2893, 517 August 2000, . 519 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 520 of Explicit Congestion Notification (ECN) to IP", 521 RFC 3168, DOI 10.17487/RFC3168, September 2001, 522 . 524 [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for 525 UNilateral Self-Address Fixing (UNSAF) Across Network 526 Address Translation", RFC 3424, DOI 10.17487/RFC3424, 527 November 2002, . 529 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 530 Considered Useful", BCP 82, RFC 3692, 531 DOI 10.17487/RFC3692, January 2004, 532 . 534 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 535 Network Address Translations (NATs)", RFC 4380, 536 DOI 10.17487/RFC4380, February 2006, 537 . 539 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 540 (CIDR): The Internet Address Assignment and Aggregation 541 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 542 2006, . 544 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 545 Recommendations for Internationalized Domain Names 546 (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, 547 . 549 [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, 550 DOI 10.17487/RFC5211, July 2008, 551 . 553 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 554 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 555 . 557 [RFC5894] Klensin, J., "Internationalized Domain Names for 558 Applications (IDNA): Background, Explanation, and 559 Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, 560 . 562 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 563 Internationalized Domain Names in Applications (IDNA) 564 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, 565 . 567 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 568 Encodings for Internationalized Domain Names", RFC 6055, 569 DOI 10.17487/RFC6055, February 2011, 570 . 572 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 573 NAT64: Network Address and Protocol Translation from IPv6 574 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 575 April 2011, . 577 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 578 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 579 DOI 10.17487/RFC6269, June 2011, 580 . 582 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 583 RFC 6455, DOI 10.17487/RFC6455, December 2011, 584 . 586 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 587 Considerations for Protocol Extensions", RFC 6709, 588 DOI 10.17487/RFC6709, September 2012, 589 . 591 [RFC7021] Donley, C., Ed., Howard, L., Kuarsingh, V., Berg, J., and 592 J. Doshi, "Assessing the Impact of Carrier-Grade NAT on 593 Network Applications", RFC 7021, DOI 10.17487/RFC7021, 594 September 2013, . 596 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 597 Constrained-Node Networks", RFC 7228, 598 DOI 10.17487/RFC7228, May 2014, 599 . 601 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 602 Protocol (HTTP/1.1): Message Syntax and Routing", 603 RFC 7230, DOI 10.17487/RFC7230, June 2014, 604 . 606 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 607 "Transport Layer Security (TLS) Application-Layer Protocol 608 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 609 July 2014, . 611 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet 612 Technology Adoption and Transition (ITAT)", RFC 7305, 613 DOI 10.17487/RFC7305, July 2014, 614 . 616 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 617 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 618 DOI 10.17487/RFC7540, May 2015, 619 . 621 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 622 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 623 . 625 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 626 Nordmark, "Technical Considerations for Internet Service 627 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 628 March 2016, . 630 [TR46] Unicode Consortium, "Unicode IDNA Compatibility 631 Processing", June 2015, 632 . 634 [TSV2007] Sridharan, M., Bansal, D., and D. Thaler, "Implementation 635 Report on Experiences with Various TCP RFCs", Proceedings 636 of IETF 68, March 2007, 637 . 640 Appendix A. Case Studies 642 Appendix A of [RFC5218] describes a number of case studies that are 643 relevant to this document and highlight various transition problems 644 and strategies (see for instance the Inter-Domain Multicast case 645 study in Section A.4 of [RFC5218]). We now include several 646 additional case studies that focus on transition problems and 647 strategies. Many other equally good case studies could have been 648 included, but, in the interests of brevity, only a sampling is 649 included here that is sufficient to justify the conclusions in the 650 body of this document. 652 A.1. Explicit Congestion Notification 654 Explicit Congestion Notification (ECN) is a mechanism to replace loss 655 as the only signal for the detection of congestion, with an explicit 656 signal sent from a router to the recipient of a packet, then 657 reflected back to the sender. It was standardized in 2000 in 658 [RFC3168], and the mechanism consists of two parts: congestion 659 detection in the IP layer, reusing two bits of the old IP Type of 660 Service (TOS) field, and congestion feedback in the transport layer. 661 Feedback in TCP uses two TCP flags, ECN Echo and Congestion Window 662 Reduced. Together with a suitably configured active queue management 663 (AQM), ECN can improve TCP performance on congested links. 665 The deployment of ECN is a case study in failed transition followed 666 by possible redemption. Initial deployment of ECN in the early and 667 mid 2000s led to severe problems with some network equipment, 668 including home router crashes and reboots when packets with ECN IP or 669 TCP flags was received [TSV2007]. This led to firewalls stripping 670 ECN IP and TCP flags, or even dropping packets with these flags set. 671 This stalled deployment. The need for both endpoints (to negotiate 672 and support ECN) and on-path devices (to mark traffic when congestion 673 occurs) to cooperate in order to see any benefits from ECN deployment 674 was a further issue. The deployment of ECN across the Interent had 675 failed. 677 In the late 2000s, Linux and Windows servers began defaulting to 678 "passive ECN support", meaning they would negotiate ECN if asked by 679 the client, but would not ask to negotiate ECN by default. This 680 decision was regarded as without risk: only if a client were 681 explicitly configured to negotiate ECN would any possible 682 connectivity problems surface. Gradually, this has increased server 683 support in the Internet from near zero in 2008, to 11% of the top 684 million Alexa webservers in 2011, to 30% in 2012, to 65% in late 685 2014. In the meantime, the risk to connectivity of ECN negotiation 686 has reduced dramatically [PAM2015], leading to ongoing work to make 687 Windows, Apple iOS, OSX, and Linux clients negotiate ECN by default. 688 It is hoped that a critical mass of clients and servers negotiating 689 ECN will provide an incentive to mark congestion on ECN-enabled 690 traffic, thus breaking the logjam. 692 A.2. Internationalized Domain Names 694 The deployment of Internationalized Domain Names (IDN) has a long and 695 complicated history. This should not be surprising, since 696 internationalization deals with language and cultural issues 697 regarding differing expectations of users around the world, thus 698 making it inherently difficult to agree on common rules. 699 Furthermore, because human languages evolve and change over time, 700 even if common rules can be established, there is likely to be a need 701 to review and update them regularly. 703 There have been multiple technical transitions related to IDNs, 704 including the introduction of non-ASCII in DNS, the transition to 705 each new version of Unicode, and the transition from IDNA 2003 to 706 IDNA 2008. A brief history of the introduction of non-ASCII in DNS 707 and the various complications that arose therein, can be found in 708 section 3 of [RFC6055]. While IDNA 2003 was limited to Unicode 709 version 3.2 only, one of the IDNA 2008 changes was to decouple its 710 rules from any particular version of Unicode (see [RFC5894], 711 especially section 1.4, for more discussion of this point, and see 712 [RFC4690] for a list of other issues with IDNA 2003 that motivated 713 IDNA 2008). However, the transition from IDNA 2003 to IDNA 2008 714 itself presented a problem since IDNA 2008 did not preserve backwards 715 compatibility with IDNA 2003 for a couple of codepoints. 716 Investigations and discussions with affected parties led to the IETF 717 ultimately choosing IDNA 2008 because the overall gain by moving to 718 IDNA 2008 to fix the problems with IDNA 2003 was seen to be much 719 greater than the problems due to the few incompatibilities at the 720 time of the change, as not many IDNs were in use, and even fewer that 721 might see incompatibilities. 723 A couple of browser vendors in particular were concerned about the 724 differences between IDNA 2003 and IDNA 2008, and the fact that if a 725 browser stopped being able to get to some site, or unknowingly sent a 726 user to a different (e.g., phishing) site instead, the browser would 727 be blamed. As such, any user-perceivable change from IDNA 2003 728 behavior would be painful to the vendor to deal with, and hence they 729 could not depend on solutions that would need action by other 730 entities. 732 Thus, to deal with issues like such incompatibilities, some 733 applications and client-side frameworks wanted to map one string into 734 another (namely, a string that would give the same result as when 735 IDNA 2003 was used) before invoking DNS. 737 To provide such mapping (and some other functioanlity), the Unicode 738 Consortium published [TR46] that continued down the path of IDNA 2003 739 with a code point by code point selection mechanism. This was 740 implemented by some, but never adopted by the IETF. 742 Meanwhile, the IETF did not publish any mapping mechanism, but 743 [RFC5895] was published on the Independent Submission stream. In 744 discussions around mapping, one of the key topics was about how long 745 the transition should last. At one end of the duration spectrum is a 746 flag day where some entities would be broken initially but the change 747 would happen before IDN usage became even more ubiquitous. At the 748 other end of the spectrum is the need to maintain mappings 749 indefinitely. Local incentives at each entity who needed to change, 750 however, meant that a short timeframe was impractical. 752 There are many affected types of entities with very different 753 incentives. For example, the incentives affecting browser vendors, 754 registries, domain name marketers and applicants, app developers, and 755 protocol designers are each quite different, and the various 756 solutions require changes by multiple types of entities, where the 757 benefits do not always align with the costs. If there is some group 758 (or even an individual) that is opposed to a change/transition and 759 able to put significant resources behind their opposition, 760 transitions get a lot harder. 762 Finally, there are multiple naming contexts, and the protocol 763 behavior (including how internationalized domain names are handled) 764 within each naming context can be different. Hence applications and 765 frameworks often encounter a variety of behaviors and may or may not 766 be designed to deal with them. See sections 2 and 3 of [RFC6055] for 767 more discussion. 769 In summary, all this diversity can cause problems for each affected 770 entity, especially if a competitor does not have such a problem, 771 e.g., for browser vendors if competing browsers do not have the same 772 problems, or for an email server provider if competing server 773 providers do not have the same problems. 775 A.3. IPv6 777 Twenty-one years after publication of [RFC1883], the transition to 778 IPv6 is still in progress. The first document to describe a 779 transition plan ([RFC1933], later obsoleted by [RFC2893]) was 780 published less than a year after the protocol itself. It recommended 781 co-existence (dual-stack or tunneling technology) with the 782 expectation that over time, all hosts would have IPv6, and IPv4 could 783 be quietly retired. 785 In the early stages, deployment was limited to peer-to-peer uses, 786 tunneled over IPv4 networks. For example, Teredo [RFC4380] aligned 787 the cost of fixing the problem with the benefit, and allowed for 788 incremental benefits to those who used it. 790 Operating System vendors had incentives because with such tunneling 791 protocols, they could get peer-to-peer apps working without depending 792 on any infrastructure changes. That resulted in the main apps using 793 IPv6 being in the peer-to-peer category (BitTorrent, Xbox gaming, 794 etc.). 796 Router vendors had some incentive because IPv6 could be used within 797 an intra-domain network more efficiently than tunneling, once the OS 798 vendors already had IPv6 support and some special-purpose apps 799 existed. 801 For content providers and ISPs, on the other hand, there was little 802 incentive for deployment: there was no incremental benefit to 803 deploying locally. Since everyone already had IPv4, there was no 804 network effect benefit to deploying IPv6. Even as proponents argued 805 that workarounds to extend the life of IPv4--such as CIDR, NAT, and 806 stingy allocations--made it more complex, IPv4 continued to work well 807 enough for most applications. 809 Workarounds to NAT problems documented in [RFC6269] and [RFC7021] 810 included ICE, STUN, and TURN, technologies that allowed those 811 experiencing the problems to deploy technologies to resolve them. As 812 with end-to-end IPv6 tunneling (e.g., Teredo), the incentives there 813 aligned the cost of fixing the problem with the benefit, and allowed 814 for incremental benefits to those who used them. The IAB discussed 815 NAT technology proposals [RFC3424] and recommended they be considered 816 short-term fixes, and said that proposals must include an exit plan, 817 such that they would decline over time. In particular, the IAB 818 warned against generalizing NAT solutions, which would lead to 819 greater dependence on them. In some ways, these solutions, along 820 with other IPv4 development (e.g., the workarounds above, and 821 retrofitting IPsec into IPv4) continued to reduce the incentive to 822 deploy IPv6. 824 Some early advocates overstated the benefits of IPv6, suggesting that 825 it had better security (because IPsec was required) or that NAT was 826 worse than it often appeared to be or that IPv4 exhaustion would 827 happen years sooner than it actually did. Some people pushed back on 828 these exaggerations, and decided that the protocol itself somehow 829 lacked credibility. 831 Not until a few years after IPv4 runout in various Regional Address 832 Registry (RIR) regions did IPv6 deployment significantly increase. 833 The RIRs had been advocating in their communities for IPv6 for some 834 time, reducing fees for IPv6, and in some cases providing training; 835 there is little to suggest that these had a significant effect. The 836 RIRs and others conducted surveys of different industries and 837 industry segments to learn why people did not deploy IPv6 838 [IPv6Survey2011] [IPv6Survey2015], which commonly listed lack of a 839 business case, lack of training, and lack of vendor support as 840 primary hurdles. 842 Arguably forward-looking companies collaborated, with ISOC, on World 843 IPv6 Day and World IPv6 Launch to jump start global IPv6 deployment. 844 By including multiple competitors, World IPv6 Day reduced the risk 845 that any of them would lose customers if a user's IPv6 implementation 846 was broken. World IPv6 Launch then set a goal for content providers 847 to permanently enable IPv6, and for large ISPs to enable IPv6 for at 848 least 1% of end users. These large, visible deployments gave vendors 849 specific features and target dates to support IPv6 well. Key aspects 850 of World IPv6 Day and World IPv6 Launch that contributed to their 851 successes (measured as increased deployment of IPv6) were the 852 communication through ISOC, and that measurement metrics and 853 contingency plans that were announced in advance. 855 Several efforts have been made to mitigate the lack of a business 856 case. Some governments (South Korea, Japan) provided tax incentives 857 to include IPv6. Other governments (Belgium, Singapore) mandated 858 IPv6 support by private companies. Few of these had enough value to 859 drive significant IPv6 deployment. 861 The concern about lack of training is often a common issue in 862 transitions. Because IPv4 is so ubiquitous, its use is routine and 863 simplified with common tools, and it is taught in network training 864 everywhere. While IPv6 deployment was low, ignorance of it was no 865 obstacle to being hired as a network administrator or developer. 867 Organizations with the greatest incentives to deploy IPv6 are those 868 which continue to grow quickly, even after IPv4 free pool exhaustion. 869 Thus, ISPs have had varying levels of commitment, based on the growth 870 of their user base, services being added (especially video over IP), 871 and the number of IPv4 addresses they had available. Cloud-based 872 providers, including CDN and hosting companies, have been major 873 buyers of IPv4 addresses, and several have been strong deployers and 874 advocates of IPv6. 876 Different organizations will use different transition models for 877 their networks, based on their needs. Some are electing to use 878 IPv6-only hosts in the network with IPv6-IPv4 translation at the 879 edge. Others are using dual-stack hosts with IPv6-only routers in 880 the core of the network, and IPv4 tunneled or translated through them 881 to dual-stack edge routers. Still others are using native dual-stack 882 throughout the network, but that generally persists as an interim 883 measure: adoption of two technologies is not the same as 884 transitioning from one technology to another. Finally, some walled 885 gardens or isolated networks, such as management networks, use 886 IPv6-only end-to-end. 888 It is impossible to predict with certainty the path IPv6 deployment 889 will have taken when it is complete. Lessons learned so far include 890 aligning costs and benefits (incentive), and ensuring incremental 891 benefit (network effect, or backward compatibility). 893 A.4. HTTP 895 HTTP has been through several transitions as a protocol. 897 The first version [HTTP0.9] was extremely simple, with no headers, 898 status codes, or explicit versioning. HTTP/1.0 [RFC1945] introduced 899 these and a number of other concepts; it succeeded mostly because 900 deployment of HTTP was still relatively new, with a small pool of 901 implementers and (comparatively) small set of deployments and users. 903 HTTP/1.1 (first defined in [RFC2068]) was an attempt to make the 904 protocol suitable for the massive scale it was being deployed upon, 905 and to introduce some new features. 907 HTTP/2 [RFC7540] was largely aimed at improving performance. The 908 primary improvement was the introduction of request multiplexing, 909 which is supported by request prioritization and flow control. It 910 also introduced header compression [RFC7541] and binary framing; this 911 made it completely backwards incompatible on the wire, but still 912 semantically compatible with previous versions of the protocol. 914 A.4.1. Protocol Versioning, Extensions and 'Grease' 916 During the development of HTTP/1.1, there was a fair amount of 917 confusion regarding the semantics of HTTP version numbers, resulting 918 in [RFC2145]. Later, it was felt that minor versioning in the 919 protocol caused more confusion than it was worth, and so HTTP/2.0 920 became HTTP/2. 922 This decision was informed by the observation that many 923 implementations ignored the major version number of the protocol, or 924 misinterpreted it. As is the case with many protocol extension 925 points, HTTP versioning had failed to be "greased" by use often 926 enough, and so had become "rusted" so that only a limited range of 927 values could interoperate. 929 This phenomenon has been observed in other protocols, such as TLS (as 930 exemplified by [I-D.ietf-tls-grease]), and there are active efforts 931 to identify extension points that are in need of such "grease" and 932 making it appear as if they are in use. 934 Besides the protocol version, HTTP's extension points that are well- 935 greased include header fields, status codes, media types and cache- 936 control extensions; HTTP methods, content-encodings and chunk- 937 extensions enjoy less flexibility, and need to be extended more 938 cautiously. 940 A.4.2. Limits on Changes in Major Versions 942 Each update to the "major" version of HTTP has been accompanied by 943 changes that weren't compatible with previous versions. This was not 944 uniformly successful given the diversity and scale of deployment and 945 implementations. 947 HTTP/1.1 introduced pipelining to improve protocol efficiency. 948 Although it did enjoy implementation, interoperability did not 949 follow. 951 This was partially because many existing implementations had chosen 952 architectures that did not lend themselves to supporting it; 953 pipelining was not uniformly implemented and where it was, support 954 was sometimes incorrect or incomplete. Since support for pipelining 955 was indicated by the protocol version number itself, interop was 956 difficult to achieve, and furthermore its inability to completely 957 address head of line blocking issues made pipelining unattractive. 959 Likewise, HTTP/1.1's Expect/Continue mechanism relied on wide support 960 for the new semantics it introduced, and did not have an adequate 961 fallback strategy for previous versions of the protocol. As a 962 result, interoperability and deployment suffered, and is still 963 considered a "problem area" for the protocol. 965 More recently, the HTTP working group decided that HTTP/2 represented 966 an opportunity to improve security, making the protocol much stricter 967 than previous versions about the use of TLS. To this end, a long 968 list of TLS cipher suites were prohibited, constraints were placed on 969 the key exchange method, and renegotiation was prohibited. 971 This did cause deployment problems. Though most were minor and 972 transitory, disabling renegotiation caused problems for deployments 973 that relied on the feature to authenticate clients and prompted new 974 work to replace the feature. 976 A number of other features or characteristics of HTTP were identified 977 as potentially undesirable as part of the HTTP/2 process and 978 considered for removal. This included trailers, the 1xx series of 979 responses, certain modes of request forms, and the unsecured 980 (http://) variant of the protocol. 982 For each of these, the risk to the successful deployment of the new 983 version was considered to be too great to justify removing the 984 feature. However, deployment of the unsecured variant of HTTP/2 985 remains extremely limited. 987 A.4.3. Planning for Replacement 989 HTTP/1.1 provided the Upgrade header field to enable transitioning a 990 connection to an entirely different protocol. So far, this has been 991 little-used, other than to enable the use of WebSockets [RFC6455]. 993 With performance being a primary motivation for HTTP/2, a new 994 mechanism was needed to avoid spending an additional round trip on 995 protocol negotiation. A new mechanism was added to TLS to permit the 996 negotiation of the new version of HTTP: Application Layer Protocol 997 Negotiation (ALPN) [RFC7301]. Upgrade was used only for the 998 unsecured variant of the protocol. 1000 ALPN was identified as the primary way in which future protocol 1001 versions would be negotiated. The mechanism was well-tested during 1002 development of the specification, proving that new versions could be 1003 deployed safely and easily. Several draft versions of the protocol 1004 were successfully deployed during development, and version 1005 negotiation was never shown to be an issue. 1007 Confidence that new versions would be easy to deploy if necessary 1008 lead to a particular design stance that might be considered unusual 1009 in light of the advice in [RFC5218], though is completely consistent 1010 with [RFC6709]: few extension points were added, unless an immediate 1011 need was understood. 1013 This decision was made on the basis that it would be easier to revise 1014 the entire protocol than it would be to ensure that an extension 1015 point was correctly specified and implemented such that it would be 1016 available when needed. 1018 Author's Address 1020 Dave Thaler (editor) 1021 Microsoft 1022 One Microsoft Way 1023 Redmond, WA 98052 1024 US 1026 Email: dthaler@microsoft.com