RFC 8170
Planning for Protocol Adoption and Subsequent Transitions
Planning for Protocol Adoption and Subsequent Transitions 💖
Okay bestie, this is RFC 8170 🎀, and it's basically a guide to how to change protocols without the whole internet going 😭. It came from the Internet Architecture Board (IAB), with D. Thaler as the editor (that's the "Ed." 🫶). It's dated May 2017, and it's in the Informational category 📚, so it's published for the permanent record, not as a standard. The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so no drama there 🙈.
Abstract 🌸
So ever since the Internet Protocol showed up, we've been watching transitions happen all up and down the protocol stack ✨. Like rolling out a brand new protocol, or updating or replacing one that's already out there. Here's the tea: a lot of protocols and technologies weren't built to make switching to alternatives smooth, or to make adding extensions easy 😩. That's why some transitions, like bringing in IPv6, have been really hard. This doc tries to sum up some basic principles that help with future transitions, and it also covers what makes a good transition plan 💅.
Status of This Memo 🦋
Real talk: this is not an Internet Standards Track specification 🙅. It's just published for informational purposes.
This document is a product of the Internet Architecture Board (IAB), and it holds info the IAB decided was valuable enough to keep on the permanent record 📜. It represents the consensus of the Internet Architecture Board (IAB). Documents the IAB approves for publication are not a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 if you want the details 🔥.
If you want the current status, any errata, or a way to send feedback, head to http://www.rfc-editor.org/info/rfc8170 💜.
Copyright Notice 🧚
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions when it comes to this document 📖.
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Transition vs. Coexistence . . . . . . . . . . . . . . . . . 5
4. Translation/Adaptation Location . . . . . . . . . . . . . . . 6
5. Transition Plans . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Understanding of Existing Deployment . . . . . . . . . . 7
5.2. Explanation of Incentives . . . . . . . . . . . . . . . . 7
5.3. Description of Phases and Proposed Criteria . . . . . . . 8
5.4. Measurement of Success . . . . . . . . . . . . . . . . . 8
5.5. Contingency Planning . . . . . . . . . . . . . . . . . . 8
5.6. Communicating the Plan . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . 10
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 14
A.1. Explicit Congestion Notification . . . . . . . . . . . . 14
A.2. Internationalized Domain Names . . . . . . . . . . . . . 15
A.3. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.4. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.4.1. Protocol Versioning, Extensions, and 'Grease' . . . . 20
A.4.2. Limits on Changes in Major Versions . . . . . . . . . 20
A.4.3. Planning for Replacement . . . . . . . . . . . . . . 21
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 221. Introduction ✨
A "transition" is the process or period of changing from one state or condition to another 🦋. There are a few kinds. There are technical ones, like changing protocols or deploying an extension 🔧, and organizational ones, like changing which organization manages a web site 🏢. This doc only focuses on the technical kind, though some principles might apply to the other types too.
Here, "transition" is our catch-all term for any of these:
- adoption of a new protocol where none existed before,
- deployment of a new protocol that obsoletes a previous protocol,
- deployment of an updated version of an existing protocol, or
- decommissioning of an obsolete protocol.
There have been loads of IETF and IAB RFCs and IAB statements about transitions of all sorts 📚. Most of them are protocol-specific, focused on one particular transition. A few relevant ones where the IAB got involved are:
- IAB RFC 3424 [RFC3424] recommended that any technology for so-called "UNilateral Self-Address Fixing (UNSAF)" across NATs include an exit strategy to transition away from such a mechanism. Since the IESG, not the IAB, approves IETF documents, the IESG became the body to enforce (or not) such a requirement.
- IAB RFC 4690 [RFC4690] gave recommendations around internationalized domain names. It discussed issues around the process of transitioning to new versions of Unicode, and this resulted in the creation of the IETF Precis Working Group (WG) to address this problem.
- The IAB statement on "Follow-up work on NAT-PT" [IabIpv6TransitionStatement] pointed out gaps at the time in transitioning to IPv6, and this resulted in the rechartering of the IETF Behave WG to solve this problem.
More recently, the IAB has done work on more generally applicable principles, including two RFCs 💅.
IAB RFC 5218 [RFC5218] on "What Makes for a Successful Protocol?" looked closely at which factors help or hurt a protocol's success, and it made a bunch of recommendations 🔍. It talked about two types of transitions: "initial success" (moving to the technology) and extensibility (moving to updated versions of it). The principles and recommendations in that document apply pretty broadly to all technical transitions. Some of the big principles were:
- Incentive: Transition is easiest when the benefits come to those bearing the costs. That is, the benefits should outweigh the costs at each entity. Some successful cases did this by providing incentives (e.g., tax breaks), or by reducing costs (e.g., freely available source), or by imposing costs of not transitioning (e.g., regulation), or even by narrowing the scenarios of applicability to just the cases where benefits do outweigh costs at all relevant entities. 💰
- Incremental Deployability: Backwards compatibility makes transition easier. Furthermore, transition is easiest when changing only one entity still benefits that entity. In the easiest case, the benefit immediately outweighs the cost, so entities are naturally incented to transition. More commonly, the benefits only outweigh the costs once a significant number of other entities also transition. Unfortunately, in such cases, the natural incentive is often to delay transitioning. 😬
- Total Cost: It is important to consider costs that go beyond the core hardware and software, such as operational tools and processes, personnel training, business model (accounting/billing) dependencies, and legal (regulation, patents, etc.) costs. 🧾
- Extensibility: Design for extensibility [RFC6709] so that things can be fixed up later. 🛠️
IAB RFC 7305 [RFC7305] reported on an IAB workshop on Internet Technology Adoption and Transition (ITAT) 🎤. Like RFC 5218, this workshop also talked about the economic side of transitions, not just the technical side. Some important observations were:
- Early-Adopter Incentives: Part of Bitcoin's strategy was extra incentives for early adopters compared to late adopters. That is, providing a long-term advantage to early adopters can help stimulate transition even when the initial costs outweigh the initial benefit. 🚀
- Policy Partners: Policy-making organizations of various sorts (Regional Internet Registries (RIRs), ICANN, etc.) can be important partners in enabling and facilitating transition. 🤝
The rest of this document picks up the conversation from those two RFCs and shares some extra thoughts on transition strategies and plans 🧠✨.
2. Extensibility 🔌
Lots of protocols are designed to be extensible, using things like options, version negotiation, and so on, so that new features are easier to roll out 🎀. But implementations often give in to commercial pressure and skip that flexibility for the sake of performance or economy 😤. As a result, extension mechanisms (e.g., IPv6 Hop-by-Hop Options) often run into problems in practice once people actually start using them 💀. In other cases, a mechanism gets stuck into a protocol for future use without anyone having a clear idea of how it'll be used, and that causes trouble later (e.g., SNMP's original 'security' field, or the IPv6 Flow Label) 🙈. So designers need to ask whether it would be easier to transition to a brand new protocol than to make sure an extension point is specified and implemented correctly, so it's ready when it's needed 🤔.
A protocol that plans for its own eventual replacement while it's being designed makes later transitions way easier 🦋. Designing and testing the technical mechanisms needed to signal or negotiate a replacement is essential to that kind of plan 💜.
When people want to translate between a new mechanism and an old one, the complexity of that translation must also be considered 🧩. The big challenge in translation is semantic differences. Syntactic differences can often be translated seamlessly, but semantic ones almost never can 😭. So when you're designing for translatability, syntactic and semantic differences should be clearly documented 📝.
See RFC 3692 [RFC3692] and RFC 6709 [RFC6709] for more discussion of design considerations for protocol extensions 🌸.
3. Transition vs. Coexistence ✨
okay so there's a really important difference between a strict "flag day" style transition, where an old mechanism gets swapped out for a new one immediately, and a more chill coexistence approach, where the new mechanism gets added right next to the existing one for some overlap period, and then the old one gets removed later on 🫶
when a new mechanism is backwards compatible with the existing one, transition is the easiest because different parties can switch at different times 💖 but when there's no backwards compatibility, like with the IPv4 to IPv6 transition, the transition plan has to pick either a "flag day" or a period of coexistence 🦋 when a huge number of entities are involved, a flag day gets impractical or even impossible 😭 coexistence has its own costs though, since you have to maintain two separate mechanisms during the overlap period, and that overlap could be quite long 💅 and the longer it lasts, the more the old mechanism might keep getting deployed, which makes the overall pain of transition worse 💀
the decision between a "flag day" and a sustained coexistence period can get really messy when different entities have different incentives (see the case studies in the Appendix for the tea ☕)
some new protocols or protocol versions are built with the intent of never retiring the protocol they're replacing 🌸 these might only aim to address a subset of the use cases the original covers, and for these, coexistence is the end state 🧚
indefinite coexistence could be totally viable if removing the existing protocol isn't an urgent goal 👑 it might even be necessary for "wildly successful" protocols that have way more disparate uses than anyone can reasonably consider when designing a replacement 🔥 for example, HTTP/2 doesn't aspire to cause the eventual decommissioning of HTTP/1.1 for these reasons 💜
4. Translation/Adaptation Location 🌈
a translation or adaptation mechanism is often required if the old and new mechanisms aren't interoperable 🙈 you have to be careful figuring out whether one will even work, and where the translator is best placed 🎀
translation doesn't work for every use case though 💀 for example, if translating from one protocol (or protocol version) to another gives indeterminate results, translation won't work reliably 😭 and if translation always produces a downgraded protocol result, the incentive considerations in Section 5.2 are going to be relevant 👀
requiring a translator in the middle of the path can hamper end-to-end security and reliability 🔐 for example, see the discussion of network-based filtering in [RFC7754] 🫶
on the other hand, requiring a translation layer within an endpoint can be a resource issue in some cases, like if the endpoint could be a constrained node [RFC7228] 🔋
also, when a translator lives inside an endpoint, it can try to hide the difference between an older protocol and a newer one 🦋 it can either expose one of the two sets of behavior to applications and internally map it to the other set, or expose a higher level of abstraction that then gets mapped to either one depending on which one is needed 💖 in contrast, when a translator is in the middle of the path, typically only the first approach can be done, since the middle of the path usually can't provide a higher level of abstraction 🧚
any transition strategy for a non-backward-compatible mechanism should include a discussion of where the incompatible mechanism is placed, plus a rationale 📝 the transition plan should also think about moving away from translation and adaptation technologies too 🌸
5. Transition Plans 💅
a review of the case studies in Appendix A suggests that a good transition plan includes at least these components: an understanding of what's already deployed and in use, an explanation of incentives for each entity involved, a description of the phases of the transition along with proposed criteria for each phase, a method for measuring the transition's success, a contingency plan in case the transition fails, and an effective way to communicate the plan to the entities involved and fold in their feedback 🎀 we recommend that such criteria be considered when evaluating proposals to transition to new or updated protocols ✨ each of these components gets its own subsection below 👑
5.1. Understanding of Existing Deployment 🔍
existing mechanisms often have variations across implementations and operational deployments 🙈 for example, a specification might include optional behaviors that may or may not be implemented or deployed 🤷♀️ there may also be implementations or deployments that deviate from a specification, or include vendor-specific extensions to various parts of it 😬 when you're thinking about a transition, it's super important to understand which variations you're transitioning from or coexisting with, since the technical and non-technical issues can vary wildly depending on that 💅
5.2. Explanation of Incentives 💸
a transition plan should explain the incentives each involved entity has to support the transition 🫶 heads up: lots of entities besides the endpoint applications and their users may be affected, and the barriers to transition can be non-technical as well as technical 😭 when you're considering incentives, also think about network operations tools, practices and processes, personnel training, accounting and billing dependencies, and legal and regulatory incentives 📋
if there's opposition to a particular new protocol (from another standards organization, a government, or some other affected entity, say), there are non-technical issues that should be part of the plan and dealt with 🏛️ similarly, if there are significant costs or other disincentives, the plan needs to figure out how to overcome them 💪
analyzing incentives can be tricky and sometimes gets led astray by wishful thinking, instead of properly considering economic realities 🔮 so honestly considering any barriers to transition, and justifying your conclusions about others' incentives, are the keys to a successful analysis 🔑
5.3. Description of Phases and Proposed Criteria 🗓️
transition phases might include pilot/experimental deployment, coexistence, deprecation, and removal phases for a transition from one technology to an incompatible one 🧪
timelines are notoriously hard to predict and basically impossible to impose on uncoordinated transitions at Internet scale 😩 but rough estimates can sometimes help everyone involved understand the intended duration of each phase ⏳ it's usually more useful to provide criteria that must be met before moving to the next phase 🎯 for example, is removal scheduled for a particular date (like the Federal Communications Commission (FCC) regulation to discontinue analog TV broadcasts in the U.S. by June 12, 2009), or is removal based on use of the old mechanism falling below a specified level, or some other criteria? 📺
as one example, RFC 5211 [RFC5211] proposed a transition plan for IPv6 that included a proposed timeline and criteria specific to each phase 📜 the timeline wasn't accurately followed, but the phases and timeline did serve as inputs to the World IPv6 Day and World IPv6 Launch events 🌍
5.4. Measurement of Success 📊
the degree of deployment of a given protocol or feature at a given phase of its transition can be measured differently, depending on its design 📏 for example, server-side protocols and options that identify themselves through a versioning or negotiation mechanism can be discovered through active Internet measurement studies 🔬
5.5. Contingency Planning 🛟
a contingency plan can be as simple as providing for indefinite coexistence between an old and new protocol, or for reverting to the old protocol until an updated version of the new protocol is available 🔄 this is useful in case unforeseen problems pop up during deployment, so they can be quickly mitigated 🚑
for example, World IPv6 Day included a contingency plan to revert to the original state at the end of the day 🌅 after discovering no issues, some participants found this contingency plan was unnecessary and kept the new state 🎉
5.6. Communicating the Plan 📣
lots of the entities involved in a protocol transition may not be aware of the IETF or the RFC series, so spreading the word through other channels is key for broad communication of the transition plan 📰 while flag days are impractical at Internet scale, coordinated "events" like World IPv6 Launch can boost general awareness of an ongoing transition 🥳
there's also often a need for an entity that facilitates the transition through advocacy and focus 📢 an entity like that, independent of the IETF, can be key in communicating the plan and its progress 🗣️
some transitions risk breaking backwards compatibility for some fraction of users 😬 when a transition affects competing entities that risk losing customers to each other, there's an economic disincentive to transition 💔 so one role for a facilitating entity is to get competitors to transition during the same timeframe, which helps ease that fear 🤝 for example, the success of World IPv6 Launch was largely due to ISOC playing this role 👏
6. Security Considerations 🔐
this document discusses attributes of protocol transitions 📖 some types of transition can adversely affect security or privacy 🚨 for example, requiring a translator in the middle of the path may hamper end-to-end security and privacy, since it creates an attractive target 🎯 for further discussion of some of these issues, see Section 5 of [RFC7754] 🔍
also, coexistence of two protocols generally increases risk, in the sense that it doubles the attack surface 💀 it lets exploiters choose the weaker of two protocols when both are available, or force use of the weaker one when negotiating between the protocols by claiming not to understand the stronger one 😈
7. IANA Considerations 📋
this document does not require any IANA actions ✅
8. Conclusion 🎀
this document summarized the set of issues that protocol designers and deployers should consider to facilitate transition, and it points to previous work (like [RFC3692] and [RFC6709]) that provided detailed design guidelines 📚 it also covered what makes a good transition plan and includes several case studies as examples 🌟 as more experience is gained over time on how to successfully apply these principles and design effective transition plans, we encourage the community to share those learnings with the IETF community and on the architecture-discuss@ietf.org mailing list, so any future document on this topic can build on that experience 💜
9. Informative References ✨
Okay bestie, here's the reading list 📚💖 Every reference is listed below with its full details, exactly as written:
[GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility", Work
in Progress, draft-ietf-tls-grease-00, January 2017.
[HTTP0.9] Tim Berners-Lee, "The Original HTTP as defined in 1991",
1991, <https://www.w3.org/Protocols/HTTP/
AsImplemented.html>.
[IabIpv6TransitionStatement]
IAB, "Follow-up work on NAT-PT", October 2007,
<https://www.iab.org/documents/correspondence-reports-
documents/docs2007/follow-up-work-on-nat-pt/>.
[IPv6Survey2011]
Botterman, M., "IPv6 Deployment Survey", 2011,
<https://www.nro.net/wp-content/uploads/
ipv6_deployment_survey.pdf>.
[IPv6Survey2015]
British Telecommunications, "IPv6 Industry Survey Report",
August 2015, <http://www.globalservices.bt.com/static/asse
ts/pdf/products/diamond_ip/IPv6-Survey-Report-2015.pdf>.
[PAM2015] Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I.,
Fairhurst, G., and R. Scheffenegger, "Enabling Internet-
Wide Deployment of Explicit Congestion Notification",
Proceedings of PAM 2015, DOI 10.1007/978-3-319-15509-8_15,
2015, <http://ecn.ethz.ch/ecn-pam15.pdf>.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
December 1995, <http://www.rfc-editor.org/info/rfc1883>.
[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, DOI 10.17487/RFC1933,
April 1996, <http://www.rfc-editor.org/info/rfc1933>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996,
<http://www.rfc-editor.org/info/rfc1945>.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, DOI 10.17487/RFC2068, January 1997,
<http://www.rfc-editor.org/info/rfc2068>.
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Frystyk, "Use
and Interpretation of HTTP Version Numbers", RFC 2145,
DOI 10.17487/RFC2145, May 1997,
<http://www.rfc-editor.org/info/rfc2145>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for
UNilateral Self-Address Fixing (UNSAF) Across Network
Address Translation", RFC 3424, DOI 10.17487/RFC3424,
November 2002, <http://www.rfc-editor.org/info/rfc3424>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004,
<http://www.rfc-editor.org/info/rfc3692>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <http://www.rfc-editor.org/info/rfc4632>.
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
Recommendations for Internationalized Domain Names
(IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006,
<http://www.rfc-editor.org/info/rfc4690>.
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211,
DOI 10.17487/RFC5211, July 2008,
<http://www.rfc-editor.org/info/rfc5211>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<http://www.rfc-editor.org/info/rfc5218>.
[RFC5894] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Background, Explanation, and
Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
<http://www.rfc-editor.org/info/rfc5894>.
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,
<http://www.rfc-editor.org/info/rfc5895>.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
Encodings for Internationalized Domain Names", RFC 6055,
DOI 10.17487/RFC6055, February 2011,
<http://www.rfc-editor.org/info/rfc6055>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011,
<http://www.rfc-editor.org/info/rfc6269>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011,
<http://www.rfc-editor.org/info/rfc6455>.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012,
<http://www.rfc-editor.org/info/rfc6709>.
[RFC7021] Donley, C., Ed., Howard, L., Kuarsingh, V., Berg, J., and
J. Doshi, "Assessing the Impact of Carrier-Grade NAT on
Network Applications", RFC 7021, DOI 10.17487/RFC7021,
September 2013, <http://www.rfc-editor.org/info/rfc7021>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>.
[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet
Technology Adoption and Transition (ITAT)", RFC 7305,
DOI 10.17487/RFC7305, July 2014,
<http://www.rfc-editor.org/info/rfc7305>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<http://www.rfc-editor.org/info/rfc7541>.
[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
Nordmark, "Technical Considerations for Internet Service
Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,
March 2016, <http://www.rfc-editor.org/info/rfc7754>.
[TR46] The Unicode Consortium, "Unicode IDNA Compatibility
Processing", Version 9.0.0, June 2016,
<http://www.unicode.org/reports/tr46/>.
[TSV2007] Sridharan, M., Bansal, D., and D. Thaler, "Implementation
Report on Experiences with Various TCP RFCs", Proceedings
of IETF 68, March 2007, <http://www.ietf.org/proceedings/
68/slides/tsvarea-3/sld1.htm>.Appendix A. Case Studies 🎀
Okay so, [RFC5218] has its own Appendix A full of case studies about transition problems and strategies, and they're honestly iconic 💅 For example, check out the Inter-Domain Multicast case study in Appendix A.4 of [RFC5218]. Here we add a few more case studies focused on transition problems and strategies. There are loads of other equally good ones we could've included 🙈 but we kept it brief and only picked a sampling that's enough to back up the conclusions in the main body of this document.
A.1. Explicit Congestion Notification 🦋
Explicit Congestion Notification (ECN) is a mechanism that replaces loss as the only signal for detecting congestion ✨ It works by sending an explicit signal first from a router to the recipient of a packet, and then that signal gets reflected back to the sender. It was standardized in 2001 in [RFC3168]. The mechanism has two parts: congestion detection at the IP layer, which reuses two bits of the old IP Type of Service (TOS) field, and congestion feedback at the transport layer. For feedback in TCP, it uses two TCP flags, ECN Echo and Congestion Window Reduced. Together with a suitably configured active queue management (AQM), ECN can improve TCP performance on congested links 🔥
The deployment of ECN is a total case study in failed transition followed by possible redemption 😭 Early deployment in the early and mid 2000s caused serious problems with some network equipment, including home router crashes and reboots when packets with ECN IP or TCP flags were received [TSV2007]. Because of that, firewalls started stripping ECN IP and TCP flags, or even dropping packets with those flags set. Deployment stalled 💀 Another issue was that both endpoints (to negotiate and support ECN) and on-path devices (to mark traffic when congestion occurs) had to cooperate before anyone could see any benefit from ECN deployment. The deployment of ECN across the Internet had failed 💔
Then in the late 2000s, Linux and Windows servers started defaulting to "passive ECN support". That meant they would negotiate ECN if a client asked, but they would not ask to negotiate ECN by default. This was seen as risk-free: only if a client was explicitly configured to negotiate ECN would any possible connectivity problems surface. Gradually, server support across the Internet went up from near zero in 2008, to 11% of the top million Alexa webservers in 2011, to 30% in 2012, and to 65% in late 2014 📈 Meanwhile, the risk to connectivity from ECN negotiation dropped dramatically [PAM2015], which led to ongoing work to make Windows, Apple iOS, OSX, and Linux clients negotiate ECN by default. The hope is that a critical mass of clients and servers negotiating ECN will give an incentive to mark congestion on ECN-enabled traffic, and that would break the logjam 🌈👑
A.2. Internationalized Domain Names 🌍💖
okay so IDNs have a long and complicated history, and honestly? not surprising at all 😭. internationalization is about language and culture, and everyone around the world has different expectations, so agreeing on common rules is inherently hard 💅
and it gets worse, bestie. human languages keep evolving and changing over time, so even if everyone manages to agree on rules, they will probably need to be reviewed and updated regularly 🔄
there have been multiple technical transitions related to IDNs 🦋 like the introduction of non-ASCII in DNS, the move to each new version of Unicode, and the switch from IDNA 2003 to IDNA 2008. if you want the tea on the non-ASCII in DNS saga and all the chaos that came with it, check out Section 3 of [RFC6055] ✨. now, IDNA 2003 was only limited to Unicode version 3.2 🙈, and one of the IDNA 2008 changes was to decouple its rules from any particular version of Unicode (see [RFC5894], especially Section 1.4, for more discussion of this point, and see [RFC4690] for a list of other issues with IDNA 2003 that motivated IDNA 2008) 🌸. that decoupling is iconic, honestly.
BUT the transition from IDNA 2003 to IDNA 2008 itself was kind of a problem 😬, because IDNA 2008 did not preserve backwards compatibility with IDNA 2003 for a couple of codepoints. the IETF looked into it with the affected parties and ultimately chose IDNA 2008 🎀, because the overall gain from fixing the problems with IDNA 2003 was seen to be much greater than the problems from the few incompatibilities at the time of the change. like, not many IDNs were in use, and even fewer might actually see incompatibilities. the math mathed 🧮✨
a couple of browser vendors were especially worried about the differences between IDNA 2003 and IDNA 2008 🥺. if a browser suddenly couldn't get to some site, or unknowingly sent a user to a different (e.g., phishing) site instead, the browser would be the one getting blamed 💀. so any user-perceivable change from IDNA 2003 behavior would be painful for the vendor to deal with, and they couldn't depend on solutions that needed action from other entities. not fair, but it's giving real-world drama 😤
so, to handle incompatibilities like that, some applications and client-side frameworks wanted to map one string into another 🪄 (namely, a string that would give the same result as when IDNA 2003 was used) before invoking DNS.
to provide that mapping (and some other functionality), the Unicode Consortium published [TR46] 📚. it kept going down the IDNA 2003 path with a code point by code point selection mechanism. some folks implemented it, but the IETF never adopted it 🙃.
meanwhile, the IETF didn't publish any mapping mechanism, but [RFC5895] came out on the Independent Submission stream 🌈. in the mapping discussions, one of the big questions was how long the transition should last. on one end is a flag day, where some entities would be broken at first but the change would happen before IDN usage got even more ubiquitous 🗓️. on the other end is maintaining mappings indefinitely, which is a lot. local incentives at each entity that needed to change meant a short timeframe was impractical 🫠.
there are so many affected types of entities with very different incentives 👑. browser vendors, registries, domain name marketers and applicants, app developers, and protocol designers all have quite different incentives, and the solutions need changes from multiple types of entities where the benefits don't always line up with the costs. if some group (or even one individual) opposes a change or transition and can put serious resources behind that opposition, transitions get a lot harder 😤💜.
finally, there are multiple naming contexts, and protocol behavior (including how internationalized domain names are handled) can differ within each one 🧚. so applications and frameworks often run into a variety of behaviors and may or may not be built to handle them. see Sections 2 and 3 of [RFC6055] for more discussion 📖.
in summary, all this diversity can cause problems for each affected entity, especially if a competitor doesn't have the same problem. like, for browser vendors, if competing browsers don't have the same problems, or for an email server provider, if competing server providers don't have the same problems. main character chaos 💅🔥
A.3. IPv6 🌐🦋
twenty-one years after [RFC1883] was published, the transition to IPv6 is still in progress 😭. the first document to describe a transition plan ([RFC1933]) came out less than a year after the protocol itself 📜. it recommended coexistence (dual-stack or tunneling technology) with the expectation that over time, all hosts would have IPv6 and IPv4 could be quietly retired 🤫.
in the early stages, deployment was limited to peer-to-peer uses tunneled over IPv4 networks 🫧. for example, Teredo [RFC4380] lined up the cost of fixing the problem with the benefit and allowed incremental benefits for anyone who used it ✨. that's the vibe 💖.
operating system vendors had incentives 🙌, because with tunneling protocols they could get peer-to-peer apps working without depending on any infrastructure changes. that's how the main apps using IPv6 ended up in the peer-to-peer category (BitTorrent, Xbox gaming, etc.) 🎮.
router vendors had some incentive too 🛜, since IPv6 could be used within an intra-domain network more efficiently than tunneling, once OS vendors already had IPv6 support and some special-purpose apps existed 🍓.
content providers and ISPs, on the other hand, had little incentive to deploy 🥲: there was no incremental benefit to deploying locally. since everyone already had IPv4, there was no network effect benefit to deploying IPv6. even as proponents argued that workarounds to extend the life of IPv4 made things more complex, IPv4 kept working well enough for most applications 🙄. those workarounds were Classless Inter-Domain Routing (CIDR) [RFC4632] , NAT, and stingy allocations 🧱.
workarounds to NAT problems documented in [RFC6269] and [RFC7021] included Interactive Connectivity Establishment (ICE), Session Traversal Utilities for NAT (STUN), and Traversal Using Relays around NAT (TURN) 🔧. these technologies let people dealing with the problems deploy fixes for them 🛠️. just like end-to-end IPv6 tunneling (e.g., Teredo), the incentives there lined up the cost of fixing the problem with the benefit, and allowed incremental benefits for those who used them 💜. the IAB discussed NAT technology proposals [RFC3424] and recommended that they be considered short-term fixes, and that proposals must include an exit plan so they would decline over time 🚪. in particular, the IAB warned against generalizing NAT solutions, since that would lead to greater dependence on them 🙅♀️. in some ways, these solutions, along with other IPv4 development (e.g., the workarounds above, and retrofitting IPsec into IPv4), kept reducing the incentive to deploy IPv6 😩.
some early advocates overstated the benefits of IPv6 🙈. they suggested it had better security (because IPsec was required), that NAT was worse than it often appeared to be, or that IPv4 exhaustion would happen years sooner than it actually did. some people pushed back on these exaggerations, and decided the protocol itself somehow lacked credibility 💀.
IPv6 deployment didn't significantly increase until a few years after IPv4 addresses were exhausted in various RIR regions ⏳. the RIRs had been advocating for IPv6 in their communities for some time, reducing fees for IPv6, and in some cases providing training, but there's little to suggest any of that had a significant effect 🤷♀️. the RIRs and others surveyed different industries and industry segments to learn why people weren't deploying IPv6 [IPv6Survey2011] [IPv6Survey2015] 📊. the answers commonly listed lack of a business case, lack of training, and lack of vendor support as the primary hurdles 🚧.
arguably forward-looking companies collaborated with ISOC on World IPv6 Day and World IPv6 Launch to jump-start global IPv6 deployment 🚀. by including multiple competitors, World IPv6 Day reduced the risk that any of them would lose customers if a user's IPv6 implementation was broken 🫶. World IPv6 Launch then set a goal for content providers to permanently enable IPv6, and for large ISPs to enable IPv6 for at least 1% of end users 🎯. these big, visible deployments gave vendors specific features and target dates to support IPv6 well 🗓️. the key things that made World IPv6 Day and World IPv6 Launch successful (measured as increased deployment of IPv6) were the communication through ISOC, and the fact that measurement metrics and contingency plans were announced in advance 🎀✨.
several efforts tried to mitigate the lack of a business case 💸. some governments (South Korea and Japan) gave tax incentives to include IPv6. other governments (Belgium and Singapore) mandated IPv6 support by private companies. few of these had enough value to drive significant IPv6 deployment 😬.
lack of training is a common issue in transitions 🎓. because IPv4 is so ubiquitous, its use is routine and simplified by common tools, and it's taught in network training everywhere. while IPv6 deployment was low, not knowing it was no obstacle to being hired as a network administrator or developer 🤡.
the organizations with the greatest incentive to deploy IPv6 are the ones that keep growing quickly, even after IPv4 free-pool exhaustion 📈. so ISPs have had varying levels of commitment, based on the growth of their user base, the services being added (especially video over IP), and the number of IPv4 addresses they had available 📺. cloud-based providers, including Content Delivery Network (CDN) and hosting companies, have been major buyers of IPv4 addresses, and several have been strong deployers and advocates of IPv6 ☁️💜.
different organizations use different transition models for their networks, based on their needs 🧩. some use IPv6-only hosts in the network with IPv6-IPv4 translation at the edge. others use dual-stack hosts with IPv6-only routers in the core, with IPv4 tunneled or translated through them to dual-stack edge routers. still others use native dual-stack throughout the network, but that generally sticks around as an interim measure, since adopting two technologies is not the same as transitioning from one to another 🙃. finally, some walled gardens or isolated networks, such as management networks, use IPv6-only end-to-end 🔒.
it is impossible to predict with certainty the path IPv6 deployment will have taken when it's complete 🔮. lessons learned so far include aligning costs and benefits (incentive), and ensuring incremental benefit (network effect or backward compatibility) 🫶🌈✨
A.4. HTTP ✨
okay so HTTP has been through like, a lot of glow-ups as a protocol 💅
The very first version [HTTP0.9] was giving pure minimalism 🌸. It had no headers, no status codes, and no explicit versioning. Then HTTP/1.0 [RFC1945] showed up and introduced all of those plus a bunch of other concepts 🎀. It succeeded mostly because HTTP deployment was still pretty new, with a small pool of implementers and a (comparatively) small set of deployments and users ✨.
HTTP/1.1 [RFC7230] (first defined in [RFC2068]) was the attempt to make the protocol ready for the massive scale it was getting deployed on, while also adding some new features 🦋.
HTTP/2 [RFC7540] was mainly about performance 🔥. The big win was request multiplexing, backed up by request prioritization and flow control. It also brought in header compression [RFC7541] and binary framing. ngl, this made it completely backwards incompatible on the wire, but it's still semantically compatible with the older versions 🫶.
A.4.1. Protocol Versioning, Extensions, and 'Grease'
During HTTP/1.1 development there was a LOT of confusion about what the version numbers actually meant, and that resulted in [RFC2145] 😭. Later on, people felt minor versioning was causing more confusion than it was worth, so HTTP/2.0 just became HTTP/2 💅.
This was based on the observation that a lot of implementations ignored the major version number or misread it 💀. Like with many protocol extension points, HTTP versioning never got "greased" by being used often enough, so it became "rusted" and only a limited range of values could interoperate 🥲.
This has been seen in other protocols too, like TLS (see [GREASE] for the receipts), and there are active efforts to find extension points that need that "grease" and to make it look like they're in use ✨.
Besides the protocol version, HTTP's well-greased extension points include header fields, status codes, media types, and cache-control extensions 🌈. HTTP methods, content-encodings, and chunk-extensions get less flexibility, so they need to be extended more cautiously 🙈.
A.4.2. Limits on Changes in Major Versions
Every time the "major" version of HTTP got bumped, there were changes that weren't compatible with the previous versions. That wasn't uniformly successful, given how diverse and huge the deployment and implementations were 😬.
HTTP/1.1 brought in pipelining to improve protocol efficiency. It did get implemented, but interoperability didn't follow 💔.
Partly that's because lots of existing implementations had picked architectures that didn't really lend themselves to supporting it. Pipelining wasn't uniformly implemented, and where it was, support was sometimes incorrect or incomplete 🙃. Since support for pipelining was indicated by the protocol version number itself, interop was hard to achieve. Its inability to completely address head-of-line blocking issues also made pipelining kinda unattractive 🫠.
Likewise, HTTP/1.1's Expect/Continue mechanism relied on wide support for the new semantics it introduced, and it didn't have an adequate fallback strategy for previous versions of the protocol. So interoperability and deployment suffered, and it's still considered a "problem area" for the protocol 😭.
More recently, the HTTP working group decided HTTP/2 was an opportunity to level up security 🔐, making the protocol way stricter than previous versions about the use of TLS. A long list of TLS cipher suites got prohibited, constraints were placed on the key exchange method, and renegotiation was prohibited 🚫.
This did cause deployment problems. Most were minor and transitory, but disabling renegotiation broke deployments that relied on the feature to authenticate clients, and it prompted new work to replace the feature 🥲.
A number of other features or characteristics of HTTP were flagged during the HTTP/2 process as potentially undesirable and considered for removal 👀. This included trailers, the 1xx series of responses, certain modes of request forms, and the unsecured (http://) variant of the protocol.
For each of these, the risk to successfully deploying the new version was judged to be too great to justify removing the feature 🙅. However, deployment of the unsecured variant of HTTP/2 remains extremely limited 🥀.
A.4.3. Planning for Replacement
HTTP/1.1 gave us the Upgrade header field to transition a connection to an entirely different protocol. So far, that's been barely used, other than to enable WebSockets [RFC6455] 🔌.
With performance being a primary motivation for HTTP/2, a new mechanism was needed to avoid spending an additional round trip on protocol negotiation ⏱️. A new mechanism was added to TLS to permit negotiating the new version of HTTP: Application-Layer Protocol Negotiation (ALPN) [RFC7301] ✨. Upgrade was only used for the unsecured variant of the protocol.
ALPN was identified as the primary way future protocol versions would be negotiated 🎯. The mechanism was well-tested during development of the specification, proving that new versions could be deployed safely and easily 🥳. Several draft versions of the protocol were successfully deployed during development, and version negotiation was never shown to be an issue 💯.
Confidence that new versions would be easy to deploy led to a particular design stance that might seem unusual given the advice in [RFC5218], though it's completely consistent with [RFC6709] 🧠: few extension points were added, unless an immediate need was understood.
This decision was made because it'd be easier to revise the entire protocol than to make sure an extension point was correctly specified and implemented so it'd be available when needed 🫶.
IAB Members at the Time of Approval 🎀
- Jari Arkko
- Ralph Droms
- Ted Hardie
- Joe Hildebrand
- Russ Housley
- Lee Howard
- Erik Nordmark
- Robert Sparks
- Andrew Sullivan
- Dave Thaler
- Martin Thomson
- Brian Trammell
- Suzanne Woolf
Acknowledgements 🫶
This document is a product of the IAB Stack Evolution Program, with input from many others. Special shoutouts to Mark Nottingham, Dave Crocker, Eliot Lear, Joe Touch, Cameron Byrne, John Klensin, Patrik Faltstrom, the IETF Applications Area WG, and others who gave helpful input on this doc 💖.
Author's Address 💜
Dave Thaler (editor)
One Microsoft Way
Redmond, WA 98052
United States of America
Email: dthaler@microsoft.com📦 where this page comes from
- ietf: rfc8170 2017-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms