]> independent

minami.hiroy@gmail.com

protocol ossification middlebox protocol evolution This document catalogues cases of protocol ossification. Protocol ossification is a phenomenon in which a new protocol, version, or extension cannot traverse an existing Internet path; such problems have been discovered and reported during protocol standardization and deployment. This document summarizes the reported observations and sources for those cases, together with case-specific responses. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction Protocol specifications can contain extension points for future versions, options, extension fields, and other additions. Such extension points normally define rules intended to preserve interoperability in the presence of unknown parameters. However, even when an extension point is permitted by the specification, network devices or middleware on the path can make assumptions about packet formats and values based on what they already recognize. A new value or structure can violate those assumptions and disrupt communication. This phenomenon--where deploying an extension or a new version of an existing protocol over the Internet is impeded--is called protocol ossification. Protocol ossification has been observed in a range of protocols, including TCP, TLS 1.3, and QUIC. This document summarizes such cases and their mitigations. Each mitigation distinguishes specified measures, implemented measures, and observed deployment actions recorded by a source, as applicable.

Terminology

Endpoint:

A host, application, or service that initiates or terminates communication.

Middlebox:

A device or function between endpoints that does more than forward packets, including state tracking, inspection, transformation, or policy enforcement. NATs, firewalls, proxies, and load balancers are examples.

Ossification:

Loss of interoperability for a valid extension when an endpoint or an on-path implementation fails to handle an unknown value or new structure as required by the specification. It might reject, drop, rewrite, or misinterpret a version, code point, option, extension field, or header field reserved or defined for future use.

Intentional blocking:

A deliberate decision not to permit an unknown feature because of a security policy, regulation, or operational requirement. It can produce the same connection failure as ossification, but its cause is different. This document distinguishes the two.

GREASE:

A technique that sends reserved values with no semantic meaning during normal operation, exposing implementations that cannot ignore unknown values and preserving extensibility.

Communication Failure Classifications Communication failures caused by protocol ossification can take different forms. This document assigns a communication manifestation to each case.

Initial reachability failure:

The first packet, request, or response does not pass, so that a connection or its first transaction cannot start.

Negotiation failure:

A peer or path does not respond to, rejects, or incorrectly responds to a proposed version, capability, option, or extension.

In-flight dropping:

Packets, including those after initial exchange, are dropped on the path. A case identifies whether this is one-way or two-way when known.

Field or option removal/rewrite:

Communication might continue, but a middlebox removes, adds, or changes a header field, option, or payload.

Semantic or state failure:

Packets arrive, but rewriting, incomplete interpretation, or endpoint state disagreement breaks a function or subsequent communication.

Silent fallback or feature degradation:

Basic communication continues, but the new capability is not used and an older mechanism is used instead.

Failure of broad deployment:

In addition to individual failures, the protocol or feature cannot safely be assumed available on the general Internet.

Intentional policy blocking:

An operator explicitly does not permit a packet or feature under a security policy or similar policy.

Cases: Issues, Reported Observations, and Mitigations For each case, this document identifies the reported observation, its sources, and the associated response.

IP Layer

Dropping IPv6 Extension Headers Issue: Firewalls and other middleboxes drop packets containing IPv6 Extension Headers (EH), including standard Fragment Headers. Variable location of the Layer 4 header, arbitrary EH chains, and fragment reassembly are common causes. Communication manifestation: Initial reachability failure, in-flight dropping (one-way or two-way), and sometimes intentional policy blocking. Report category: Measurement or operational observation. Reported observations and sources: measured dropping of EH-containing packets on the Internet. records widely deployed firewalls that did not recognize standardized EHs or handle Fragment Headers. also summarizes operational problems and reports of intentional dropping.

Transport Layer

Reachability of New IP Transport Protocols Issue: NATs and stateful firewalls often implement and permit flow state only for TCP and UDP. An endpoint cannot assume that a new IP transport protocol, such as SCTP or DCCP, will traverse the general Internet. Communication manifestation: Initial reachability failure, failure of broad deployment, and sometimes intentional policy blocking. Report category: Measurement or operational observation. Reported observations and sources: Edeline et al. report RIPE Atlas and comparison traffic measurements showing that middleboxes impede new transports and extensions to existing transports. WebRTC data channels specify SCTP over DTLS over UDP rather than native SCTP . Mitigation: Specified measure: WebRTC data channels specify SCTP over DTLS over UDP rather than native SCTP .

TCP Fast Open and TCP Option Intolerance Issue: TCP Fast Open (TFO) cookies and data in SYN packets change assumptions made by middlebox TCP state machines. Operational deployments observed post-handshake black holes and one-way data drops. Communication manifestation: Field or option removal/rewrite, negotiation failure, and silent fallback or feature degradation. Report category: Measurement or operational observation. The case was observed in an Apple service deployment on iOS 9 and OS X 10.11. Reported observations and sources: Paasch shows a 30-second post-handshake black hole caused by middleboxes at some ISPs, and one-way data dropping. also notes middleboxes that remove unknown TCP options, and specifies fallback behavior for TFO. Mitigation: Specified measure: Treat TFO as opportunistic and promptly retry with an ordinary TCP handshake. Observed deployment action: The Apple deployment used aggressive client timeouts to blacklist a network for TFO and whitelisted a network after a successful TFO connection. It used TCP keepalive and receive sequence state to detect one-way loss.

TCP Sequence Translation and SACK Inconsistency Issue: A middlebox that inserts or removes TCP payload can translate the fixed sequence and acknowledgment fields but fail to translate SACK ranges. Endpoints then receive invalid SACK information and loss recovery can degrade. Communication manifestation: Field or option removal/rewrite and semantic or state failure. Report category: Documented implementation behavior. Reported observations and sources: identifies middleboxes that rewrite only the fixed TCP header and not SACK information as an example of TCP ossification.

MPTCP and ECN Issue: Paths that do not preserve MPTCP options such as MP_CAPABLE, MP_JOIN, and DSS cause capability negotiation to fail and fall back to regular TCP. ECN-capable SYNs and ECE/CWR handling have similar compatibility risks. Communication manifestation: Negotiation failure, field or option removal/rewrite, and silent fallback or feature degradation. Report category: Mixed. MPTCP includes documented implementation and operational behavior in . ECN-capable SYN fallback in is a specification consideration or design constraint. Reported observations and sources: specifies MPTCP fallback for middlebox compatibility and records operational heuristics. specifies fallback for middleboxes that drop ECN-capable SYNs. Mitigation: Specified measure: For MPTCP, fall back to TCP without MPTCP options when a middlebox prevents connection establishment. For ECN, retransmit the SYN without ECN negotiation if an ECN-capable SYN receives no response.

UDP Options: Mismatch between UDP Length and IP Length Issue: UDP Options use the surplus area after the user data indicated by the UDP Length field and before the end of the IP payload. The UDP Length and IP payload length therefore intentionally differ. Some implementations and inspection devices classify this difference as anomalous or an attack. Communication manifestation: Initial reachability failure or in-flight dropping. An IDS alert alone does not necessarily cause failure. Report category: Measurement or operational observation and documented implementation behavior. Reported observations and sources: , Section 18, records interoperability tests on Linux, macOS, Windows Cygwin, and NATs that delivered only user data, but also reports embedded devices that delivered the entire IP datagram to a UDP application. It records the default configuration of the Alcatel-Lucent "Brick" IDS, which reported a UDP/IP length mismatch as an attack. Mitigation: Specified measure: Initially use only SAFE Options so that legacy receivers retain the meaning of UDP user data.

Unsafe UDP Options and Endpoint Ossification Issue: UNSAFE Options for compression, encryption, fragmentation, and similar functions can break semantics when a legacy receiver ignores the option and processes user data. UDP provides no standard stateful negotiation, so a sender cannot know in advance that an endpoint supports such an option. Communication manifestation: Negotiation failure, semantic or state failure, or silent fallback or feature degradation. Report category: Specification consideration or design constraint. Reported observations and sources: defines SAFE Options as those that do not change user-data meaning if ignored. It deliberately defines incompatible behavior for UNSAFE Options, for example by making user data empty and placing payload in a FRAG Option. The RFC also explains that endpoint support cannot be known in advance. Mitigation: Specified measure: Make a new option SAFE where possible. For UNSAFE Options, use capability exchange, fallback, and reordering/loss handling at a higher layer, and do not permit in-transit modification.

TLS

Version Intolerance Issue: An old implementation can reject a ClientHello that advertises an unknown newer TLS version rather than selecting a supported lower version. Communication manifestation: Negotiation failure and initial reachability failure. Report category: Documented implementation behavior. Reported observations and sources: records version intolerance. TLS 1.3 moves version preference to the supported_versions extension and fixes legacy_version to the TLS 1.2 value, 0x0303. Mitigation: Specified measure: Do not depend on putting a new version directly in an old version field; use a compatible negotiation extension.

ClientHello Extension Intolerance and TLS 1.3 Compatibility Mode Issue: Endpoints and middleboxes can reject unknown TLS extensions, cipher suites, lengths, or handshake ordering. Some middleboxes treated the TLS 1.3 wire image as anomalous relative to TLS 1.2. Communication manifestation: Negotiation failure and initial reachability failure; compatibility mode can instead produce silent fallback or feature degradation. Report category: Measurement or operational observation. Reported observations and sources: , Appendix D.4, relies on field measurements and specifies compatibility mode, including a dummy ChangeCipherSpec. Benjamin reports a Chrome 63 rollout of TLS 1.3 draft 22 to 95% of stable users. A Canon PIXMA MX492 failed because BSAFE's private extended_random extension number 40 collided with TLS 1.3 key_share. Cisco Firepower in "Decrypt - Resign" mode improperly forwarded supported_versions, key_share, and the client random, breaking TLS 1.3 servers. defines TLS GREASE. QUIC's use of TLS does not use the CCS compatibility mode . Mitigation: Specified measure: Clients should continuously use GREASE.

Large PQC ClientHello Messages and TLS Inspection Intolerance Issue: Hybrid post-quantum key exchange enlarges supported_groups and key_share in ClientHello. The ClientHello can span multiple TCP segments. TLS inspection middleboxes that cannot reassemble and inspect it correctly can make the handshake fail. Communication manifestation: Negotiation failure and user-visible initial reachability failure; disabling PQC key exchange produces silent fallback or feature degradation. Report category: Measurement or operational observation. The sources identify concrete failures and fixes. Reported observations and sources: Chromium CECPQ2 records that larger TLS messages caused failures or timeouts in non-conformant middleware during a CECPQ2 rollout, including FortiGate and possibly Palo Alto Networks devices. CECPQ2 used X25519 and NTRU-HRSS and is not the same algorithm as current ML-KEM deployment, but is an operational precursor. Fortinet's technical note documents ERR_SSL_PROTOCOL_ERROR and a fatal illegal_parameter alert for ML-KEM ClientHello with Flow-based TLS Deep Inspection, with IPS Engine updates as the long-term resolution. Palo Alto Networks' technical note records SSL session failure when ClientHello arrives in multiple packets over an asymmetric path, with disabling the accumulation proxy or client PQC as workarounds. Mitigation: Implemented measure: Fortinet identifies an IPS Engine update for Flow-based TLS Deep Inspection as the long-term resolution .

Encrypted Client Hello and Middleboxes Assuming Plaintext SNI Issue: ECH places the real SNI and related information in a ClientHelloInner and sends a ClientHelloOuter containing an encrypted_client_hello extension. A middlebox that rejects unknown TLS extensions, or an inspection/termination proxy that assumes visible SNI, can fail the handshake. Deliberately disabling ECH to restore plaintext SNI can produce the same result, but is intentional policy blocking, not ossification. Communication manifestation: Negotiation failure, initial reachability failure, or silent fallback or feature degradation. A deliberate ECH block is intentional policy blocking. Report category: Specification consideration or design constraint. describes an incompatible TLS-terminating proxy as capable of retry or connection failure depending on the client's trust configuration. Reported observations and sources: , Section 6.2, specifies GREASE encrypted_client_hello for clients without an ECHConfig. Section 10.10.4 explicitly presents broad GREASE ECH deployment as a mitigation for network ossification. Section 8.1.2 explains how a conforming proxy ignores unknown parameters and connects to the public name, and how failure can result when the proxy certificate is not authoritative for that name. Mitigation: Specified measure: Clients should continue GREASE ECH.

DNS

No Response or FORMERR to EDNS(0) OPT Records Issue: An authoritative server, recursive resolver, or middlebox can give no response, return FORMERR, or remove an EDNS(0) OPT pseudo-RR. A resolver may be unable to distinguish packet loss from EDNS intolerance and falls back to plain DNS. Communication manifestation: Negotiation failure, in-flight dropping (query or response), and silent fallback or feature degradation. Report category: Measurement or operational observation. Reported observations and sources: records widespread non-response to EDNS queries, fallback to plain DNS, and possible DNSSEC validation failure. treats DNS extension intolerance as a case requiring broad fallback. Mitigation: Specified measure: Resolvers need EDNS fallback. draft-ietf-dnsop-grease-03 proposes low-rate GREASE of DNS extension points to expose intolerance to unknown values early.

Individual EDNS Option Intolerance and UDP Fragmentation Issue: Implementations that return FORMERR for an unknown EDNS option do not distinguish lack of that option from lack of EDNS as a whole. Large DNS UDP responses that require IP fragmentation can time out when fragments are dropped, including for DNSSEC resolution. Communication manifestation: Negotiation failure, in-flight dropping (primarily one-way on the response path), and silent fallback or feature degradation. Report category: Documented implementation and operational behavior. Reported observations and sources: describes incorrect handling of unknown EDNS options. describes EDNS-size fallback for DNSSEC reachability, and discusses oversized EDNS UDP payloads and fragmentation reachability.

HTTP

HTTP Fields and WAF Allowlists Issue: HTTP header fields, methods, status codes, and cache directives are extension points. A WAF, proxy, or cache that permits only known field names or values can block, remove, or misinterpret a new field or a permitted new value. Communication manifestation: Field or option removal/rewrite, semantic or state failure, or one-way in-flight dropping of a request or response. Report category: Specification consideration or design constraint. Reported observations and sources: draft-nottingham-http-grease identifies HTTP methods, status codes, header/trailer fields, cache directives, content codings, and range units as potentially ossified extension points and proposes GREASE.

QUIC and HTTP/3

Blocking UDP/443 Issue: In enterprise networks, access networks, or firewalls that block UDP/443, QUIC Initial packets cannot complete a round trip and an HTTP/3 connection cannot start. Communication manifestation: Initial reachability failure, failure of broad deployment, and sometimes intentional policy blocking. Report category: Measurement or operational observation. The available measurement is not limited to UDP/443. Reported observations and sources: The UDP reachability measurements in Edeline et al. show that UDP is not universally traversable.

Middlebox Ossification on Google QUIC Public Flags Google QUIC (GQUIC) in this section is the pre-IETF QUIC deployed and studied by Google from 2013 and in the 2017 paper cited below. It differs from IETF QUIC in wire format and cryptographic handshake. Issue: In October 2016, Google changed one public flag bit in a GQUIC packet header. A firewall product used that flag to identify and explicitly block GQUIC. Before the change, all GQUIC packets were blocked and the client could fall back to TCP. After the change, the classifier let the initial packet pass but blocked later packets, creating a black hole after connection start and preventing TCP fallback. Communication manifestation: In-flight dropping after the first packet, semantic or state failure, and initial reachability failure when fallback does not activate. Report category: Measurement or operational observation. Google observed the failure during global deployment, rolled back the change, and contacted the vendor. Reported observations and sources: Section 7.5 of Langley et al. records the one-bit change, pathological loss of later packets in a firewall, fallback failure, rollback, and a vendor classifier update. It also describes GQUIC's encryption of most transport-header information to reduce middlebox modification and ossification. Mitigation: Observed deployment action: In this case, client rollback and the vendor classifier update restored service. Implemented measure: GQUIC encrypted transport information that did not require middlebox interpretation.

IETF QUIC Versions and Visible Invariants IETF QUIC in this section is the standardized protocol based on . It is different from the GQUIC described in the preceding section. The risk of middleboxes fixing on a visible wire image is common to both. Issue: A QUIC-aware middlebox can depend on its own interpretation of the version-1 first packet, connection ID, fixed bit, or other visible values and thereby interfere with version 2 or a future version. Communication manifestation: Negotiation failure, initial reachability failure, or failure of broad deployment. Report category: Specification consideration or design constraint. QUIC v2 exercises version negotiation to resist ossification. Chaos Protection is an endpoint testing practice. Reported observations and sources: specifies QUIC v2 to exercise version negotiation and counter an ossification vector, including middlebox attention to the first packet. limits version-independent properties. Mitigation: Specified measure: QUIC v2 exercises version negotiation to mitigate ossification around version-1 Initial packets . Implemented measure: Chrome's QUIC implementation uses "Chaos Protection" that splits ClientHello across CRYPTO frames and varies PING, PADDING, and frame order; the quiche implementation records this practice.

NTP

NTPv4 Extension Field Intolerance Issue: NTPv4 can append Extension Fields after its fixed header. Existing implementations that discard a packet with an unknown Extension Field cannot interoperate with a peer sending a new field, although a receiver that does not use the field would otherwise ignore it and continue time synchronization. Communication manifestation: Negotiation failure or one-way/two-way in-flight dropping of requests and responses; retry without the field can be silent fallback or feature degradation. Report category: Documented implementation behavior. Reported observations and sources: says a host SHOULD ignore an unknown Extension Field, subject to policy. explicitly states that its UDP Checksum Complement Extension Field cannot interoperate with legacy implementations that discard unknown Extension Fields.

Why NTPv5 Negotiation Cannot Use Extension Fields Issue: NTPv5 is not wire-compatible with NTPv4. Some widely deployed NTPv4 servers interpret a higher-version request as NTPv4 and copy its version number into the response, or do not respond to a request containing an unknown Extension Field. NTPv4 Extension Fields therefore cannot be used for NTPv5 capability negotiation. Communication manifestation: Negotiation failure, one-way in-flight dropping of requests, and failure of broad deployment. Report category: Documented implementation behavior. The source records existing implementation behavior as a design input. Reported observations and sources: draft-ietf-ntp-ntpv5-09, Section 12 records these behaviors. Mitigation: Specified measure: NTPv5 places its negotiation signal in an existing reference-timestamp field.

Security Considerations This document introduces no new security considerations. Security considerations for each case are in the RFCs, Internet-Drafts, and other sources cited in the text.

IANA Considerations This document has no IANA actions.

References Normative References This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section. The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations. The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC 5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MACs). 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 describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure. It outlines potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face. This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements. 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. TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience. 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. The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. RFC 8261 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, which is referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values): "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". This specification also specifies how to use the new proto values with the SDP offer/answer mechanism for negotiating SCTP-over-DTLS associations. 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. 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 describes how Transport Layer Security (TLS) is used to secure QUIC. 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 summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet. 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. 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 specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC. Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks. This document specifies interleaved modes for the Network Time Protocol (NTP). These new modes improve the accuracy of time synchronization by enabling the use of more accurate transmit timestamps that are available only after the transmission of NTP messages. These enhancements are intended to improve timekeeping in environments where high accuracy is critical. This document updates RFC 5905 by defining these new operational modes. This document describes a mechanism in Transport Layer Security (TLS) for encrypting a message under a server public key. Transport protocols are extended through the use of transport header options. This document updates RFC 768 (UDP) by indicating the location, syntax, and semantics for UDP transport layer options within the surplus area after the end of the UDP user data but before the end of the IP datagram. This document provides guidelines and documents best current practice for operating authoritative DNS servers, recursive resolvers, and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. It also provides guidance on how recursive DNS resolvers should select upstream DNS servers, including when IPv4-embedded IPv6 addresses are available. This document obsoletes RFC 3901. Informative References arXiv:1612.07816 n.d. IETF 94 TCPM presentation TLS Working Group mailing list Chromium n.d. Fortinet n.d. Palo Alto Networks n.d. n.d. Internet-Draft, draft-ietf-dnsop-grease-03 n.d. Internet-Draft, draft-nottingham-http-grease n.d. SIGCOMM 2017 Chromium n.d. n.d. Internet-Draft, draft-ietf-ntp-ntpv5-09, Section 12

Acknowledgments The author thanks the authors and editors of the IETF specifications, operational documents, and measurement studies cited in this document.

References