RFC 6709

Design Considerations for Protocol Extensions

📅 published September 2012, from ietf

Design Considerations for Protocol Extensions 🎀

Okay bestie, let's start with the basics ✨ This is RFC 6709 and it's an Informational doc, so it's a permanent record and not a Standards Track spec 📜

Author(s): B. Carpenter, B. Aboba (Ed.), S. Cheshire 💖
Published by: the Internet Architecture Board (IAB) 🧚
Category: Informational
ISSN: 2070-1721
Date: September 2012 🍓
Obsoletes / Updates: the title block doesn't list any, so this doc doesn't obsolete or update anything else 🌸

Abstract 💖

This doc is all about the architecture behind making Internet protocols extensible, and it focuses on design considerations 🧚 It's meant to help people designing base protocols and people designing extensions, and it includes case studies too 🫶 A companion doc, RFC 4775 (BCP 125), covers the procedures for extending IETF protocols.

Status of This Memo 🦋

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. 💅

Info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6709 🔥

Copyright Notice 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they spell out your rights and restrictions with respect to this document 👑

Table of Contents ⭐

   1. Introduction ....................................................3
      1.1. Requirements Language ......................................4
   2. Routine and Major Extensions ....................................4
      2.1. What Constitutes a Major Extension? ........................4
      2.2. When is an Extension Routine? ..............................6
   3. Architectural Principles ........................................7
      3.1. Limited Extensibility ......................................7
      3.2. Design for Global Interoperability .........................8
      3.3. Architectural Compatibility ...............................12
      3.4. Protocol Variations .......................................13
      3.5. Testability ...............................................16
      3.6. Protocol Parameter Registration ...........................16
      3.7. Extensions to Critical Protocols ..........................17
   4. Considerations for the Base Protocol ...........................18
      4.1. Version Numbers ...........................................19
      4.2. Reserved Fields ...........................................22
      4.3. Encoding Formats ..........................................23
      4.4. Parameter Space Design ....................................23
      4.5. Cryptographic Agility .....................................26
      4.6. Transport .................................................27
      4.7. Handling of Unknown Extensions ............................28
   5. Security Considerations ........................................29
   6. References .....................................................30
      6.1. Normative References ......................................30
      6.2. Informative References ....................................30
   7. Acknowledgments ................................................35
   8. IAB Members at the Time of Approval ............................35
   Appendix A.  Examples .............................................36
      A.1. Already-Documented Cases ..................................36
      A.2. RADIUS Extensions .........................................36
      A.3. TLS Extensions ............................................39
      A.4. L2TP Extensions ...........................................41

1. Introduction 🧚

Okay so when IETF Working Groups (WGs) build protocols, they often add ways for those protocols to get extended later 💅 Designing in extensibility is often a good call. As described in "What Makes for a Successful Protocol" [RFC5218], a "wildly successful" protocol is one that becomes widely used in ways nobody originally saw coming 🚀 Well-designed extension mechanisms help protocols evolve and make it easier to roll out small changes in an interoperable way. BUT (and this is the tea ☕) extensions also carry the risk of unintended consequences, like interoperability issues, operational problems, or security vulnerabilities 💀

Proliferation of extensions can get really expensive, even when they're well designed 😭 As noted in "Simple Mail Transfer Protocol" [RFC5321] Section 2.2.1:

Experience with many protocols has shown that protocols with few options tend towards ubiquity, whereas protocols with many options tend towards obscurity. Each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs.

This is not a new worry, tbh 🙈 "TCP Extensions Considered Harmful" [RFC1263] came out back in 1991. The word "Extend" or "extension" shows up in the title of more than 400 existing Request for Comments (RFC) documents 🦋 Even so, generic extension considerations had never been written down before ✨

The whole point of this doc is to lay out the architectural principles of solid extensibility design, so that the risks get minimized 🫶 Formal procedures for extending IETF protocols are covered in "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775] 📜

Here's how the rest of this doc is set up 🌸 Section 2 talks about routine and major extensions. Section 3 covers architectural principles for protocol extensibility. Section 4 explains how base protocol designers can anticipate and make it easier to create later extensions safely and reliably. Section 5 is about security considerations. Appendix A has the case studies 💜

Readers are advised to study the whole document, since all the considerations are closely linked. No skipping, bestie 🙈

1.1. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" BCP 14 [RFC2119] 🔥

2. Routine and Major Extensions 🌈

The risk of unintended consequences from an extension is especially high when a different team does the extending than the original designers, because that team may wander outside the implicit design constraints or assumptions 😬 So it's really important for the original designers to spell out those design constraints and assumptions. That way extensions can be done carefully, with a full understanding of the base protocol, existing implementations, and current operational practice 🧠

To help extension designers and reviewers out, protocol docs should give guidelines on how extensions should be done, plus guidance on how the extension mechanisms should be used ✨

Protocol components that are designed specifically to allow extensibility should be clearly marked, with specific and complete instructions on how to extend them 💅 This includes the review process for extension proposals. Do they need community review? If so, how much, and by whom? 👀

How much review an extension needs usually depends on what kind of extension it is. Routine extensions may need minimal review, while major extensions may need wide review 💖 Which extensions count as 'routine' and which count as 'major' is covered in the sections that follow 🦋

2. Routine and Major Extensions 🎀

2.1. What Constitutes a Major Extension? 💅

okay so major extensions can have traits that lead to interoperability failures, security vulnerabilities, or operational problems 😭 when those traits show up, you have to be extra careful about backward compatibility with implementations and deployments of the unextended protocol, plus the chance of accidentally introducing security or operational exposures 🙈

extension designers should check their design for these issues:

Modifications or extensions to the underlying protocol. ✨ an extension document should be considered to update the underlying protocol specification if an implementation of the underlying protocol would need to be updated to accommodate the extension. this shouldn't be necessary if the underlying protocol was designed with a modular interface. examples of extensions modifying the underlying protocol include specifying additional transports (see Section 4.6), changing protocol semantics, or defining new message types that may require implementation changes in existing and deployed implementations of the protocol, even if they don't want to use the new functions. a base protocol that doesn't uniformly permit "silent discard" of unknown extensions may automatically land in this category, even for apparently minor extensions 👀 handling of "unknown" extensions is discussed in more detail in Section 4.7.
Changes to the basic architectural assumptions. 🧚 this may include assumptions that are stated explicitly or ones that implementers have quietly assumed. for example, adding a requirement for session state to a previously stateless protocol would count 💀
New usage scenarios not originally intended or investigated. 🌈 this can lead to operational difficulties once deployed, even when the "on-the-wire" format hasn't changed. for example, the amount of traffic the protocol carries may go up a lot, packet sizes may grow, and widely deployed implementation algorithms may not scale or otherwise be up to the new task 😩 a new DNS Resource Record (RR) type that's too big to fit into a single UDP packet could cause interoperability problems with existing DNS clients and servers. similarly, the extra traffic from an extension to a routing protocol could hurt the performance or stability of implementations that don't implement the extension 🚦
Changes to the extension model. 🔥 adverse impacts are very likely if the base protocol has an extension mechanism and the proposed extension doesn't fit the model used to create and define that mechanism. extensions with the same properties the mechanism was designed to anticipate are way less likely to be disruptive than extensions that don't fit the model 💜 also, changes to the extension model itself (including changes that limit further extensibility) can create interoperability problems.
Changes to protocol syntax. 🍓 changing protocol syntax brings the potential for backward-compatibility issues. if at all possible, extensions should be designed to be compatible with existing syntax so interoperability failures get avoided ✨
Interrelated extensions to multiple protocols. 🦋 a set of interrelated extensions spanning multiple protocols typically carries a bigger risk of interoperability issues or incompatibilities than a simple extension does. that's why these proposals should get earlier and more in-depth review than unitary extensions 🫶
Changes to the security model. 🔐 changes to the protocol security model (or even adding new security mechanisms inside an existing framework) can introduce security vulnerabilities or hurt operations. so these proposals should go through security review as well as operational review 😱 security considerations are discussed in Section 5.
Performance impact. 🐢 an extension that affects performance can have bad consequences, especially if the performance of existing deployments takes a hit 📉

2.2. When is an Extension Routine? 🌸

an extension may be considered 'routine' if it doesn't meet the criteria for being a 'major' extension AND its handling is opaque to the protocol itself (for example, it doesn't substantially change the pattern of messages and responses) 🎀 for this to apply, no changes to the base protocol can be required, and no changes can be required to existing and currently deployed implementations unless they use the extension. furthermore, existing implementations shouldn't be impacted. this typically requires that implementations be able to ignore 'routine' extensions without ill effects 💖

examples of routine extensions include the Dynamic Host Configuration Protocol (DHCP) vendor-specific option [RFC2132], Remote Authentication Dial In User Service (RADIUS) Vendor-Specific Attributes [RFC2865], the enterprise Object IDentifier (OID) tree for Management Information Base (MIB) modules, and vendor Multipurpose Internet Mail Extension (MIME) types. these can safely be made with minimal discussion ✨

processes that allow routine extensions with minimal or no review (such as "First Come First Served" (FCFS) allocation [RFC5226]) should be used sparingly 🙃 in particular, they should be limited to cases that are unlikely to cause interoperability problems or security or operational exposures.

experience has shown that even routine extensions can benefit from expert review 🧐 for example, even though DHCP carries opaque data, defining a new option using completely unstructured data may produce an option that's unnecessarily hard for clients and servers to process 🤯

3. Architectural Principles 🦋

this section describes the basic principles of protocol extensibility 💜

Extensibility features should be limited to what is reasonably anticipated when the protocol is developed.
Protocol extensions should be designed for global interoperability. 🌍
Protocol extensions should be architecturally compatible with the base protocol.
Protocol extension mechanisms should not be used to create incompatible protocol variations.
Extension mechanisms need to be testable. 🧪
Protocol parameter assignments need to be coordinated to avoid potential conflicts.
Extensions to critical components require special care. a critical component is one whose failure can lead to Internet-wide reliability and security issues or performance degradation 🚨

3.1. Limited Extensibility 🧚

protocols should not be made more extensible than clearly necessary at inception, so they can be optimized along dimensions (e.g., bandwidth, state, memory requirements, deployment time, latency, etc.) that matter most for the most common use cases 🍰

the process for defining new extensibility mechanisms should make sure adequate review of proposed extensions happens before widespread adoption 🔍

as noted in "What Makes for a Successful Protocol" [RFC5218], "wildly successful" protocols far exceed their original goals, in terms of scale, purpose (being used in scenarios far beyond the initial design), or both 🚀 this implies that not all potential uses may be known at inception. as a result, extensibility mechanisms may need to be revisited as additional use cases show up 🔄 however, this doesn't mean an initial design needs to account for every potential need at inception 🙅‍♀️

3.2. Design for Global Interoperability 🌏

Section 3.1 of "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775] notes:

According to its Mission Statement [RFC3935], the IETF produces high quality, relevant technical and engineering documents, including protocol standards. The mission statement goes on to say that the benefit of these standards to the Internet "is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users". One consequence of this mission is that the IETF designs protocols for the single Internet. The IETF expects its protocols to work the same everywhere. Protocol extensions designed for limited environments may be reasonable provided that products with these extensions interoperate with products without the extensions. Extensions that break interoperability are unacceptable when products with and without the extension are mixed. It is the IETF's experience that this tends to happen on the Internet even when the original designers of the extension did not expect this to happen. Another consequence of this definition of interoperability is that the IETF values the ability to exchange one product implementing a protocol with another. The IETF often specifies mandatory-to-implement functionality as part of its protocols so that there is a core set of functionality sufficient for interoperability that all products implement. The IETF tries to avoid situations where protocols need to be profiled to specify which optional features are required for a given environment, because doing so harms interoperability on the Internet as a whole.

since the global Internet is more than a collection of incompatible protocols (or "profiles") for use in separate private networks, implementers supporting extensions in shipping products or multi-site experimental usage must assume that systems will need to interoperate on the global Internet 🌐

a key requirement for interoperable extension design is that the base protocol must be well designed for interoperability and that extensions must have unambiguous semantics 🫧 ideally, the protocol mechanisms for extension and versioning should be described well enough that compatibility can be assessed on paper. otherwise, when two "private" or "experimental" extensions run into each other on a public network, unexpected interoperability problems may occur 😬 however, as noted in the Transport Layer Security (TLS) case study (Appendix A.3), it isn't enough to design extensibility carefully; it also has to be implemented carefully 🔧✨

3.2.1. Private Extensions 🧳

Okay bestie, plot twist: private networks are never as private as they promise. Laptops are basically little travellers hopping from network to network, and networks that were meant to stay separate keep getting plugged into each other later. 💀

Picture this. Your work laptop has a "private" extension installed, and since it's portable, it's constantly connecting to your home network or some hotel wifi. If that "private" extension doesn't play nice with the unextended version of the same protocol, things are going to break. 😭

It gets messier. "Private" extensions can also clash with each other 🙈. Imagine one site decides that DHCP [RFC2132] option code 62 means one thing, and another site uses 62 for something totally different and incompatible. A vendor making portable devices might literally be unable to build something that works correctly in both places. Not ideal, bestie.

One way people tried to fix this was by reserving chunks of an identifier namespace for "limited applicability" or "site-specific" use. Think X- headers in email messages [RFC822] or P- headers in SIP [RFC3427]. However, as noted in "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols" [RFC6648], Appendix B:

The primary problem with the "X-" convention is that unstandardized parameters have a tendency to leak into the protected space of standardized parameters, thus introducing the need for migration from the "X-" name to a standardized name. Migration, in turn, introduces interoperability issues (and sometimes security issues) because older implementations will support only the "X-" name and newer implementations might support only the standardized name. To preserve interoperability, newer implementations simply support the "X-" name forever, which means that the unstandardized name has become a de facto standard (thus obviating the need for segregation of the name space into standardized and unstandardized areas in the first place).

So the "X-" prefix basically becomes a standard by accident. 🙃 As a result, the notion of "X-" headers from the 1982 Internet Message Format standard [RFC822] was removed when the specification was updated in 2001 [RFC2822]. Within SIP, the guidance published in 2002 regarding "P-" headers [RFC3427] was deprecated eight years later in Section 4 of the 2010 update [RFC5727]. More generally, as noted in Section 1 of the "X-" prefix deprecation document [RFC6648]:

This document generalizes from the experience of the email and SIP communities by doing the following: 1. Deprecates the "X-" convention for newly defined parameters in application protocols, including new parameters for established protocols. This change applies even where the "X-" convention was only implicit, and not explicitly provided, such as was done for email in [RFC822].

Honestly, the lesson is simple: stop using the X- prefix. 💅

3.2.2. Local Use 🏠

Values designated as "experimental" or "local use" are only appropriate in limited circumstances, like early implementations of an extension restricted to a single site. ✨

For example, "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers" [RFC4727] discusses experimental values for IP and transport headers, and "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] defines experimental/local use ranges for differentiated services code points.

Such values should be used with care and only for their stated purpose: experiments and local use. They are unsuitable for Internet-wide use, since they may be used for conflicting purposes and thereby cause interoperability failures. Packets containing experimental or local use values must not be allowed out of the domain in which they are meaningful. 🚧

Section 1 of "Assigning Experimental and Testing Numbers Considered Useful" BCP 82 [RFC3692] provides guidance on the use of experimental code points:

Numbers in the experimentation range ... are not intended to be used in general deployments or be enabled by default in products or other general releases. In those cases where a product or release makes use of an experimental number, the end user must be required to explicitly enable the experimental feature and likewise have the ability to chose and assign which number from the experimental range will be used for a specific purpose (i.e., so the end user can ensure that use of a particular number doesn't conflict with other on-going uses). Shipping a product with a specific value pre-enabled would be inappropriate and can lead to interoperability problems when the chosen value collides with a different usage, as it someday surely will. From the above, it follows that it would be inappropriate for a group of vendors, a consortia, or another Standards Development Organization to agree among themselves to use a particular value for a specific purpose and then agree to deploy devices using those values. By definition, experimental numbers are not guaranteed to be unique in any environment other than one where the local system administrator has chosen to use a particular number for a particular purpose and can ensure that a particular value is not already in use for some other purpose. Once an extension has been tested and shown to be useful, a permanent number could be obtained through the normal assignment procedures.

However, as noted in Appendix B of the "X-" prefix deprecation document [RFC6648], assigning a parameter block for experimental use is only necessary when the parameter pool is limited:

"Assigning Experimental and Testing Numbers Considered Useful" ... implies that the "X-" prefix is also useful for experimental parameters. However, BCP 82 addresses the need for protocol numbers when the pool of such numbers is strictly limited (e.g., DHCP options) or when a number is absolutely required even for purely experimental purposes (e.g., the Protocol field of the IP header). In almost all application protocols that make use of protocol parameters (including email headers, media types, HTTP headers, vCard parameters and properties, URNs, and LDAP field names), the name space is not limited or constrained in any way, so there is no need to assign a block of names for private use or experimental purposes.... Therefore, it appears that segregating the parameter space into a standardized area and a unstandardized area has few, if any, benefits and has at least one significant cost in terms of interoperability.

Translation: splitting the namespace into "official" and "unofficial" zones isn't worth the drama. Pick the standard name and move on. 🌸

3.2.3. Multi-Site Experiments 🧪

Where an experiment is undertaken among a diverse set of experimental sites connected via the global Internet, the use of "experimental" or "local use" code points is inadvisable. This might include, for example, sites that take a prototype implementation of some protocol and use that both within their site but, importantly, among the full set of other sites interested in that protocol. In such a situation, it is impractical and probably impossible to coordinate the de-confliction of "experimental" code points. Section 4.1 of the IANA Considerations guidelines document [RFC5226] notes:

For private or local use ... No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways.... assignments are not generally useful for broad interoperability. It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use).

The Host Identity Protocol (HIP) [RFC5201] and the Locator/ID Separation Protocol [LISP] are examples of sets of experimental sites collaborating among themselves, though not necessarily in a tightly coordinated way. Both HIP and LISP handled this by getting unique non-experimental code points allocated to HIP and LISP, respectively, at the time of publication of their respective Experimental RFCs. That's the glow-up path, babe. 🦋

3.3. Architectural Compatibility 🧩

Since protocol extension mechanisms may impact interoperability, it is important that they be architecturally compatible with the base protocol. 💖

This includes understanding what current implementations do and how a proposed extension will interact with deployed systems. Is it clear when a proposed extension (or its proposed usage), if widely deployed, will operationally stress existing implementations or the underlying protocol itself? If this is not explained in the base protocol specification, is this covered in an extension design guidelines document? 🤔

As part of the definition of a new extension, it is important to address whether the extension makes use of features as envisaged by the original protocol designers, or whether a new extension mechanism is being invented. If a new extension mechanism is being invented, then architectural compatibility issues need to be addressed.

To assist in the assessment of architectural compatibility, protocol documents should provide guidelines explaining how extensions should be performed, and guidance on how protocol extension mechanisms should be used.

Protocol components that are designed with the specific intention of allowing extensibility should be clearly identified, with specific and complete instructions on how to extend them. This includes the process for adequate review of extension proposals: do they need community review, and if so, how much and by whom? 👀

Documents relying on extension mechanisms need to explicitly identify the mechanisms being relied upon. For example, a document defining new data elements should not implicitly define new data types or protocol operations without explicitly describing those dependencies and discussing their impact. Where extension guidelines are available, mechanisms need to indicate whether they are compliant with those guidelines and offer an explanation if they are not. No sneaky implicit stuff, okay? 🫶

Examples of documents describing extension guidelines include:

"Guidelines for Extending the Extensible Provisioning Protocol (EPP)" [RFC3735], which provides guidelines for use of EPP's extension mechanisms to define new features and object management capabilities.
"Guidelines for Authors and Reviewers of MIB Documents" BCP 111 [RFC4181], which provides guidance to protocol designers creating new MIB modules.
"Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)" [RFC4485], which outlines guidelines for authors of SIP extensions.
"Considerations for Lightweight Directory Access Protocol (LDAP) Extensions" BCP 118 [RFC4521], which discusses considerations for designers of LDAP extensions.
"RADIUS Design Guidelines" BCP 158 [RFC6158], which provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol.

3.4. Protocol Variations ✨

Okay so protocol variations are the sneakiest mess 💀. These are specs that look sooo similar to the original but don't interoperate with each other or with the original, and that's even worse for interop than extensions 😭. In general, they should be avoided 🙅‍♀️. Variations usually come from incompatible protocol extensions, uncoordinated protocol development, and poorly designed "profiles" 🫠.

Designing a protocol for extensibility has this ironic side effect 🙃: it can make it super easy to build incompatible variations. So protocol extension mechanisms should not be used to create incompatible forks in development 🚫. An extension can cause interoperability failures unless the extended protocol correctly supports all mandatory and optional features of the unextended base protocol, and base protocol implementations keep operating correctly when the extensions are present. On top of that, an extension has to interoperate with other extensions too 🧩.

As noted in Section 1 of "Uncoordinated Protocol Development Considered Harmful" [RFC5704], incompatible forks in development can result from the uncoordinated adaptation of a protocol, parameter, or code point 👀:

In particular, the IAB considers it an essential principle of the protocol development process that only one SDO maintains design authority for a given protocol, with that SDO having ultimate authority over the allocation of protocol parameter code-points and over defining the intended semantics, interpretation, and actions associated with those code-points.

Note that problems can still happen even when one Standards Development Organization (SDO) maintains design authority, if protocol parameter code points get reused 😬. For example, EAP-FAST [RFC5421][RFC5422] reused previously assigned Extensible Authentication Protocol (EAP) type codes. As described in the IESG note in the EAP-FAST document [RFC5421]:

The reuse of previously assigned EAP Type Codes is incompatible with EAP method negotiation as defined in RFC 3748.

3.4.1. Profiles 🎀

Profiling is a super common technique for improving interoperability within a target environment or set of scenarios. Generally speaking, there are two approaches to profiling 💅:

a) Removal or downgrading of normative requirements (thereby creating potential interoperability problems).
b) Elevation of normative requirement levels (such as from a MAY/SHOULD to a MUST). This can be done in order to improve interoperability by narrowing potential implementation choices (such as when the underlying protocol is ill-defined enough to permit non-interoperable yet compliant implementations) or to meet specific operational requirements (such as enabling use of stronger cryptographic mechanisms than those mandated in the specification).

Approach a) is potentially harmful, but approach b) may be beneficial ✨.

So profilers need to stay aware of what removing normative requirements actually does 🧐. This matters so profiled implementations don't cause interoperability problems when they talk to others over the global Internet. As noted in Section 6 of "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119], imperatives are to be used with care, and as a result, removing them within a profile is likely to have serious consequences 😳:

Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.

Recommendations can't just be dropped from profiles either 🙅‍♀️. As noted in Sections 3 and 4 of the Key Words document [RFC2119], recommendations cannot be removed from profiles without serious consideration:

[T]here may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Even removing optional features and requirements can have consequences 🌸. As noted in Section 5 of the Key Words document [RFC2119], implementations that don't support optional features still have to make sure they interoperate with implementations that do:

An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

3.5. Testability 🧪

Experience has shown that it isn't enough to just specify extensibility and backward compatibility correctly in an RFC 🙄. It's also important that implementations actually respect the compatibility mechanisms, or non-interoperable pairs of implementations can show up. The TLS case study (Appendix A.3) shows how big a deal this can be 😭.

To figure out whether protocol extension mechanisms have been implemented properly, testing is required. But for that to be possible, test cases need to be developed 📝. If a base protocol document specifies extension mechanisms but never uses them or gives examples, it may not be possible to develop effective test cases from the base protocol specification alone. So base protocol implementations may not get tested properly, and non-compliant extension behavior may not get caught until these implementations are widely deployed 💀.

To encourage correct implementation of extension mechanisms, base protocol specifications should clearly articulate the expected behavior of extension mechanisms and should include examples of correct extension behavior 🫶.

3.6. Protocol Parameter Registration 📚

As noted in Section 3.2 of "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775] 🗂️:

An extension is often likely to make use of additional values added to an existing IANA registry.... It is essential that such new values are properly registered by the applicable procedures, including expert review where applicable.... Extensions may even need to create new IANA registries in some cases. Experience shows that the importance of this is often underestimated during extension design; designers sometimes assume that a new codepoint is theirs for the asking, or even simply for the taking.

Before creating a new protocol parameter registry, existing registries should be examined to see whether one of them can be used instead (see http://www.iana.org/protocols/) 🔍.

To avoid conflicting usage of the same registry value, and to prevent potential difficulties in figuring out and transferring parameter ownership, it is essential that all new values are registered 🙏. If this doesn't happen, there's nothing stopping two different extensions from picking the same value. When those two extensions "meet" each other on the Internet, failure is inevitable 💥.

A surprisingly common case of this is misappropriation of assigned Transmission Control Protocol (TCP) (or User Datagram Protocol (UDP)) registered port numbers 😬. This can lead to a client for one service trying to talk to a server for another service. Another common case is the use of unregistered URI schemes. Numerous cases could be cited, but not without embarrassing specific implementers 🙈. For general rules, see the IANA Considerations guidelines document [RFC5226], and for specific rules and registries, see the individual protocol specification RFCs and the IANA web site.

Now, a "Standards Track" or "IETF Consensus" parameter allocation policy may be set up to encourage protocol parameter registration or to improve interoperability 🌈. In practice, though, problems can come up if the procedures take so long that requesters give up and "self-allocate" by picking code points that are presumably unused 😩. Where self-allocation is common, the information in registries can become inaccurate, especially when third parties aren't allowed to update entries to improve accuracy. In these situations, it's important to think about whether registration processes need to change to support the role of a registry as "documentation of how the Internet is operating" 📖✨.

3.7. Extensions to Critical Protocols 🚨

Some protocols (such as the Domain Name System (DNS), the Border Gateway Protocol (BGP), and the Hypertext Transfer Protocol (HTTP)) or algorithms (such as congestion control) have become critical components of Internet infrastructure 🏗️. A critical component is one whose failure can lead to Internet-wide reliability and security issues or performance degradation. When these protocols or algorithms get extended, there's potential to negatively impact the reliability and security of the global Internet 😱.

So special care needs to be taken with these extensions 🧸, such as taking explicit steps to isolate existing uses from new ones. For example, this can be done by requiring the extension to use a different port or multicast address, or by implementing the extension within a separate process, without access to the data and control structures of the base protocol.

Experience has shown that even when a mechanism has proven benign in other uses, unforeseen issues may show up when it's added to a critical protocol 👻. For example, both IS-IS and OSPF support opaque Link State Advertisements (LSAs), which are propagated by intermediate nodes that don't understand the LSA. Within Interior Gateway Protocols (IGPs), support for opaque LSAs has proven useful without introducing instability 🙌.

BGP is a different story 💀. Within BGP, "attribute tunneling" has resulted in large-scale routing instabilities, since remote nodes may reset the LOCAL session if the tunneled attributes are malformed or aren't understood. This required modifying BGP error handling, as noted in "Revised Error Handling for BGP UPDATE Messages" [ERROR-HANDLING] 🛠️.

In general, when extending protocols with local failure conditions, tunneling attributes that may trigger failures in non-adjacent nodes should be avoided 🚫. This is especially risky when the originating node gets no indicators of remote failures it may have triggered 😵.

4. Considerations for the Base Protocol ✨

okay bestie, good extension design depends on a well-designed base protocol 💅 so to promote interoperability, designers should:

Ensure a well-written base protocol specification 📝. Does the base protocol specification make clear what an implementer needs to support, and does it define the impact that individual operations (e.g., a message sent to a peer) will have when invoked?
Design for backward compatibility 🫶. Does the base protocol specification describe how to determine the capabilities of a peer and negotiate the use of extensions? Does it indicate how implementations handle extensions that they do not understand? Is it possible for an extended implementation to negotiate with an unextended (or differently-extended) peer to find a common subset of useful functions?
Respect underlying architectural or security assumptions 🦋. Is there a document describing the underlying architectural assumptions, as well as considerations that have arisen in operational experience? Or are there undocumented considerations that have arisen as the result of operational experience, after the original protocol was published?

For example, will backward-compatibility issues arise if extensions reverse the flow of data, allow formerly static parameters to be changed on the fly, or change assumptions relating to the frequency of reads/writes?

Minimize impact on critical infrastructure 🌸. For a protocol that represents a critical element of Internet infrastructure, it is important to explain when it is appropriate to isolate new uses of the protocol from existing ones.

For example, is it explained when a proposed extension (or usage) has the potential for negatively impacting critical infrastructure to the point where explicit steps would be appropriate to isolate existing uses from new ones?

Provide guidance on data model extensions 🍓. Is there a document that explains when a protocol extension is routine and when it represents a major change?

For example, is it clear when a data model extension represents a major versus a routine change? Are there guidelines describing when an extension (such as a new data type) is likely to require a code change within existing implementations?

4.1. Version Numbers 🔢

Any mechanism for extension by versioning must include provisions to ensure interoperability, or at least clean failure modes. Imagine someone creating a protocol and using a "version" field and populating it with a value (1, let's say), but giving no information about what would happen when a new version number appears in it. This would be a bad protocol design and description 💀; it should be clear what the expectation is and how it can be tested. For example, stating that 1.X must be compatible with any version 1 code, but version 2 or greater is not expected to be compatible, has different implications than stating that version 1 must be a proper subset of version 2.

An example of an under-specified versioning mechanism is provided by the MIME-Version header, originally defined in "MIME (Multipurpose Internet Mail Extensions)" [RFC1341]. As noted in Section 1 of the MIME specification [RFC1341]:

A MIME-Version header field ... uses a version number to declare a message to be conformant with this specification and allows mail processing agents to distinguish between such messages and those generated by older or non-conformant software, which is presumed to lack such a field.

Beyond this, the 1992 MIME specification [RFC1341] provided little guidance on versioning behavior, or even the format of the MIME-Version header, which was specified to contain "text". The 1993 update [RFC1521] better defined the format of the version field but still did not clarify the versioning behavior:

Thus, future format specifiers, which might replace or extend "1.0", are constrained to be two integer fields, separated by a period. If a message is received with a MIME-version value other than "1.0", it cannot be assumed to conform with this specification.... It is not possible to fully specify how a mail reader that conforms with MIME as defined in this document should treat a message that might arrive in the future with some value of MIME-Version other than "1.0". However, conformant software is encouraged to check the version number and at least warn the user if an unrecognized MIME-version is encountered.

Thus, even though the 1993 update [RFC1521] defined a MIME-Version header with a syntax suggestive of a "Major/Minor" versioning scheme, in practice the MIME-Version header was little more than a decoration 🙈.

An example of a protocol with a better versioning scheme is ROHC (Robust Header Compression). ROHCv1 [RFC3095] supports a certain set of profiles for compression algorithms. But experience had shown that these profiles had limitations, so the ROHC WG developed ROHCv2 [RFC5225]. A ROHCv1 implementation does not contain code for the ROHCv2 profiles. As the ROHC WG charter said during the development of ROHCv2:

It should be noted that the v2 profiles will thus not be compatible with the original (ROHCv1) profiles, which means less complex ROHC implementations can be realized by not providing support for ROHCv1 (over links not yet supporting ROHC, or by shifting out support for ROHCv1 in the long run). Profile support is agreed through the ROHC channel negotiation, which is part of the ROHC framework and thus not changed by ROHCv2.

Thus, in this case, both backward-compatible and backward-incompatible deployments are possible. The important point is to have a clearly thought out approach to the question of operational compatibility 🌈.

In the past, protocols have utilized a variety of strategies for versioning, each with its own benefits and drawbacks in terms of capability and complexity of implementation:

No versioning support. This approach is exemplified by the Extensible Authentication Protocol (EAP) [RFC3748] as well as the Remote Authentication Dial In User Service (RADIUS) protocol [RFC2865], both of which provide no support for versioning. While lack of versioning support protects against the proliferation of incompatible dialects, the need for extensibility is likely to assert itself in other ways, so that ignoring versioning entirely may not be the most forward thinking approach.
Highest mutually supported version (HMSV). In this approach, implementations exchange the version numbers of the highest version each supports, with the negotiation agreeing on the highest mutually supported protocol version. This approach implicitly assumes that later versions provide improved functionality and that advertisement of a particular version number implies support for all lower version numbers. Where these assumptions are invalid, this approach breaks down, potentially resulting in interoperability problems. An example of this issue occurs in the Protected Extensible Authentication Protocol [PEAP] where implementations of higher versions may not necessarily provide support for lower versions.
Assumed backward compatibility. In this approach, implementations may send packets with higher version numbers to legacy implementations supporting lower versions, but with the assumption that the legacy implementations will interpret packets with higher version numbers using the semantics and syntax defined for lower versions. This is the approach taken by "Port-Based Network Access Control" [IEEE-802.1X]. For this approach to work, legacy implementations need to be able to accept packets of known types with higher protocol versions without discarding them; protocol enhancements need to permit silent discard of unsupported extensions; and implementations supporting higher versions need to refrain from mandating new features when encountering legacy implementations.
Major/minor versioning. In this approach, implementations with the same major version but a different minor version are assumed to be backward compatible, but implementations are required to negotiate a mutually supported major version number. This approach assumes that implementations with a lower minor version number but the same major version can safely ignore unsupported protocol messages.
Min/max versioning. This approach is similar to HMSV, but without the implied obligation for clients and servers to support all versions back to version 1, in perpetuity. It allows clients and servers to cleanly drop support for early versions when those versions become so old that they are no longer relevant and no longer required. In this approach, the client initiating the connection reports the highest and lowest protocol versions it understands. The server reports back the chosen protocol version:

a. If the server understands one or more versions in the client's range, it reports back the highest mutually understood version.

b. If there is no mutual version, then the server reports back some version that it does understand (selected as described below). The connection is then typically dropped by client or server, but reporting this version number first helps facilitate useful error messages at the client end:

If there is no mutual version, and the server speaks any version higher than client max, it reports the lowest version it speaks that is greater than the client max. The client can then report to the user, "You need to upgrade to at least version <xx>".
Else, the server reports the highest version it speaks. The client can then report to the user, "You need to request the server operator to upgrade to at least version <min>".

Protocols generally do not need any version-negotiation mechanism more complicated than the mechanisms described here. 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. 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 🧚.

4.2. Reserved Fields 🎀

okay so protocols literally always have these "reserved" fields 🦋 they're sitting there on purpose so future versions can use them. good practice is to say what the sender puts in there (typically zero) and what the receiver does when it sees some other value (typically no action). in packet format diagrams they're usually labeled "MBZ", which reads as "Must Be Zero on transmission, Must Be Ignored on reception" 💅

the classic newbie trap 🙈 is thinking MBZ means their software should check that the field is zero on reception and reject the packet if it isn't. nope bestie 💀 that code will fall apart when future versions give those fields new meanings. protocols should also spell out how receivers react to unknown extensions (headers, TLVs, etc.) so that failures only happen when that's actually the intended outcome ✨

4.3. Encoding Formats 🌸

using widely supported encoding formats = better interoperability and way easier to extend later 🫶

as "IAB Thoughts on Encodings for Internationalized Domain Names" [RFC6055] explains, the number of encodings should be minimized, and complex encodings are generally a bad idea 🙅‍♀️ the second you step outside the ASCII repertoire, things get messy fast with collation, valid code points, encoding, normalization, and comparison, and extensions have to handle all of that with care [ID-COMPARISON][PRECIS-STATEMENT][PRECIS-FRAMEWORK] 😭

the Simple Network Management Protocol (SNMP) Structure of Managed Information (SMI) is a good example of this energy 👑 there are guidelines for defining the Management Information Base (MIB) objects that SNMP carries [RFC4181]. there are also multiple textual conventions already published, so MIB designers don't have to "reinvent the wheel" when they need a commonly seen construct 🍓 for example, "Textual Conventions for Internet Network Addresses" [RFC4001] can be used by any MIB designer who needs objects containing IP addresses, which keeps things consistent as the pool of MIBs grows 🧚

4.4. Parameter Space Design 💜

in some protocols the parameter space either has no specified limit (e.g., Header field names) or is big enough that it's unlikely to ever run out ✨ in other protocols the space is limited and, sometimes, has turned out to be inadequate for demand 😬 common mistakes include:

a. a version field that's too small (e.g., two bits or less) 💀 when you design a version field, you have to account for existing as well as potential versions of a protocol. for example, if a protocol is being standardized and there are existing implementations with known interoperability issues, more than one version for "pre-standard" implementations may be needed. if two "pre-standard" versions are needed on top of a version for an IETF Standard, then a two-bit version field would only leave one extra code point for a future update, which could be insufficient. this problem came up during the development of the PEAPv2 protocol [PEAP] 🙈

b. a small parameter space (e.g., 8 bits or less) combined with a First Come, First Served (FCFS) allocation policy [RFC5226] 🚩 in general, FCFS is only appropriate when parameter exhaustion is highly unlikely. when substantial demand is expected within a parameter space, the space should either be designed to handle that demand, or vendor extensibility should be provided so vendors can self-allocate. the combo of a small space, FCFS, and no vendor extensibility is especially likely to be ill-advised 🥲 the original 8-bit EAP Type space [RFC2284] was an example of that combo.

once the potential for parameter exhaustion becomes apparent, it's important to address it as quickly as possible ⏰ protocol changes can take years to show up in implementations, and by then the exhaustion problem could be acute.

here are some options for dealing with a protocol parameter exhaustion problem:

Rethinking the allocation regime 🔄 Where it's clear that a parameter space is too small for demand, it may be necessary to rethink the allocation mechanism, to prevent or delay exhaustion. when revising allocation mechanisms, it's important to consider both supply and demand so you avoid unintended consequences like self-allocation or black markets for reselling protocol parameters 🕵️‍♀️

for example, a few years after PPP EAP [RFC2284] was published in 1998, it became clear that an FCFS allocation policy [RFC5226] together with a lack of vendor-extension support had created the potential for the EAP Method Type space to run out within a few years. to fix it, Section 6.2 of the 2004 update [RFC3748] changed the allocation policy for EAP Method Types from FCFS to Expert Review, with Specification Required. since that policy revision didn't change the demand for EAP Method Types, it would likely have led to self-allocation within the standards space if mechanisms to expand the Method Type space (including support for vendor-specific method types) hadn't been provided 🫠

Support for vendor-specific parameters 🏷️ if the demand that can't be accommodated is coming from vendors, just making allocation harder could make things worse, because it may push vendors to self-allocate and create interoperability problems 😩 in that case, support for vendor-specific parameters should be considered, letting each vendor self-allocate within its own vendor-specific space based on the vendor's Private Enterprise Code (PEC). for example, for the EAP Method Type space, Section 6.2 of the 2004 EAP specification [RFC3748] also provided an Expanded Type space for "functions specific only to one vendor's implementation" 💅

Extensions to the parameter space 📏 if the goal is to hold off exhaustion in the face of high demand, a larger parameter space may help 🌈 this may require a new version of the protocol (like what was needed for IPv6). where vendor-specific parameter support exists, this may be achieved by allocating a PEC for IETF use. otherwise, it may be necessary to try extending the size of the parameter fields, which could need a new protocol version or other substantial protocol changes 🙃

Parameter reclamation ♻️ to buy some time, it may be necessary to reclaim unused parameters. the tricky part is that it may not be easy to tell whether an allocated parameter is still in use, especially if the entity that got the allocation no longer exists or has been acquired (possibly more than once) 👀

Parameter transfer 🤝 when all the above mechanisms have proved infeasible and exhaustion is looming in the near future, enabling the transfer of ownership of protocol parameters can be considered as a way to improve allocation efficiency 💫 but it can be far from simple if the allocation process wasn't originally designed to allow title searches and ownership transfers 😵‍💫

a process designed to uniquely allocate code points is fundamentally different from one designed to enable title search and transfer 🧠 if the only goal is making sure a parameter isn't allocated more than once, the parameter registry only needs to record the initial allocation. but if the goal is to enable transfer of ownership, then it's important to record not only the initial allocation but also subsequent ownership changes, so it's possible to determine and transfer the title. because it's really hard to switch from a unique allocation regime to one that supports title search and ownership transfer, the desired capabilities should be carefully thought through when the registry is established 📝

4.5. Cryptographic Agility 🔐

extensibility when it comes to cryptographic algorithms is super desirable, because it gives you resilience if any particular algorithm gets compromised 🛡️ Section 3 of "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management" BCP 132 [RFC4962] gives some basic advice:

The ability to negotiate the use of a particular cryptographic algorithm provides resilience against compromise of a particular cryptographic algorithm.... This is usually accomplished by including an algorithm identifier and parameters in the protocol, and by specifying the algorithm requirements in the protocol specification. While highly desirable, the ability to negotiate key derivation functions (KDFs) is not required. For interoperability, at least one suite of mandatory-to-implement algorithms MUST be selected.... This requirement does not mean that a protocol must support both public-key and symmetric-key cryptographic algorithms. It means that the protocol needs to be structured in such a way that multiple public-key algorithms can be used whenever a public-key algorithm is employed. Likewise, it means that the protocol needs to be structured in such a way that multiple symmetric-key algorithms can be used whenever a symmetric-key algorithm is employed.

in practice, the hardest part of crypto agility is making a smooth transition when a mandatory-to-implement algorithm gets compromised 😤 since it can take a long time for a previously undeployed alternative to be widely implemented, it's often a good idea to recommend implementing alternative algorithms of distinct lineage in addition to the mandatory ones, so an alternative is ready to go 🏃‍♀️ if no such recommended alternative is in place, it would be wise to issue that recommendation as soon as signs of a potential weakness show up. this matters most for algorithms that authenticate and integrity-protect the cryptographic negotiation itself, like KDFs or message integrity checks (MICs) 🚨 without secure alternatives to a compromised KDF or MIC algorithm, it may not be possible to secure the negotiation while keeping backward compatibility 💔

4.6. Transport ✨

okay so bestie, IETF protocols have been run over multiple transports for ages 🦋 Usually the protocol starts out on one transport, then real deployment shows up its limits, so new transports get specified later 💅

a protocol that started on UDP often hit one or more of these issues and ended up needing an alternative transport:

a. Payload fragmentation (usually because of new extensions or extra usage scenarios) 💀
b. Problems with congestion control, transport reliability, or efficiency 😭
c. No deployment in multicast scenarios, which had been the whole reason to pick UDP in the first place 🙈

and then there are protocols that started on a reliable transport and later defined a UDP transport, for one or more of these reasons:

a. NAT traversal concerns that were easier to handle with UDP transport 🌈
b. Scalability problems that UDP transport could help with 🚀

okay here's the main tea 🍵 specifying a single transport gives the highest potential for interoperability, so protocol designers should carefully consider not only initial but also potential future requirements when picking a transport protocol 🎀 if UDP transport is picked, the guidance in "Unicast UDP Usage Guidelines for Application Designers" [RFC5405] should be taken into account ✨

once a protocol has a lot of deployment, there are few good options for fixing problems with the transport it was originally given 😩 you can specify more transport protocols, but yanking out a widely used transport is likely to cause interoperability problems, so it should be avoided 🫶

⚠️ Mandating the initially selected transport while labelling extra transports as optional can have limitations. Optional transports usually show up because they're amazing in certain scenarios, and in those situations, implementations that skip the optional transports may have degraded performance or may even fail 💔

and honestly, mandating multiple transports might look super attractive 👑 but designers need to realistically evaluate how likely implementers are to actually conform 🧐 for example, where resources are limited (like in embedded systems), implementers may choose to support only a subset of the mandated transport protocols, which results in non-interoperable protocol variants 🥺

4.7. Handling of Unknown Extensions

okay so IETF protocols have used a bunch of techniques for dealing with unknown extensions 🧚 one technique, which often shows up for vendor-specific extensions, is to say that unknown extensions be "silently discarded" 🤫

this approach can deliver a high level of interoperability 💖 but it's problematic in some situations. where security functionality is involved, "silent discard" may not be satisfactory, especially if the recipient doesn't give any feedback about whether it supports the extension 😬 that can lead to operational security issues that are super hard to detect and fix, as noted in Appendix A.2 and in Section 2.5 of "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] 💀

so to make sure a recipient actually supports an extension, a recipient that runs into an unknown extension may be required to explicitly reject it and return an error, instead of ignoring the extension and carrying on with the rest of the message 🛑 this can be done with a "Mandatory" bit in a TLV-based protocol like the Layer 2 Tunneling Protocol (L2TP) [RFC2661], or with a "Require" or "Proxy-Require" header in a text-based protocol like SIP [RFC3261] or HTTP [RFC2616] 🎀

💅 Since a mandatory extension can cause an interoperability failure when talking to a party that doesn't support it, this designation may not be permitted for vendor-specific extensions and may only be allowed for Standards Track extensions. And to allow fallback operation with degraded functionality, it is good practice for the recipient to indicate the reason for the failure, including a list of unsupported extensions. That way the initiator can retry without the offending extensions 🔁

typically only the recipient ends up in the position of rejecting a mandatory extension, since the initiator can explicitly say which extensions it supports, and the recipient picks from among those 🫶 this can be done with an exchange of TLVs, like in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5996] or Diameter [RFC3588], or with "Accept", "Accept-Encoding", "Accept-Language", "Allow", and "Supported" headers in a text-based protocol like SIP [RFC3261] or HTTP [RFC2616] ✨

5. Security Considerations 💀

okay this part is SO important, so pay attention bestie 🫵 an extension must not introduce new security risks without also providing adequate countermeasures. in particular, it must not accidentally defeat the security measures in the unextended protocol 🚨 so the security analysis for an extension needs to be just as thorough as the one for the original protocol. effectively, it needs to be a regression analysis that checks the extension doesn't accidentally invalidate the original security model 😱

this analysis might be simple (like, adding an extra opaque data element is unlikely to create a new risk) or it might be quite complex (like, adding a handshake to a previously stateless protocol may create a completely new opportunity for an attacker) 🕵️‍♀️

when the extensibility of a design includes letting new and presumably more powerful cryptographic algorithms be added, you need to take particular care to make sure the result is actually more secure 🔐 for example, from a security viewpoint it may be undesirable to allow negotiation down to an older, less secure algorithm. not it 🙅‍♀️

6. References 📚

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🌸
[RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten, "Procedures for Protocol Extensions and Variations", BCP 125, RFC 4775, December 2006. 🦋
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 💜

6.2. Informative References 📚

Okay bestie, these are the extra-credit reads that back up the whole doc 🤓 The [ERROR-HANDLING] entry is a Work in Progress by Scudder, Chen, Mohapatra, and Patel, "Revised Error Handling for BGP UPDATE Messages", June 2012. 🌸

[ERROR-HANDLING] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", Work in Progress, June 2012.
[ID-COMPARISON] Thaler, D., "Issues in Identifier Comparison for Security Purposes", Work in Progress, August 2012. 🦋
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, December 2004. 💜
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, May 2012. ✨
[PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004. 🎀
[PRECIS-FRAMEWORK] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols", Work in Progress, August 2012. 🧚
[PRECIS-STATEMENT] Blanchet, M. and A. Sullivan, "Stringprep Revision and PRECIS Problem Statement", Work in Progress, August 2012. 💅
[RFC822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, August 1982. 🍓
[RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, October 1991. 🙈
[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, June 1992. 🌈
[RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993. ⭐
[RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, January 1997. 🔥
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. 🌸
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 💖
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. 🦋
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. ✨
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 🫶
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. 🌈
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. 💜
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001. 🎀
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 🍓
[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended RADIUS Practices", RFC 2882, July 2000. 🧚
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. 👑
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 📞
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", RFC 3427, December 2002. 🌷
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003. 🎀
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 💅
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. 🙈
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. 🧪
[RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, March 2004. 🦋
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 🌈
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004. 🫶
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. ✨
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005. 💖
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. 🔥
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", RFC 4485, May 2006. 🌸
[RFC4521] Zeilenga, K., "Considerations for Lightweight Directory Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, June 2006. 🍓
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 🧚
[RFC4929] Andersson, L., Ed., and A. Farrel, Ed., "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007. 👑
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007. 💜
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007. 🎀
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. 🦋
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008. 🌈
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008. 🫶
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. ✨
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. 💅
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. 🙈
[RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5421, March 2009. 🍓
[RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5422, March 2009. 🧚
[RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated Protocol Development Considered Harmful", RFC 5704, November 2009. 👑
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010. 💜
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 🎀
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011. 🦋
[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011. 🌈
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012. 🫶

7. Acknowledgments 🫶

This document is heavily based on an earlier draft by Scott Bradner and Thomas Narten, other parts of which were eventually published as RFC 4775.

That draft stated: "The initial version of this document was put together by the IESG in 2002. Since then, it has been reworked in response to feedback from John Loughney, Henrik Levkowetz, Mark Townsley, Randy Bush and others."

Valuable comments and suggestions on the current form of the document were made by Loa Andersson, Ran Atkinson, Stewart Bryant, Leslie Daigle, Alan DeKok, Roy Fielding, Phillip Hallam-Baker, Ted Hardie, Alfred Hoenes, John Klensin, Barry Leiba, Eric Rescorla, Adam Roach, and Pekka Savola. The text on TLS experience was contributed by Yngve Pettersen. 💖

8. IAB Members at the Time of Approval 👑

These are the IAB members who were around when this got approved, bestie. Iconic lineup 😭

Bernard Aboba
Jari Arkko
Marc Blanchet
Ross Callon
Alissa Cooper
Spencer Dawkins
Joel Halpern
Russ Housley
David Kessens
Danny McPherson
Jon Peterson
Dave Thaler
Hannes Tschofenig

Appendix A. Examples 🌷

This section is giving case studies, and we're about to look at some specific examples 👀

A.1. Already-Documented Cases

There are certain documents that specify a change process or describe extension considerations for specific IETF protocols:

The SIP change process [RFC3427], [RFC4485], [RFC5727]
The (G)MPLS change process (mainly procedural) [RFC4929]
LDAP extensions [RFC4521]
EPP extensions [RFC3735]
DNS extensions [RFC2671][RFC3597]
SMTP extensions [RFC5321]

It is relatively common for MIBs, which are all in effect extensions of the SMI data model, to be defined or extended outside the IETF. BCP 111 [RFC4181] offers detailed guidance for authors and reviewers. 🧠✨

A.2. RADIUS Extensions 🦋

Okay so RADIUS [RFC2865] was designed to be extended by adding Attributes 💅 That extensibility model assumed Attributes would stick to a small set of data types, and that vendor extensions would only be used by vendors in situations where interoperability wasn't needed. Then things got wild and stretched those assumptions way past what anyone planned 😭

From the very beginning, people used RADIUS for stuff outside the original protocol definition, and outside the scope of the RADIUS Working Group charter too 🙈 On top of rampant self-allocation within the limited RADIUS standard attribute space, vendors made up their own RADIUS commands. That led to a fast spread of vendor-specific protocol variants. Even now, lots of common implementation practices haven't been documented. For example, authentication server implementations are often based on a Data Dictionary, which lets you add Attributes without changing any code 🤯 But the concept of a Data Dictionary isn't mentioned anywhere in the RADIUS specification [RFC2865]. Not me noticing that 💀

As noted in "Extended RADIUS Practices" [RFC2882], Section 1:

The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds for dial-in terminal servers. Unfortunately the real world of Network Access Servers (NASes) hasn't stayed that small and simple, and continues to evolve at an amazing rate. This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the protocol. These features use the RADIUS protocol structure and format, but employ operations and semantics well beyond the RFC documents.

The limited set of data types in the RADIUS specification [RFC2865] led later documents to define new data types 🎀 New data types are usually defined implicitly as part of defining a new attribute, and RADIUS client and server implementations differ in how much of these extra specs they support. So there's no definitive registry of RADIUS data types, and support for data types has been inconsistent. To catalog the data types people commonly implement, and to give guidance to implementers and attribute designers, Section 2.1 of "RADIUS Design Guidelines" [RFC6158] has advice on basic and complex data types ✨ Unfortunately, those guidelines [RFC6158] came out in 2011, which is 14 years after the RADIUS protocol was first documented [RFC2058] in 1997. Bestie, that's a long wait 😩

Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism for Vendor-Specific extensions (Attribute 26) and says that use of Vendor-Specific extensions:

should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful.

But in practice, the use of Vendor-Specific Attributes (VSAs) has been way broader than that 👀 Standards Development Organizations (SDOs) in particular have used VSAs to define their own extensions to the RADIUS protocol, and that's caused a bunch of problems 🫠

One issue is the data model for VSAs. Nobody expected multi-vendor VSA implementations to need to interoperate, so the RADIUS specification [RFC2865] doesn't define the data model for VSAs. It also allows multiple sub-attributes inside a single Attribute of type 26. That means VSAs can be defined that current implementations couldn't support if they were placed in the standard RADIUS attribute space, which has made it hard to standardize widely deployed VSAs. Section 2.4 of "RADIUS Design Guidelines" BCP 158 [RFC6158] talks about this:

RADIUS attributes can often be developed within the vendor space without loss (and possibly even with gain) in functionality. As a result, translation of RADIUS attributes developed within the vendor space into the standard space may provide only modest benefits, while accelerating the exhaustion of the standard space. We do not expect that all RADIUS attribute specifications requiring interoperability will be developed within the IETF, and allocated from the standard space. A more scalable approach is to recognize the flexibility of the vendor space, while working toward improvements in the quality and availability of RADIUS attribute specifications, regardless of where they are developed. It is therefore NOT RECOMMENDED that specifications intended solely for use by a vendor or SDO be translated into the standard space.

Another issue is how implementations should handle unknown VSAs 🤔 Section 5.26 of the RADIUS specification [RFC2865] says:

Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.

Here's the tricky part: VSAs don't have a "mandatory" bit, so RADIUS clients and servers may not know whether it's safe to ignore unknown VSAs 😬 If VSAs are about security (like Filters, for example), ignoring them might not be safe at all. Because of that, Section 2.5 of "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] includes this caution:

To avoid misinterpretation of service requests encoded within VSAs, RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS clients that are not known to understand them. For example, a RADIUS server should not send a VSA encoding a filter without knowledge that the RADIUS client supports the VSA.

On top of extending RADIUS with VSAs, SDOs have also defined new values of the Service-Type attribute to create new RADIUS commands 💖 The RADIUS specification [RFC2865] allocated Service-Type values on a First Come, First Served (FCFS) basis [RFC5226]. So new RADIUS commands could be allocated without any IETF review. That oversight has since been fixed in "IANA Considerations for RADIUS" [RFC3575] 🎉 Main character energy for the fix, honestly 👑

A.3. TLS Extensions 🔐

Okay so, the Secure Sockets Layer (SSL) Version 2 Protocol was made by Netscape to lock down online transactions on the Internet 💳. It got replaced by SSLv3, which was also Netscape's, and then the IETF took SSLv3 and developed it further into Transport Layer Security (TLS) 1.0 [RFC2246] 🎀.

Here's the tea 🫖: SSLv3 was never explicitly specified to be extended, and even TLS 1.0 didn't define an extension mechanism explicitly. There were extension "loopholes" though 🙈. Extension mechanisms were finally defined in "Transport Layer Security (TLS) Extensions" [RFC4366] ✨:

New versions
New cipher suites
Compression
Expanded handshake messages
New record types
New handshake messages

The protocol also defines how implementations should handle unknown extensions 🧚.

Of the above extension methods, new versions and expanded handshake messages have caused the most interoperability problems 💀. Implementations are supposed to ignore unknown record types, but they're supposed to reject unknown handshake messages. Sis, the drama 😭.

Now the new version support in SSL/TLS can define new versions of the protocol while still letting newer implementations talk to older ones 🦋. As part of that, some Key Exchange methods have functionality to prevent version rollback attacks 🔒.

The experience with this upgrade functionality in SSL and TLS is decidedly mixed 🙃:

SSLv2 and SSLv3/TLS are not compatible. You can use SSLv2 protocol messages to start an SSLv3/TLS connection, but you can't talk to an SSLv2 implementation with SSLv3/TLS protocol messages 💔.
Some implementations refuse to accept handshakes using newer versions of the protocol than they support 🙅‍♀️.
Other implementations accept newer versions but handle the version rollback protection clumsily 🤦‍♀️.

The SSLv2 problem forced SSLv3 and TLS clients to keep using SSLv2 Client Hellos for their initial handshake with almost all servers until 2006 🕰️. That was way longer than anyone wanted, all so they could interoperate with old servers 😩.

The problem with handling newer versions incorrectly also forced many clients to actually disable the newer protocol versions 🙈. They did this either by default or by automatically turning the functionality off, just so they could connect to those servers. Basically, the version rollback protection in SSL and TLS is non-existent when you're talking to a fatally compromised older version 💀🌈.

SSLv3 and TLS also permitted extension of the Client Hello and Server Hello handshake messages ✨. That got fully defined with TLS extensions, which make it possible to add new functionality to the handshake 🧁. Think the name of the server the client is connecting to, requesting certificate status information, and indicating Certificate Authority support, maximum record length, etc. 🍓 Several of these extensions also introduce new handshake messages 💅.

Here's where it gets messy 😬. Many SSLv3 and TLS implementations that don't support TLS extensions did not ignore the unknown extensions, even though the protocol specifications require them to. Instead they just failed to establish connections 🚫. Several of the implementations behaving this way are used by high-profile Internet sites, like online banking sites 🏦. That caused a significant delay in deploying clients that support TLS extensions, and several clients that did enable support use heuristics that let them disable the functionality when they detect a problem 🫠.

Looking ahead ⏭️, the protocol version problem in particular can cause future security problems for TLS 🚨. The strength of the digest algorithms (MD5 and SHA-1) used by SSL and TLS is weakening. If MD5 and SHA-1 weaken to the point where it's feasible to mount successful attacks against older SSL and TLS versions, the current error recovery used by clients would become a security vulnerability (among many other serious problems for the Internet) 😱.

To address this, TLS 1.2 [RFC5246] uses a newer cryptographic hash algorithm (SHA-256) during the TLS handshake by default 👑. Legacy ciphersuites can still protect application data, but new ciphersuites are specified for data protection as well as for authentication within the TLS handshake 🎀. The hashing method can also be negotiated via a Hello extension 🌸. Implementations are encouraged to implement new ciphersuites and to let policy govern which ciphersuite gets used during a TLS session, so everyone can move away from weakened ciphersuites faster 🏃‍♀️💨.

The lesson here is that it isn't enough to design extensibility carefully. It also has to be implemented carefully by every implementer, without exception 🫶. Test suites and certification programs can help give implementers the incentive to pay attention to implementing extensibility mechanisms correctly 🏆.

A.4. L2TP Extensions 🦋

The Layer Two Tunneling Protocol (L2TP) [RFC2661] carries Attribute-Value Pairs (AVPs), and most AVPs have no semantics to the L2TP protocol itself 🌷. However, L2TP message types are identified by a Message Type AVP (Attribute Type 0) with specific AVP values that indicate the actual message type 🔍. So extensions relating to Message Type AVPs would likely be considered major extensions 👀.

L2TP also provides for vendor-specific AVPs 🎁. Because everything in L2TP is encoded using AVPs, it would be easy to define vendor-specific AVPs that would be considered major extensions 😅.

L2TP also provides a "mandatory" bit in AVPs 🚩. Recipients of L2TP messages containing AVPs they don't understand, but that have the mandatory bit set, are expected to reject the message and terminate the tunnel or session the message refers to 🙅‍♀️. This leads to interesting interoperability issues, because a sender can include a vendor-specific AVP with the M-bit set, which then stops the recipient from interoperating with the sender 🥲. This sort of behavior goes against IETF ideals 🇺🇳, since implementations of the IETF standard should interoperate successfully with other implementations and shouldn't require implementing non-IETF extensions just to talk to each other 💜. Section 4.2 of the L2TP specification [RFC2661] includes specific wording on this point, though there was significant debate at the time about whether that language was enough by itself 🗣️.

Fortunately, the potential problems described above haven't yet become a problem in practice 🥳. At the time of this writing, the authors aren't aware of any vendor-specific AVPs that also set the M-bit ✨🌈.

Authors' Addresses 💌

Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand

EMail: brian.e.carpenter@gmail.com


Bernard Aboba (editor)
PMB 606
15600 NE 8th Street, Suite B1
Bellevue, WA 98008
USA

EMail: bernard_aboba@hotmail.com


Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA

EMail: cheshire@apple.com

📦 where this page comes from

ietf: rfc6709 2012-09
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms