RFC 9170
Long-Term Viability of Protocol Extension Mechanisms
Long-Term Viability of Protocol Extension Mechanisms ✨
Okay so, bestie, let's get into RFC 9170! 🦋 It's an IAB doc, published as Informational (so no standards-track drama here 💅), dated December 2021. The authors are M. Thomson and T. Pauly, and it's ISSN 2070-1721 📚. It doesn't obsolete or update anything, so it's a clean slate 🌸.
Abstract
The whole vibe: being able to change a protocol depends on actually using the extension and version-negotiation stuff that makes change possible 🔥. This doc explores how regular use of new protocol features keeps changes deployable over time. It also gives examples where not using those features made changes harder or more expensive 😭.
Status of This Memo
This doc is NOT on the Internet Standards Track 🙈. It's just published for informational purposes.
It's a product of the Internet Architecture Board (IAB) and holds info the IAB thought was worth keeping on permanent record 📜. It represents the IAB's consensus. Documents the IAB approves are not candidates for any level of Internet Standard, see Section 2 of RFC 7841 💖.
For the current status, errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9170 🧚.
Copyright Notice
Copyright (c) 2021 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 (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions 🎀.
Table of Contents
1. Introduction
2. Imperfect Implementations Limit Protocol Evolution
2.1. Good Protocol Design Is Not Itself Sufficient
2.2. Disuse Can Hide Problems
2.3. Multi-party Interactions and Middleboxes
3. Active Use
3.1. Dependency Is Better
3.2. Version Negotiation
3.3. Falsifying Active Use
3.4. Examples of Active Use
3.5. Restoring Active Use
4. Complementary Techniques
4.1. Fewer Extension Points
4.2. Invariants
4.3. Limiting Participation
4.4. Effective Feedback
5. Security Considerations
6. IANA Considerations
7. Informative References
Appendix A. Examples
A.1. DNS
A.2. HTTP
A.3. IP
A.4. SNMP
A.5. TCP
A.6. TLS
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses1. Introduction 🌈
Okay so, a successful protocol [SUCCESS] has to keep changing so it can keep up with what its users need 💅. New use cases, conditions, and deployment constraints can make a protocol that doesn't change totally obsolete 💀.
Usage patterns and requirements shift over time. Implementations might adjust how they use the protocol within its constraints, the protocol could get extended, or a replacement could be built 🦋. Real-world Internet-scale deployment shows each option has different costs. [TRANSITIONS] looks at protocol evolution more broadly 📚.
An extension point is a mechanism that lets a protocol be changed or enhanced ✨. This doc digs into the specific conditions that decide whether protocol maintainers can actually design and deploy new or modified protocols through those extension points 🫶. Section 2 covers historical examples of trouble with transitions to new features. Section 3 argues that ossified protocols are harder to update and shows how successful protocols use new extensions and code points all the time 🔥. Section 4 lays out extra strategies that might help keep protocol changes possible over time 🧚.
The experience behind this doc is mostly at the "higher" layers of the network stack, in protocols with fewer participants 🍓. Similar issues show up in lots of protocols running at scale, but the trade-offs of some suggested techniques can get way more complicated with many participants, like at the network layer or in routing systems 💜.
2. Imperfect Implementations Limit Protocol Evolution 💀
It can be extremely hard to deploy a protocol change if the implementations it needs to work with don't behave predictably 😭. Different handling of new code points or extensions can come from bugs in implementations or in specifications. Unpredictability can look like errors, crashes, timeouts, sessions suddenly ending, or endpoints just vanishing 🙈.
That risk can make some protocol changes totally infeasible 💅. If a new code point or extension makes one implementation less reliable than the others, even in rare cases, implementations are way less likely to adopt the change 📉.
Deploying a change might mean implementations have to fix a big chunk of the bugs the change exposes 🔧. That's a whole process: figuring out what caused the errors, finding the responsible implementation(s), coordinating a bug fix and release plan, contacting users and/or operators of affected services, and waiting for the fix to roll out 🫠.
Because fixing stuff takes so much effort, these kinds of bugs can outright block some protocol changes 🚫, especially for multi-party protocols or ones considered critical infrastructure (e.g., IP, BGP, DNS, or TLS) 👑. It could even mean coming up with a totally new protocol design that gets the same result a different way 🦋.
This doc only covers cases where extensions aren't deliberately blocked 🎀. Some deployments or implementations have policies that explicitly prohibit unknown capabilities. This is especially true for functions that try to make security guarantees, like firewalls 🔒.
The interoperable features in a protocol are often just the subset that's valuable to the people implementing and deploying it 💖. Future extensibility isn't always part of that set 🥀.
2.1. Good Protocol Design Is Not Itself Sufficient 🎀
People often argue that a carefully designed extension point or version-negotiation capability is critical to the freedom the protocol ultimately offers 💜.
RFC 6709 [EXTENSIBILITY] has tons of well-thought-out advice on designing for extensions ✨. It includes this bit:
This means that, to be useful, a protocol version-negotiation mechanism should be simple enough that it can reasonably be assumed that all the implementers of the first protocol version at least managed to implement the version-negotiation mechanism correctly.
A bunch of protocols have found this isn't enough in practice 😭. Their implementations of these mechanisms are imperfect. Mechanisms that aren't used are the ones that fail most often 💀. The same paragraph from RFC 6709 admits this problem exists but doesn't offer a fix:
The nature of protocol version-negotiation mechanisms is that, by definition, they don't get widespread real-world testing until after the base protocol has been deployed for a while, and its deficiencies have become evident.
Basic interoperability is considered critical early on in a protocol's life 🌸. Wanting to deploy fast can mean focusing early on a reduced feature set, which can push off implementing version-negotiation and extension mechanisms 🥺. That's why these mechanisms get hit especially hard by this problem 💔.
2.2. Disuse Can Hide Problems 🙈
Lots of extension points in protocols have been completely unused, or used so rarely that nobody can count on them working correctly anymore 😬.
Appendix A has examples of disuse across a bunch of widely deployed Internet protocols 📖.
Even when extension points have multiple valid values, if the set of permitted values never changes, there's still a risk that existing implementations won't tolerate new values 🚨. If the set of values for a field, or the order those values appear in, stays fixed for a long time, some implementations might not handle a new value correctly when it finally shows up 😵. For example, TLS implementations broke when new values of the signature_algorithms extension were introduced 💀.
2.3. Multi-party Interactions and Middleboxes 🧚
One of the biggest challenges in deploying new features is making sure everything works with all the actors that could be involved in the protocol 🫶. Even the most superficially simple protocols can involve more actors than you'd think 👀.
The design of extension points needs to consider what actions middleboxes might take in response to a protocol change, and how those actions could affect the protocol's operation 🔍.
Deploying protocol extensions also has to consider the impact on entities beyond protocol participants and middleboxes 🌍. Protocol changes can affect applications or systems that don't interact with the protocol directly, like when a change modifies how data is formatted for an application 🎀.
3. Active Use 🔥
Designing a protocol for extensibility and eventual replacement [EXTENSIBILITY] doesn't guarantee you can actually use those options 💅. The features that enable future evolution need to be interoperable in the first implementations and deployments 🦋. Implementing the mechanisms that support evolution is necessary to keep them available for new uses, and history shows this happens almost exclusively through active mechanism use 📈.
Only by actually using a protocol's extension capabilities is that capability assured 🔒. "Using" here includes specifying, implementing, and deploying capabilities that rely on the extension capability 🛠️. Protocols that don't use a mechanism, or only rarely use it, can end up making that mechanism unreliable 😱.
Implementations that routinely see new values are more likely to handle new values correctly 🌟. More frequent changes improve the odds that incorrect handling or intolerance gets found and fixed ✅. The longer an intolerant implementation stays deployed, the harder it is to correct 😩.
Protocols that routinely add new extensions and code points rarely have trouble adding more, especially when handling of new versions or extensions is well defined 👑. Defining mechanisms alone isn't enough; it's the assured implementation and active use of those mechanisms that decides whether they stay available 💖.
What counts as "active use" can depend a lot on the environment a protocol is deployed in 🌏. The frequency of changes needed to safeguard some mechanisms might be slow enough to let ossification set in for one deployment, while being excessive for others 🐢.
Part 1 of 5 done, bestie! 🫶 More parts coming, so stay tuned 💅✨
3.1. Dependency Is Better 💅✨
okay so the easiest way to make sure a protocol mechanism actually gets used? make handling it critical for an endpoint to even take part in the protocol 🫶 like, implementations have to rely on both the existence of extension mechanisms AND their continued, repeated expansion over time 🔥
for example, SMTP's message format leans on header fields for most of its jobs, including the most basic delivery stuff. no SMTP deployment can dodge implementing header field handling 😭 and because new header fields keep getting defined and used, deployments constantly run into header fields they don't yet (and may never) understand. so an SMTP implementation has to be able to process the header fields it knows AND ignore the ones it doesn't 🦋
so implementing the extensibility mechanism isn't just something the spec says to do, it's literally crucial to the protocol working at all 💖 if an implementation messed that up, everyone would notice fast 👑
BUT (bestie, listen) be careful about assuming that building a dependency on an extension mechanism is enough to keep it available long term 🙈 if the set of possible uses is narrowly constrained and deployments never change, implementations might never see new variations, or they might assume a narrower meaning of what's possible. those implementations can still throw errors when they meet new variations 💀
3.2. Version Negotiation 🎀
like we said in Section 2.1, protocols with version-negotiation mechanisms might not be able to test that feature until a new version is actually deployed 😤 one relatively successful design approach has been to use the protocol selection mechanisms built into a lower-layer protocol to pick the protocol instead 🧚 this could let a version-negotiation mechanism benefit from active use of the extension point by other protocols 🌈
for instance, all published versions of IP have a version number in the four high bits of the first header byte 🍓 however, version selection using that field did NOT work out 💀 ultimately, successful deployment of IPv6 over Ethernet [RFC2464] needed a different EtherType from IPv4. this change took advantage of how already diverse EtherType usage was ✨
other examples of this style of design include Application-Layer Protocol Negotiation ([ALPN]) and HTTP content negotiation (Section 12 of [HTTP]) 🫶
this technique relies on the code point being usable 🔥 for instance, the IP protocol number is known to be unreliable and therefore not suitable [NEW-PROTOCOLS] 😭
3.3. Falsifying Active Use 🌸
"Grease" was originally defined for TLS [GREASE] but other protocols like QUIC [QUIC] have adopted it too 💜 grease treats lack of use as a problem (protocol mechanisms "rusting" shut 🦋) and proposes reserving values for extensions that have no semantic value attached ✨
the design in [GREASE] is aimed at the style of negotiation most used in TLS, where one endpoint offers a set of options and the other picks the one it most prefers from the ones it supports 👑 an endpoint that uses grease randomly offers options (usually just one) from a set of reserved values 🎀 these values are guaranteed to never be assigned real meaning, so its peer will never have a genuine reason to select one of them 🫶
more generally, "greasing" refers to any attempt to exercise extension points without changing endpoint behavior, other than to encourage participants to tolerate new or varying values of protocol elements 💅
the principle grease runs on: an implementation that's regularly exposed to unknown values is less likely to be intolerant when new values show up 🧚 this depends a lot on the assumption that implementing the extension mechanism correctly is as easy or easier than writing code to spot and filter out reserved values 🌈 reserving random or unevenly distributed values for this purpose is thought to discourage special treatment even more 🍓
without reserved greasing code points, an implementation can use code points from spaces set aside for private or experimental use, if such a range exists 🙈 but that comes with the risk of accidentally joining an unwanted experiment 😬 and it can be less effective, since incorrect implementations might still be able to identify those code points and ignore them 💀
also, besides advertising bogus capabilities, an endpoint might selectively disable noncritical protocol elements to test whether its peers can handle the absence of certain capabilities 🔥
ngl this style of defensive design has limits, because it's only superficial 😭 greasing only mimics active use of an extension point, so it only exercises a small part of the mechanisms that support extensibility 🦋 even more critically, it doesn't translate easily to all forms of extension points. for instance, highest mutually supported version (HMSV) negotiation cannot be greased this way 💅 other techniques might be needed for protocols that don't rely on the particular style of exchange that's predominant in TLS ✨
grease is deployed to quickly reveal errors in implementing the mechanisms it protects 🎀 it has been effective at revealing problems in some TLS cases, but the efficacy of greasing isn't proven more generally 🙈 where implementations can tolerate a non-zero error rate in their operation, greasing offers a potential option for safeguarding future extensibility 🫶 however, this relies on there being enough participants willing to invest the effort and tolerate the risk of interoperability failures 💀
3.4. Examples of Active Use 🧚
header fields in email [SMTP], HTTP [HTTP], and SIP [SIP] all come from the same basic design, which amounts to a list of name/value pairs 🌈 there's no evidence of significant barriers to deploying header fields with new names and semantics in email and HTTP, since clients and servers generally ignore headers they don't understand or need 🍓 the widespread deployment of SIP back-to-back user agents (B2BUAs), which generally do NOT ignore unknown fields, means new SIP header fields don't reliably reach peers 😤 this doesn't necessarily cause interoperability issues in SIP, but it does mean features stay unavailable until the B2BUA gets updated ✨ all three protocols can still deploy new features reliably, but SIP features roll out more slowly because more active participants need to support them 👑
another example: the attribute-value pairs (AVPs) in Diameter [DIAMETER] are fundamental to the protocol's design 🔥 any use of Diameter requires exercising the ability to add new AVPs, and that's routinely done without fear that a new feature won't deploy successfully 💖
these examples show that extension points which are heavily used are relatively unaffected by deployment issues that would otherwise block new values for new use cases 🫶
these examples also show that a good design is NOT required for success 💅 on the contrary, success often comes despite shortcomings in the design 😭 for instance, the shortcomings of HTTP header fields are significant enough that there are ongoing efforts to improve the syntax [HTTP-HEADERS] 🙈
3.5. Restoring Active Use 🦋
with enough effort, active use can be used to restore capabilities 💪
Extension Mechanisms for DNS ([EDNS]) was defined to provide extensibility in DNS 🌸 intolerance of the extension in DNS servers led to a fallback method being widely deployed (see Section 6.2.2 of [EDNS]) 😬 that fallback meant EDNS got disabled for affected servers 💀 over time, greater support for EDNS and increased reliance on it for different features motivated a flag day [DNSFLAGDAY], where the workaround was removed 🎀
the EDNS example shows that effort can restore capabilities ✨ this is partly because EDNS was actively used with most resolvers and servers 🔥 so it was possible to force a change that made sure extension capabilities would always be available 👑 however, that took an enormous coordination effort 😭 a small number of incompatible servers, and the names they serve, also became inaccessible to most clients 💔
- Complementary Techniques ✨
the protections to protocol evolution that come from active use (Section 3) can be improved with other defensive techniques 🫶 the techniques listed here might not prevent ossification on their own, but they can make active use more effective 💅
4.1. Fewer Extension Points 🌈
a successful protocol will include many potential types of extensions 🍓 designing multiple types of extension mechanisms, each suited to a specific purpose, might leave some extension points less heavily used than others 🙈
disuse of a specialized extension point might render it unusable 💀 in contrast, having a smaller number of extension points with wide applicability could improve the use of those extension points 🔥 using a shared extension point for any purpose can protect rarer or more specialized uses 🦋
both extensions and core protocol elements use the same extension points in protocols like HTTP [HTTP] and DIAMETER [DIAMETER]; see Section 3.4 👑
4.2. Invariants 🎀
documenting the aspects of the protocol that cannot or will not change as extensions or new versions are added can be a super useful exercise 🧚 Section 2.2 of [RFC5704] defines invariants as:
| Invariants are core properties that are consistent across the |
|---|
| network and do not change over extremely long time-scales. |
understanding which aspects of a protocol are invariant can help guide the process of identifying the parts that might change ✨ [QUIC-INVARIANTS] and Section 9.3 of [TLS13] are both examples of documented invariants 💖
as a means of protecting extensibility, a declaration of protocol invariants is only useful to the extent that protocol participants are willing to allow new uses for the protocol 🫶 a protocol that declares invariants relies on implementations understanding and respecting them 🙈 if active use isn't possible for all non-invariant parts of the protocol, greasing (Section 3.3) might be used to improve the chance that invariants get respected 💅
protocol invariants need to be clearly and concisely documented 😤 including examples of aspects of the protocol that are NOT invariant, such as Appendix A of [QUIC-INVARIANTS], can help clarify intent 🌸
4.3. Limiting Participation 🦋
reducing the number of entities that can participate in a protocol, or limiting the extent of their participation, can reduce how many entities might affect extensibility 💜 using TLS or other cryptographic tools can therefore reduce the number of entities that can influence whether new features are usable 🔥
[PATH-SIGNALS] also recommends encryption and integrity protection to limit participation 🫶 for example, the QUIC protocol [QUIC] uses encryption to limit the information available to middleboxes, and integrity protection prevents modification ✨
4.4. Effective Feedback 📬✨
Okay so, feedback systems aren't a direct way to protect extensibility mechanisms, but they are seriously important for spotting problems 🔍 Bestie, it's giving detective energy.
The visibility of errors is critical to the success of techniques like grease (see Section 3.3) 🦋 The grease design works best when a deployment can actually detect and report errors. If errors get ignored, problems can get entrenched and stick around forever 🥀
Feedback on errors matters even more during the development and early deployment of a change 🌱 It can also be super helpful to turn off automatic error recovery methods while you're developing, so the errors don't get quietly fixed before you ever see them 🙈
Automated feedback systems are a must for automated systems, or for anywhere the error recovery is automated too 🤖 Like, connection failures with HTTP alternative services [ALT-SVC] are not permitted to affect the outcome of transactions. So an automated feedback system for capturing failures in alternative services is therefore necessary, otherwise those failures would never get detected 😭
How errors get gathered and reported depends a lot on the kind of protocol deployment and on who receives the report 💅 End users, developers, and network operations all have totally different needs for how error reports are created, managed, and acted upon. Iykyk 💜
Automated delivery of error reports can be critical for fixing deployment errors as early as possible 🚀 You can see this in [DMARC] and [SMTP-TLS-REPORTING], and it's honestly so iconic 👑
5. Security Considerations 🔐
Okay, real talk, bestie 🥺 Lots of the problems in this document aren't caused by someone deliberately being a villain 😈 They come from mistakes, decisions made without enough context, or just plain neglect. In other words, they aren't the result of opposition by an adversary. So the recommended measures generally assume that other protocol participants won't take deliberate action to prevent protocol evolution 🫶
The use of cryptographic techniques to exclude potential participants is the only strong measure that this document recommends. But authorized protocol peers are most often the ones responsible for the problems we identified, which can mean that cryptography is insufficient to exclude them 💀 Not me realizing the bad actor is sometimes the friend in the group chat 😭
The ability to design, implement, and deploy new protocol mechanisms can be critical to security 🛡️ In particular, it's really important to be able to replace cryptographic algorithms over time [AGILITY]. For example, preparing for the replacement of weak hash algorithms was made more difficult through misuse [HASH] 🍓 Learn from it, periodt.
6. IANA Considerations 🧾
This document has no IANA actions. Nothing to register here, bestie 🌸
7. Informative References 📚✨
Okay bestie, here's the reading list 🤓 Every single source the doc points to, with all the details, so you can go deeper if you want to. Look at all those DOIs, I'm obsessed 💜
[AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>.
[ALPN] 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, <https://www.rfc-editor.org/info/rfc7301>.
[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[DIAMETER] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>.
[DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[DNSFLAGDAY]
"DNS Flag Day 2019", May 2019,
<https://dnsflagday.net/2019/>.
[EDNS] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[EXT-TCP] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
Handley, M., and H. Tokuda, "Is it still possible to
extend TCP?", IMC '11: Proceedings of the 2011 ACM SIGCOMM
conference on Internet measurement conference,
DOI 10.1145/2068816.2068834, November 2011,
<https://doi.org/10.1145/2068816.2068834>.
[EXTENSIBILITY]
Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/info/rfc6709>.
[GREASE] Benjamin, D., "Applying Generate Random Extensions And
Sustain Extensibility (GREASE) to TLS Extensibility",
RFC 8701, DOI 10.17487/RFC8701, January 2020,
<https://www.rfc-editor.org/info/rfc8701>.
[HASH] Bellovin, S. and E. Rescorla, "Deploying a New Hash
Algorithm", Proceedings of NDSS, 2006,
<https://www.cs.columbia.edu/~smb/papers/new-hash.pdf>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
draft-ietf-httpbis-semantics-19, September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
semantics-19>.
[HTTP-HEADERS]
Nottingham, M. and P-H. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/info/rfc8941>.
[HTTP11] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
ietf-httpbis-messaging-19, September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
messaging-19>.
[INTOLERANCE]
Kario, H., "Re: [TLS] Thoughts on Version Intolerance",
July 2016, <https://mailarchive.ietf.org/arch/msg/tls/
bOJ2JQc3HjAHFFWCiNTIb0JuMZc>.
[MPTCP] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>.
[MPTCP-HOW-HARD]
Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M.,
Duchene, F., Bonaventure, O., and M. Handley, "How Hard
Can It Be? Designing and Implementing a Deployable
Multipath TCP", April 2012,
<https://www.usenix.org/conference/nsdi12/technical-
sessions/presentation/raiciu>.
[NEW-PROTOCOLS]
Barik, R., Welzl, M., Fairhurst, G., Elmokashfi, A.,
Dreibholz, T., and S. Gjessing, "On the usability of
transport protocols other than TCP: A home gateway and
internet path traversal study", Computer Networks, Vol.
173, pp. 107211, DOI 10.1016/j.comnet.2020.107211, May
2020, <https://doi.org/10.1016/j.comnet.2020.107211>.
[PATH-SIGNALS]
Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC",
RFC 8999, DOI 10.17487/RFC8999, May 2021,
<https://www.rfc-editor.org/info/rfc8999>.
[RAv4] Katz, D., "IP Router Alert Option", RFC 2113,
DOI 10.17487/RFC2113, February 1997,
<https://www.rfc-editor.org/info/rfc2113>.
[RAv6] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, DOI 10.17487/RFC2711, October 1999,
<https://www.rfc-editor.org/info/rfc2711>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>.
[RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated
Protocol Development Considered Harmful", RFC 5704,
DOI 10.17487/RFC5704, November 2009,
<https://www.rfc-editor.org/info/rfc5704>.
[RRTYPE] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[SMTP-TLS-REPORTING]
Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J.,
and M. Risher, "SMTP TLS Reporting", RFC 8460,
DOI 10.17487/RFC8460, September 2018,
<https://www.rfc-editor.org/info/rfc8460>.
[SNI] Langley, A., "[TLS] Accepting that other SNI name types
will never work.", March 2016,
<https://mailarchive.ietf.org/arch/msg/
tls/1t79gzNItZd71DwwoaqcQQ_4Yxc>.
[SNMPv1] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", RFC 1157,
DOI 10.17487/RFC1157, May 1990,
<https://www.rfc-editor.org/info/rfc1157>.
[SPF] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/info/rfc5218>.
[TCP] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[TRANSITIONS]
Thaler, D., Ed., "Planning for Protocol Adoption and
Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
May 2017, <https://www.rfc-editor.org/info/rfc8170>.Appendix A. Examples 🎀
Okay so this appendix is a little tour of protocols that ran into trouble at different layers of the stack. Real stories, real mess, very educational 🫶
A.1. DNS 🌐
Ossified DNS code bases and systems meant that new Resource Record Codes (RRCodes) were basically unusable 😭 A brand-new code point could take years of coordinating between implementations and deployments before anyone could actually rely on it. So people overloaded the TXT record instead, just to dodge all that effort and delay. SPF did exactly this, along with other protocols [SPF].
It wasn't until the standard way of handling new RRCodes [RRTYPE] was considered widely deployed that new RRCodes could finally be safely created and used ✨
A.2. HTTP 🦋
HTTP has a bunch of really effective extension points, on top of the header fields we already talked about 💅 It also has some extension points that get used so rarely that they might not be usable at all, honestly 💀
Extension points in HTTP that might be unwise to use include the extension point on each chunk in the chunked transfer coding (Section 7.1 of [HTTP11]), the ability to use transfer codings other than the chunked coding, and the range unit in a range request (Section 14 of [HTTP]). So, be careful in those spots, bestie 🫶
A.3. IP 🌐
okay bestie, the version field in IP was literally rendered useless when it got encapsulated over Ethernet 😭 which is why IPv6 needed its own new EtherType [RFC2464] 💅. Part of the reason is that Layer 2 devices were making version-independent assumptions about the structure of the IPv4 header 🙈
Protocol identifiers or code points that are reserved for future use can be especially problematic 💀. If you reserve values without attributing any semantics to them, people end up attaching diverse or conflicting meanings with no hope of interoperability. The 224/3 address space in IPv4 is a classic example: [RFC0791] reserved it without assigning any semantics. [RFC1112] partially reclaimed that reserved space for multicast (224/4), but the remaining address space (240/4) has never been successfully reclaimed for any purpose 🥲.
For protocols that can use negotiation to attribute semantics to values, unused code points can maybe be reclaimed for active use ✨, though this requires that the negotiation include all protocol participants. For something as fundamental as addressing, negotiation is difficult or even impossible, since every node on the network path plus any potential alternative paths would need to be involved 😩.
IP Router Alerts [RAv4][RAv6] use IP options or extension headers to indicate that data is intended for consumption by the next-hop router rather than the addressed destination. The deployment of router alerts was unsuccessful in part because of the realities of processing IP packets at line rates, combined with bad assumptions in the protocol design about those performance constraints. But it wasn't all design problems or bugs, because the capability was also deliberately blocked at some routers 🚫.
A.4. SNMP 🦋
As a counter example 🙃, the first version of the Simple Network Management Protocol (SNMP) [SNMPv1] says that unparseable or unauthenticated messages are simply discarded without any response:
| It then verifies the version number of the SNMP message. If there
| is a mismatch, it discards the datagram and performs no further
| actions.When SNMP versions 2, 2c, and 3 came along, older agents did exactly what the protocol specifies. Deployment of the new versions was likely successful because the handling of newer versions was both clear and simple 🫶.
A.5. TCP 🧵
Extension points in TCP [TCP] have been rendered difficult to use, largely due to middlebox interactions; see [EXT-TCP] 🙄.
For instance, multipath TCP ([MPTCP]) can only be deployed opportunistically; see [MPTCP-HOW-HARD]. Since MPTCP is a protocol enhancement that doesn't impair the connection if it is blocked, network path intolerance of the extension only results in the multipath functionality becoming unavailable 🤷.
In comparison, the deployment of TCP Fast Open ([TFO]) critically depends on extension capability being widely available. Though very few network paths were intolerant of the extension in absolute terms, TCP Fast Open could not be deployed as a result 😭.
A.6. TLS 🔐
Transport Layer Security (TLS) [TLS12] gives us examples of where a design that is objectively sound fails when it's incorrectly implemented 💀. TLS also shows us failures in protocol version negotiation and extensibility.
Version negotiation in TLS 1.2 and earlier uses the "Highest mutually supported version (HMSV)" scheme exactly as it is described in [EXTENSIBILITY]. However, clients are unable to advertise a new version without causing a non-trivial proportion of sessions to fail, due to bugs in server and middlebox implementations 😵.
Intolerance to new TLS versions is so severe [INTOLERANCE] that TLS 1.3 [TLS13] abandoned HMSV version negotiation for a new mechanism 🫠.
The server name indication (SNI) [TLS-EXT] in TLS is another excellent example of the failure of a well-designed extensibility point 💔. SNI uses the same technique for extensions that is used successfully in other parts of the TLS protocol. The original design of SNI anticipated the ability to include multiple names of different types.
SNI was originally defined with just one type of name: a domain name. No other type has ever been standardized, though several have been proposed. Despite an otherwise exemplary design, SNI is so inconsistently implemented that any hope of using the extension point it defines has been abandoned [SNI] 😭🥀.
IAB Members at the Time of Approval 👑
Internet Architecture Board members at the time this document was approved for publication were:
- Jari Arkko
- Deborah Brungard
- Ben Campbell
- Lars Eggert
- Wes Hardaker
- Cullen Jennings
- Mirja Kühlewind
- Zhenbin Li
- Jared Mauch
- Tommy Pauly
- David Schinazi
- Russ White
- Jiankang Yao
Acknowledgments 💜
Toerless Eckert, Wes Hardaker, Mirja Kühlewind, Eliot Lear, Mark Nottingham, and Brian Trammell made significant contributions to this document 🫶✨.
Authors' Addresses 🎀
Martin Thomson
Email: mt@lowentropy.net
Tommy Pauly
Email: tpauly@apple.com
📦 where this page comes from
- ietf: rfc9170 2021-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms