]> Cloudflare

lucas@lucaspardue.com

Apple

tpauly@apple.com

Armidale Consulting

dave.thaler.ietf@gmail.com

next generation unicorn sparkling distributed ledger Active use and maintenance of network protocols is an important way to ensure that protocols remain interoperable and extensible over time. Techniques such as intentionally exercising extension points with non-meaningful values (referred to as "grease") or adding variability to how protocol elements are used help generate this active use. Grease and variability are used across various protocols developed by the IETF. This document discusses considerations when designing and deploying grease and variability mechanisms, and provides advice for making them as effective as possible. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction discusses "active use" as a category of techniques that protocol designers and implementers employ to ensure that protocol extension mechanisms are exercised and can be used in the future. This ability to change (to handle protocol updates and extensions) is an important factor in the success of protocol deployment, as discussed in . Active use of protocol features and extensions often requires intentional efforts beyond what would organically occur in deployments. Some extension points rarely see new values being used, but it is important that they remain usable in the future. Some patterns of protocol usage might be relatively static without specific efforts to ensure that they can change in the future. One key technique for intentional use is "grease" (an acronym for Generate Random Extensions And Sustain Extensibility), or "greasing". Greasing was initially designed for TLS and was later adopted by other protocols such as QUIC . In these protocols, some extension codepoints are reserved for greasing, and receivers must ignore them. Greasing is suitable for many protocols but not all; discusses the applicability and limitations of greasing. While it is becoming more common, designing and applying grease is not necessarily trivial. There are best practices, and some common pitfalls to avoid, that have been developed by the protocols using grease thus far. takes these learnings and provides considerations for new protocol design and deployment. Separate from greasing using reserved values, protocol deployments can intentionally add variability to ensure that network endpoints and middleboxes do not end up ossifying certain patterns. If expectations have been formed around historical patterns of use, changing application or transport protocol feature use could alter the network traffic profile and invalidate such expectations, possibly leading to deployment problems. For example, an HTTP deployment that had previously focused on downloads could add a new upload workload that changes the characteristics of packet flows. presents considerations about how intentionally increasing the variability of protocols can mitigate some ossification concerns. Protocol extensions can provide longevity in the face of changing needs or environment. However, a replacement protocol might be preferred when extensions are not adequate or feasible. A protocol replacement could aggregate common extensions and possibly make them mandatory, effectively defining a new baseline that can simplify deployment and interoperability. A replacement protocol version may or may not be compatible with other versions. A protocol may or may not have a mechanism for version selection or agility. presents considerations about designing for and/or implementing version negotiation and migration.

Considerations for Greasing Protocols Greasing can take many forms, depending on the protocol and the nature of its extension points. The common pattern across forms of greasing is that values are generated that have no useful meaning to the protocol and are meant to be ignored upon receipt. Such values used for the purpose of greasing are referred to as "grease values" within this document. More background to this approach is given in . This section provides some practical considerations for how to define and use greasing, and avoid possible pitfalls.

Define and Register Grease Value Ranges Many protocols that use greasing have a limited set of possible values or codepoints that can be used in a particular extension point. A common approach is to reserve a subset of the registrable space for greasing. The following are some examples of protocols that have reserved codepoints for grease values:

• TLS ()
• QUIC ()
• HTTP/3 ()
• Privacy Pass ()

The specifics of how to reserve values depends on the nature of the available space. For protocols with large possible spaces, it is useful to have a large set of grease values to increase the chance that receiver greasing requirements are exercised. The specific size and distribution of the grease range needs to accommodate the protocol constraints. For instance, protocols that use 8-bit fields may find it too costly to dedicate many grease values, 16-bit fields can usually afford a small set (TLS reserves 16 values in each of its 16-bit registries ), and 32-bit or 64-bit fields are likely to have no such limitations. Reserving grease values has a lasting cost. Grease values cannot be used or registered for any other purpose (see ), so each reserved value is permanently removed from the space available to future extensions. Designers need to be aware that reserving too many values for greasing can leave few values for defining new extensions. Separately from greasing, reserved space can also be hard to reclaim. For example, the IPv4 address block 240.0.0.0/4 was reserved for future use in 1989 , and is still listed as reserved . It is recommended to use an algorithm to reserve large sets of values. For example, uses an algorithm of 31 * N + 27 to allocate grease values for transport parameters. These values span all four sizes of QUIC's variable-length integer encoding (1, 2, 4, and 8 bytes; ), so grease exercises each size. One possible problem with some algorithms is that they will spread out values over the space, and impact the ability to use or reserve contiguous blocks of non-grease values. It is common for protocol extension designers to want to reserve contiguous blocks of codepoints in order to aid iteration and experimentation. Reserved grease values can end up being in spaces that would otherwise be used for such contiguous blocks. Codepoints being used for new reservations, or experimentation, need to be careful to not unintentionally use grease values. Doing so could lead to interoperability failures.

Recommendations for IANA Considerations IANA registries that contain reserved grease values need to indicate that the values are reserved in order to prevent them from being allocated for other uses. The specifics of how to represent the reservations is up to the documents that define the registries. Some registries list out the reserved grease values individually, marked as "Reserved". For example, the TLS registry uses this approach (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml). If an algorithm or pattern is used to define grease values, it is recommended when possible to instead only define a single entry for the entire grease value set. This entry should include the pattern or algorithm. This approach is used by the QUIC registry (https://www.iana.org/assignments/quic/quic.xhtml) and the HTTP/3 registry (https://www.iana.org/assignments/http3-parameters/http3-parameters.xhtml#http3-parameters-frame-types). Grease values must not be used or registered for any other purpose. This is in contrast to other potentially "reserved" values that might be reused or claimed for a new purpose in the future. To avoid confusion, it is recommended to label the reservation with a clear identifier, such as "reserved for greasing".

Use Unpredictable Grease Values In order to gain the benefits of active use and avoid ossification, grease values used in actual packets need to be sent in ways that won't become a predictable pattern that receiver and middlebox implementations and deployments ossify around. Implementations that generate grease values should pick unpredictable entries from the set of reserved grease values. It is most important that values be unpredictable across the set of all protocol participants for particular deployments. This can be achieved in multiple ways: for example, an individual sender might pick random values from the grease value space on each interaction; alternatively, a single sender could pick a specific grease value to use, while other senders pick other values. In order to support picking unpredictable values, the set of reserved values should be large, when possible. See for a discussion of how to allocate grease values.

Use Grease Values Unpredictably In addition to selecting unpredictable values, the inclusion of grease itself can be made unpredictable. Implementations can vary their behavior by including no grease values, one grease value, or multiple grease values for a given protocol extension point. How consistently and frequently to use grease values is a choice that implementations and deployments need to consider and weigh against several factors. Deployments of greasing should consider how they expect errors exposed by using grease values to be noticed and measured (). Counting failures separately for interactions with and without grease helps attribute them, and detailed logs help diagnose them. Logs can reveal more than the wire image, so sharing them needs care. In order to correctly report the effects of greasing, logging systems and formats should record unknown values, including grease values. If these values are discarded and not logged, failures exposed by greasing can be hidden or misattributed. One example of a logging format that includes greasing values is qlog, a structured logging format for QUIC and HTTP/3 . If grease values are sent too infrequently, so that errors due to sending grease values blend in with the noise of other errors, it is likely that no one will notice failures, thus defeating the purpose of greasing. When grease values are sent more frequently, they will be noticed more. However, if grease values are sent too consistently, receiver implementations might end up special-casing grease values. The patterns for sending grease values can be made more effective by coordinating between devices sending the values. One example of coordination is having a "flag day" where implementations start sending grease values broadly, and measure to see where errors occur. See for more considerations concerning the use of a flag day.

Don't Handle Grease Values as a Special Case Implementations that read and process grease values must ignore the values. "Ignoring" a value upon receipt can have multiple dimensions, however. Simply not performing any protocol action based on the grease value isn't enough to ensure that the protocol will remain extensible. The ignoring must be handled as a general case of "unknown" or "unhandled" values, not as a special case for ignored grease values. This means that grease values can only meaningfully be used for protocol elements where all unknown values are ignored by default. (Protocols may have ways to indicate that some specific values are "mandatory" or "critical" in order to have the protocol interaction succeed, but these must not be marked for any grease values.) One pitfall that implementations may encounter when building logic to handle the receipt of grease values is related to cases where some recognized non-grease values need to be handled as errors. Consider the following abstract example:

1. A protocol element has values 1, 2, 3, and 4 defined and registered for use. The values 13 and 42 are reserved as grease values.
2. In a specific scenario, only the known values 1 and 2 are valid; 3 and 4 are considered errors.
3. An implementation might naively choose to check for the value being 1 or 2, handle those cases, and send an error otherwise.
4. When grease values are used, the previous logic will flag an error for the grease value. If this is detected, implementations might choose to work around this by updating the logic to check for the value being 1 or 2, then check for grease values to ignore, and then send an error otherwise. This logic is also incorrect since it doesn't allow for new extensibility.

The correct logic for the above scenario would be to check for the value being 1 or 2, then explicitly check for the value being 3 or 4 (to handle the error), with a catch-all for ignored values. In pseudo-code, the correct logic would work like this, where the grease values would fall into the final else case as ignored values. Implementations need to take care when implementing such logic. Protocol specification designers should emphasize that grease values must not be special-cased. It is also recommended to provide example logic or pseudocode in specifications, similar to the example above, as guidance to implementers on how to correctly process protocol elements like these. Documents can also provide test vectors, when applicable, that include grease values to ensure they are processed correctly. One limitation of greasing is that it only exercises grease values. It does not check whether other values that are reserved for future use are correctly treated as ignored or errors. As such, ossification remains a possibility for non-grease values. The goal of greasing is to increase the chances of correct implementation, and thereby reduce (but not eliminate) the possibility of ossification. Reserved fields, which senders set to a fixed value (typically zero), are a related case. A later specification can give such a field meaning, so receivers need to ignore its value rather than reject messages where it is non-zero; calls that rejection a common mistake. Because senders always send the same value, these fields are prone to ossification (). They are often only a few bits long, leaving no room to reserve grease values. Negotiated greasing, as does for QUIC's fixed bit, can exercise such a field without consuming any of its values.

Greasing Protocol Versions discusses considerations around planning for transitioning from an existing protocol, or protocol version, to a new one. There are also intrinsic and well-documented issues related to testing version negotiation of protocols; see and Sections and of . One way to grease protocol versions is to have a protocol pass a list of supported versions or features (e.g., cipher suites), along with a grease value, such that the grease value will not impact the actual version or features chosen, since it will not be selected by the receiving entity. Another method is to have a protocol include a recovery mechanism (e.g., an extra round trip to try with another option) for cases when an unsupported version or feature is attempted. In this case, a grease value might be attempted at some frequency or opportunity that would not adversely affect performance.

Deployment Considerations and Incentives for Greasing Greasing can be used as a tool to improve the active use of existing protocol elements (which weren't necessarily designed with greasing to begin with, or weren't deployed with greasing); or as part of new protocol design and deployments. When greasing isn't used from the beginning of protocol deployment, starting to use greasing comes with the risk of triggering failures or anomalies. These failures might be innocuous, but they also might be very impactful and visible to users. This risk creates a disincentive to deploy greasing in existing systems, since the change that triggers failures is often blamed for the failure. The risk is highest when adding greasing to a particular protocol flow that doesn't require any change of behavior or adoption to hit the greasing behavior. For example, if a service migrates to use a new web server implementation that enables greasing, while the previous server didn't, some new failures may be hit if clients react poorly to greasing. Some approaches to avoid failures due to greasing include:

• Designing, implementing, and using greasing very early on in protocol development and deployment. This avoids the aforementioned risk of adding greasing late in a deployment.
• Enabling greasing along with other major protocol feature changes or deployment changes. For example, when upgrading to a new protocol version that requires implementation updates on multiple systems, greasing can be added for the new version specifically. This approach works well for situations where the protocol participants are known and already need to cooperate (such as within an encrypted protocol between two endpoints). This approach applies less well for situations where non-cooperating entities (such as middleboxes) are the source of ossification.
• Using heuristics to disable greasing when errors are encountered. For example, if a client-initiated protocol operation fails multiple times when grease values are used, it can be retried without any grease values. Alternatively, if a server recognizes a property of a client that always fails when greasing is used, it could choose to disable greasing when that client is detected. This reduces the effectiveness of grease values in removing existing ossification, but can still have benefits for flagging issues in new implementations when they receive grease values.

Ossification of DNS implementations presents an illustrative challenge for greasing. Non-encrypted DNS involves many network observers and participants, and the protocol has numerous fields that have been defined and deployed for many years. discusses approaches that can be used to grease DNS, including being able to more easily tie greasing to using encrypted DNS (thus enabling grease along with another major feature change). It also describes how the common approach in DNS to deal with failures, by retrying without options, interacts with grease.

Negotiating Greasing: Greasing the Wire Image Greasing is always intended to prevent ossification, but the protocol participants targeted by greasing can vary. Typically, greasing fields that are part of an end-to-end encrypted protocol allows a sender to target greasing at a known peer. In this case, the sender chooses to send grease without any explicit negotiation with the peer, since the point is to ensure that the peer will tolerate receiving grease. Other kinds of greasing apply to protocol fields that are visible in the wire image of a protocol , generally unencrypted fields in a protocol. These cases target greasing at all parties that can observe the wire image, including any middleboxes. In these cases, the two endpoints of a protocol might explicitly negotiate the use of greasing. This doesn't prevent the endpoints themselves ossifying (since they might choose to not negotiate), but it can still be effective for preventing ossification of middleboxes. For example, the "QUIC bit" is an unencrypted bit visible in QUIC's wire image that is used to differentiate it from other UDP traffic, and is set to a value of 1 in version 1 of QUIC. Being able to set the bit to 0 requires negotiation between clients and servers to ensure that the QUIC traffic won't conflict with other traffic (). The purpose of this mechanism is to grease the wire image by ensuring middleboxes can tolerate the bit being set to 0, but it cannot be used to grease the peer since it requires negotiation. Greasing the wire image inherently involves more parties than other kinds of greasing, and it is more difficult for implementations to anticipate all possible incompatibilities, so it is more likely to encounter deployment challenges.

Discouraging Ossification Greasing alone can help ensure that middleboxes tolerate unrecognized extensions rather than crashing, but one common middlebox behavior is to simply drop all unrecognized extensions. Techniques such as disabling greasing when errors are encountered can enable communication but may not provide enough incentive to discourage ossification. One approach to preserving the incentive to grease without being blamed for doing so, while still potentially discouraging ossification, is to make any such ossification visible. For example, a sender can log and report ossification issues on a given path when falling back to non-grease values. Similarly, a receiver can log and report communication that does not include grease values. Such reports might be used in social feedback (e.g., public product or service reviews), or in contractual business relationship (e.g., SLA) discussion, in order to provide an incentive to implementers or deployers of ossified implementations. Similar techniques can be used to encourage greasing and variability by others, to provide further discouragements against ossification in the future. Having a receiver log and report communication that does not include grease values, as noted above, can also be used to report on senders that do not support greasing. It is useful, however, to be able to distinguish between the sender not supporting greasing, versus the sender supporting greasing but only non-greased messages arriving at the receiver. Protocols defining greasing mechanisms should consider whether receivers can distinguish between these two cases. It is not generally recommended to use more drastic incentives to require greasing such as degrading performance or reliability for senders that don't support greasing. While this is possible, the benefits of greasing are longer term, rather than immediate, and the incentives are often not aligned. explains that success most easily comes when those who are required to make a change are the ones who gain the most benefit, and the benefit is noticeable. If the sending implementation does not plan to use new extensions in the future, it would not see any benefit from being pushed to add greasing.

Considerations for Increasing Protocol Variability Greasing can maintain protocol extensibility by falsifying active use of its extension points (see ). However, greasing alone does not ensure positive use of extension mechanisms. A protocol may define a wide-ranging extension capability that remains unused in the absence of real use cases. This can lead to ossification that does not expect extensions, leading to interoperability problems later on. Long-term maintenance and interoperability can be ensured by exercising extension points positively. To some extent this can be thought of as protocol fuzzing. This might be difficult to exercise because varying the protocol elements might change the outcome of interactions, leading to real errors. However, some protocols allow elements to be safely changed, as shown in the following examples. The principles in these examples are not limited to the protocols mentioned, but also arise in many other protocols (e.g., the Session Initiation Protocol (SIP) ).

Example: QUIC frames QUIC packets contain frames. Receivers might build expectations on the longitudinal aspects of packets or frames - size, ordering, frequency, etc. A sender can quite often manipulate these parameters and stay compliant to the requirements of the QUIC protocol. A QUIC stream is an ordered reliable byte stream that is serialized as a sequence of STREAM frames with a length and offset. Receivers are expected to reassemble frames, which could arrive in any order, into an ordered reliable byte stream that is readable by applications. A form of positive testing is for a sender to unpredictably order the STREAM frames that it transmits. For example, the sender can vary the sequence order of offset values. This allows exercising the QUIC reassembly features of the receiver with the expectation that no failure would occur. However, doing this may introduce delay or stream head-of-line blocking that affects the performance aspects of a transmission, which may not be acceptable for a given use case. As such, positive testing might be most appropriate to use in a subset of connections, or phases within a connection.

Example: Post-quantum key exchange in TLS Post-quantum key exchange in TLS (such as defined in ) expands the key sizes sent in Client Hello messages in TLS 1.3 . Before using these algorithms, Client Hello messages would generally fit within a single packet (either in TCP or QUIC). However, with these larger keys, Client Hello messages need to be split across two (or more) separate packets. Initial deployments of these keys uncovered many buggy server and middlebox implementations that did not correctly handle Client Hello messages being split across multiple packets. This is a case in which adding variability to how TLS Client Hello messages were sent could have helped avoid ossification and buggy implementations. Variations could include intentionally splitting the messages across packets without increasing message size, and also adding other values to messages to force them to exceed the length that can fit within a single packet.

Example: IPv6 The IPv6 protocol defines the ability to use extension headers, and further defines the ability to include options in two of those headers. It also defines a recommended (but not required) order of such headers. If the same headers tend to appear in the same order, and with the same size and offset most of the time, middleboxes can begin to incorrectly rely on assumptions that those will always be the case, and lead to ossification and inability to use new headers or options or differing orders in the future. IPv6 did not define grease values, but a sender may vary some aspects of the protocol, such as varying the order of options within an extension header, or even including a Destination Options Header with only Pad1 or PadN options between other headers. While doing such variations can discourage ossification, they might also have a negative performance impact if done indiscriminately. For example, making packets larger as a result might result in fragmentation. Finally, there may be security or gateway middleboxes already deployed that incorrectly rely on assumptions about header order, size, or location in a packet. Introducing variability might then cause operational problems in such networks and result in a disincentive to use the protocol or device or application using it. In practice, adding a padding-only Destination Options header already causes loss: about 11% to 21% of packets with an 8-byte Destination Options header of PadN options sent to public servers were dropped in measurements from 2014 and 2015 . Guidance for transit routers has since recommended permitting such packets , but senders cannot assume that every path follows that guidance.

Wire Image Variation The examples of variation above highlight ways in which specific protocol fields are sent. Variation can also apply to more generic aspects of a flow's wire image . Even when fields are encrypted, there are aspects of a protocol's wire image that middleboxes observe and can ossify around. Aspects of the wire image include packet sizes (and patterns in packet sizes), number of packets in a flow, directionality of flows (how many packets are sent in one direction or another), and relative timing of packet transmissions. Senders can induce intentional wire image variations in many ways, including: adding padding to extend packet sizes, breaking up data across multiple packets to reduce packet sizes, pacing or bursting packets to change the frequency of packet sends, and adding packets that are purely padding or random data (often referred to as "chaff").

Variability in Protocol Choice Variation can occur when an endpoint chooses to use one protocol over another, given the option to use either. For example, a client connecting to an HTTP server when connected to a dual-stack network might have several such choices:

• Perform DNS resolution using unencrypted DNS, or DNS over TLS , or DNS over HTTPS
• Connect to the server's IPv6 or IPv4 address, or both
• Connect to the server using HTTP/3 (over QUIC) or HTTP/2 (over TCP)

Endpoints often will have a preferred set of protocols to use, and will use the less preferred protocols as options they fall back to (as described in "Happy Eyeballs", ). However, for the sake of variation and preventing ossification, endpoints can intentionally choose to alter their preferences some percentage of the time. Variation can also be created when an endpoint chooses to not use a protocol feature, as an intentional way to ensure the network path or peer still tolerates its absence. For example, recommends that, in some situations, clients randomly act as if they don't support sending privacy pass tokens, to ensure that receivers cannot ossify around them being available. Note that sometimes, it is desirable to reduce the appearance of variation instead of increasing it, particularly when trying to increase an anonymity set by making connections look more similar to network observers. For example, a TLS client that supports Encrypted Client Hello (ECH), but is not aware of an ECH configuration for a server it is contacting, will send a fake ECH extension made to look like a real one (). When many clients do this, real ECH is harder to tell apart from fake, which discourages networks from treating it differently ().

Cost of Variability Adding variability to implementations and deployments can come with costs for complexity and performance, and needs to be weighed against the benefits of reducing or preventing ossification.

• Implementation complexity: Correctly implemented receivers need to be able to handle all valid inputs, but sender-side logic is often made more complex by adding support for variation. The kinds of protocol variability described in this document can require sender logic to not only support less straightforward ways of constructing packets, but also support randomly deciding when to induce variability.
• Processing overhead: For both senders and receivers, protocol variability can lead to processing overhead, and potentially higher memory usage. For example, intentionally breaking up and reordering data frames is less efficient than processing a complete data chunk.
• Network efficiency: Variability that changes the wire image of a protocol () might be achieved by spreading data out across more packets, sending smaller packets, adding chaff packets, or adding delay. All of these, if used in excess, could degrade the overall performance of a flow on a network, such as to reduce goodput, increase latency, etc.

Security Considerations The considerations in , , , and all apply to the topics discussed in this document. Security devices that inspect traffic, such as firewalls and intrusion detection systems, also process grease. Grease is normal protocol behavior, so if these systems categorize it as an attack, greasing fails and senders may stop greasing. Recognizing grease values specifically does not help: a device that permits grease but blocks other unknown values still blocks real extensions. To mitigate this, protocol specifications can define how intermediaries handle unknown values, as TLS does (), and as operational guidance does for QUIC () and DNS (). These security devices typically also fingerprint traffic (), which grease can disrupt. The use of protocol features, extensions, and versions can already allow fingerprinting . Any techniques that change parameters in any way, including but not limited to those discussed in this document, can affect fingerprinting. A deeper analysis of this topic has been deemed out of scope.

IANA Considerations This document has no IANA actions itself. Guidance on how other documents can effectively instruct IANA about protocol greasing is provided in .

Informative References The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly. The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. This memo provides information for the Internet community. This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme specified in this document can be used by Clients to redeem Privacy Pass tokens with an Origin. It can also be used by Origins to challenge Clients to present Privacy Pass tokens. This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK] This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. Akamai Meta Apple This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Akamai Meta Apple This document defines qlog event schemas containing concrete events for the core HTTP/3 protocol and selected extensions. It also defines an http namespace for the Capsule Protocol. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan. This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes. Salesforce Internet Systems Consortium Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-grease. This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image. This document describes a method for negotiating the ability to send an arbitrary value for the second-most significant bit in QUIC packets. This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This document defines three hybrid key agreement mechanisms for TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Ephemeral Elliptic Curve Diffie-Hellman) exchange. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. Apple Inc Google LLC Google LLC Google LLC Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document defines the algorithm for "Happy Eyeballs", a technique for reducing user-visible delays on dual-stack hosts. This document updates the algorithm in RFC 8305. This document describes a mechanism in Transport Layer Security (TLS) for encrypting a message under a server public key. The main goal of the networking standards process is to enable the long-term interoperability of protocols. This document describes active protocol maintenance, a means to accomplish that goal. By evolving specifications and implementations, it is possible to reduce ambiguity over time and create a healthy ecosystem. The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. However, it has been interpreted in a variety of ways. While some interpretations help ensure the health of the Internet, others can negatively affect interoperability over time. When a protocol is actively maintained, protocol designers and implementers can avoid these pitfalls. This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this. This document discusses manageability of the QUIC transport protocol and focuses on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It is intended as a "user's manual" for the wire image to provide guidance for network operators and equipment vendors who rely on the use of transport-aware network functions. The DNS is a query/response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long-term problems with protocol development. This document identifies a number of common kinds of queries to which some servers either fail to respond or respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem. The document does not look at the DNS data itself, just the structure of the responses. To protect user data and privacy, Internet transport protocols have supported payload encryption and authentication for some time. Such encryption and authentication are now also starting to be applied to the transport protocol headers. This helps avoid transport protocol ossification by middleboxes, mitigate attacks against the transport protocol, and protect metadata about the communication. Current operational practice in some networks inspect transport header information within the network, but this is no longer possible when those transport headers are encrypted. This document discusses the possible impact when network traffic uses a protocol with an encrypted transport header. It suggests issues to consider when designing new transport protocols or features. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.

Acknowledgments This work is a summary of the topics discussed during EDM meetings. The contributors at those meetings are thanked.