Multiplexed Application Substrate over QUIC Encryption Y. Rosomakho Internet-Draft Zscaler Intended status: Standards Track T. Pauly Expires: 7 January 2027 Apple 6 July 2026 Extensions to Compress and Derive Fields in HTTP Datagrams draft-ietf-masque-http-datagram-compression-01 Abstract This document defines extensions for HTTP Datagram-based protocols that improve transmission efficiency by introducing templates for compressing or deriving datagram fields. These templates allow endpoints to define parts of datagrams that are static and can be removed, and other parts that can be derived (such as packet lengths and checksum values). Additionally, this document defines a checksum offload procedure enabling receivers to complete Internet checksums using sender- provided partial values. These optimisations reduce per-packet overhead, processing cost, and increase the effective maximum transmission unit (MTU) when datagrams are encapsulated in QUIC DATAGRAM frames. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://yaroslavros.github.io/connect-ip-optimizations/draft-ietf- masque-http-datagram-compression.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf- masque-http-datagram-compression/. Discussion of this document takes place on the Multiplexed Application Substrate over QUIC Encryption Working Group mailing list (mailto:masque@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/masque/. Subscribe at https://www.ietf.org/mailman/listinfo/masque/. Source for this draft and an issue tracker can be found at https://github.com/yaroslavros/connect-ip-optimizations. Rosomakho & Pauly Expires 7 January 2027 [Page 1] Internet-Draft HTTP Datagram Compression July 2026 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Negotiation of Capabilities . . . . . . . . . . . . . . . . . 6 3.1. Header Definition . . . . . . . . . . . . . . . . . . . . 6 3.2. Negotiation Behavior . . . . . . . . . . . . . . . . . . 7 3.2.1. Templates . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Derived Fields . . . . . . . . . . . . . . . . . . . 8 3.2.3. Checksum Offload . . . . . . . . . . . . . . . . . . 8 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Processing Context Capsules . . . . . . . . . . . . . . . . . 8 4.1. Processing Context Overview . . . . . . . . . . . . . . . 9 4.1.1. Processing Context Construction . . . . . . . . . . . 9 4.1.2. Processing Context Acknowledgement . . . . . . . . . 9 4.1.3. Processing Context Closure . . . . . . . . . . . . . 9 4.2. Template Capsules . . . . . . . . . . . . . . . . . . . . 10 Rosomakho & Pauly Expires 7 January 2027 [Page 2] Internet-Draft HTTP Datagram Compression July 2026 4.2.1. TEMPLATE_ASSIGN Capsule . . . . . . . . . . . . . . . 10 4.2.2. TEMPLATE_ACK Capsule . . . . . . . . . . . . . . . . 11 4.2.3. TEMPLATE_CLOSE Capsule . . . . . . . . . . . . . . . 12 4.3. Derived Field Capsules . . . . . . . . . . . . . . . . . 12 4.3.1. DERIVED_ASSIGN Capsule . . . . . . . . . . . . . . . 12 4.3.2. DERIVED_ACK Capsule . . . . . . . . . . . . . . . . . 13 4.3.3. DERIVED_CLOSE Capsule . . . . . . . . . . . . . . . . 13 4.4. Checksum Offload Capsules . . . . . . . . . . . . . . . . 13 4.4.1. CHECKSUM_ASSIGN Capsule . . . . . . . . . . . . . . . 13 4.4.2. CHECKSUM_ACK Capsule . . . . . . . . . . . . . . . . 14 4.4.3. CHECKSUM_CLOSE Capsule . . . . . . . . . . . . . . . 14 5. Processing Context Operation . . . . . . . . . . . . . . . . 15 5.1. Sender behavior . . . . . . . . . . . . . . . . . . . . . 15 5.1.1. Template Contexts . . . . . . . . . . . . . . . . . . 15 5.1.2. Derived Field Contexts . . . . . . . . . . . . . . . 16 5.1.3. Checksum Offload Contexts . . . . . . . . . . . . . . 16 5.1.4. Context Selection . . . . . . . . . . . . . . . . . . 16 5.1.5. Conservative Template Composition . . . . . . . . . . 16 5.2. Receiver behavior . . . . . . . . . . . . . . . . . . . . 18 5.2.1. Template Reconstruction . . . . . . . . . . . . . . . 18 5.2.2. Derived Field Processing . . . . . . . . . . . . . . 19 5.2.3. Checksum Offload Processing . . . . . . . . . . . . . 19 6. Derived Field Definitions . . . . . . . . . . . . . . . . . . 19 6.1. IPv4 Total Length . . . . . . . . . . . . . . . . . . . . 20 6.1.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 21 6.1.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 21 6.2. IPv6 Payload Length . . . . . . . . . . . . . . . . . . . 21 6.2.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 22 6.2.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 22 6.3. UDP Length over IPv4 . . . . . . . . . . . . . . . . . . 23 6.3.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 23 6.3.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 24 6.4. UDP Length over IPv6 . . . . . . . . . . . . . . . . . . 24 6.4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 24 6.4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 25 6.5. IPv4 Header Checksum . . . . . . . . . . . . . . . . . . 25 6.5.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 26 6.5.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 26 6.6. TCP Checksum over IPv4 . . . . . . . . . . . . . . . . . 27 6.6.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 27 6.6.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 28 6.7. TCP Checksum over IPv6 . . . . . . . . . . . . . . . . . 28 6.7.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 29 6.7.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 29 6.8. UDP Checksum over IPv4 . . . . . . . . . . . . . . . . . 30 6.8.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 30 6.8.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 31 6.9. UDP Checksum over IPv6 . . . . . . . . . . . . . . . . . 32 Rosomakho & Pauly Expires 7 January 2027 [Page 3] Internet-Draft HTTP Datagram Compression July 2026 6.9.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 32 6.9.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 33 6.10. Ethernet Frame Check Sequence . . . . . . . . . . . . . . 33 6.10.1. Sender behavior . . . . . . . . . . . . . . . . . . 34 6.10.2. Receiver Behavior . . . . . . . . . . . . . . . . . 34 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1. CONNECT-IP: TCP over IPv6 with template, derived fields and checksum offload . . . . . . . . . . . . . . . . . . . . 35 7.2. CONNECT-ETHERNET: UDP over IPv4 with template and derived fields . . . . . . . . . . . . . . . . . . . . . . . . . 40 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 45 8.2. Amplification . . . . . . . . . . . . . . . . . . . . . . 45 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 9.1. HTTP Capsule Types Registration . . . . . . . . . . . . . 45 9.2. HTTP Field Name Registration . . . . . . . . . . . . . . 46 9.3. HTTP Datagram Derived Field Types Registry . . . . . . . 47 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 10.1. Normative References . . . . . . . . . . . . . . . . . . 49 10.2. Informative References . . . . . . . . . . . . . . . . . 50 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 1. Introduction The CONNECT-IP method [CONNECT-IP] allows an HTTP client to establish an IP tunnel through an HTTP proxy and exchange IP packets using either HTTP/3 Datagrams (Section 2.1 of [HTTP-DATAGRAMS]) or DATAGRAM capsules (Section 3.5 of [HTTP-DATAGRAMS]). Similarly, CONNECT- ETHERNET [CONNECT-ETHERNET] allows sending Ethernet frames over HTTP Datagrams. These protocols send complete packets or frames by default, including all transport and network headers. This is a simple approach, but incurs per-packet overhead due to the repeated transmission of largely invariant header fields. Other HTTP Datagram-based protocols share similar properties: datagrams often contain structured packets where many header fields remain constant across a flow while only a subset of bytes change between packets. Transmitting complete packets therefore wastes bandwidth and processing resources. This document introduces a set of optional extensions that define Processing Contexts for HTTP Datagram payloads. A Processing Context describes transformations applied to a received datagram payload prior to delivery to the target protocol and may reference a parent context, forming a processing chain. Rosomakho & Pauly Expires 7 January 2027 [Page 4] Internet-Draft HTTP Datagram Compression July 2026 Reusable templates allow endpoints to associate a Context Identifier with a reusable packet layout consisting of static and variable byte regions. Once a template has been installed using reliable Capsules, datagrams referencing the same Context Identifier carry only the variable portions of the packet. This reduces the size of transmitted datagrams and processing overhead, while remaining compatibile with intermediaries that are unaware of these optimisations. Derived field processing allows the receiver to reconstruct certain header fields (for example packet length fields and complete checksums) based on the size and structure of the reconstructed packet. This eliminates the need for the sender to transmit such fields for every packet. In addition, this document defines a checksum offload procedure enabling endpoints to cooperatively compute Internet checksums, where the sender provides a partial checksum and the receiver completes the computation after reconstruction. This mirrors hardware checksum- offload behavior used on network interfaces and tunnel devices, reducing per-packet CPU cost for encapsulating or decapsulating CONNECT-IP and CONNECT-ETHERNET traffic. When HTTP Datagrams are encapsulated in QUIC DATAGRAM frames, these optimisations also increase the effective maximum transmission unit (MTU) by reducing the number of bytes carried inside each QUIC packet. All extensions are negotiated during the HTTP request/response handshake and signalled using Capsules on the reliable control stream. Endpoints can always fall back to transmitting complete datagrams using Context Identifier 0, which represents unoptimised datagrams containing the full payload as defined by the underlying HTTP Datagram protocol. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are used in this document: Context Identifier (Context ID): A numeric identifier associated Rosomakho & Pauly Expires 7 January 2027 [Page 5] Internet-Draft HTTP Datagram Compression July 2026 with a Processing Context. Context ID encoding and allocation follow the rules defined in Section 4 of [CONNECT-UDP]. Context ID 0 indicates that the datagram payload is delivered without additional processing as defined by the underlying HTTP Datagram protocol. Processing Context: A set of rules describing how an HTTP Datagram payload is transformed before delivery to the target protocol. A Processing Context may reference a parent context, forming a processing chain. Processing Contexts are immutable once created. Template: A reusable packet layout consisting of a sequence of static and variable segments. Static segments contain bytes removed from optimized datagrams, while variable segments correspond to bytes still carried in the datagram payload. Derived Field: A header field whose value is generated by the receiver during reconstruction and written into the reconstructed packet rather than being transmitted in the datagram payload. Derived fields include length fields and complete checksums. Checksum Offload: A capability allowing the receiver to complete the Internet checksum according to [INCREMENTAL-CHECKSUM] using a sender-provided partial checksum after reconstruction of the packet. Capsule: A reliable control-stream message, as defined in Section 3 of [HTTP-DATAGRAMS], used in this specification to signal creation, acknowledgement, or deletion of Processing Contexts. 3. Negotiation of Capabilities Endpoints negotiate support for HTTP Datagram processing contexts during the HTTP request/response handshake by using the http- datagram-contexts HTTP header field, whose value is a Structured Field Dictionary as defined in Section 3.2 of [STRUCTURED-HTTP]. 3.1. Header Definition http-datagram-contexts = sf-dictionary Figure 1: http-datagram-contexts header field This document defines the following optional dictionary keys: max-templates (Integer): Maximum number of concurrently active Rosomakho & Pauly Expires 7 January 2027 [Page 6] Internet-Draft HTTP Datagram Compression July 2026 template contexts the sender is willing to maintain for templates created by the peer. Absence of this key or value of 0 indicates that the sender does not support reusable templates. max-templates-segments (Integer): Maximum number of static segments accepted within a single template. Absence of this key or value of 0 indicates that the sender does not impose a limit on number of static segments in a single template. derived (Inner List): A list of supported Derived Field Types as defined in Section 9.3. Initial field definitions and reconstruction procedures are specified in Section 6. checksum (Boolean): Indicates support for the checksum offload procedure defined in this document. A value of ?1 means the endpoint is willing to complete checksums using sender-provided partial values. If omitted or set to ?0, checksum offload is not supported. mtu (Integer): Upper limit on maximum reconstructed packet size the receiver is willing to accept. Endpoints MUST ignore unknown dictionary members. The absence of a member implies that the corresponding capability is not supported for contexts created by the peer. 3.2. Negotiation Behavior Capabilities are directional. Each endpoint advertises the processing contexts it is willing to receive and maintain for datagrams sent by the peer. An endpoint MAY create a context only if the peer advertised support for the corresponding capability. 3.2.1. Templates If the peer advertises the max-templates value greater than 0, the endpoint MAY create template contexts up to that limit using capsules defined in Section 4. An endpoint MUST NOT create templates exceeding the peer's advertised max-template-segments limit when that parameter is present. If the peer advertises an mtu limit, the sender MUST NOT transmit a datagram that would reconstruct into a packet larger than the advertised limit after all processing contexts have been applied. Rosomakho & Pauly Expires 7 January 2027 [Page 7] Internet-Draft HTTP Datagram Compression July 2026 3.2.2. Derived Fields An endpoint MAY create a derived context only if every operation in the capsule appears in the peer's derived list. 3.2.3. Checksum Offload An endpoint MAY create a checksum offload context only if the peer advertised checksum=?1. 3.3. Example HTTP/3 sample request (client to proxy): :method = CONNECT :protocol = connect-ip :scheme = https :path = /.well-known/masque/ip/*/*/ :authority = proxy.example.net capsule-protocol = ?1 http-datagram-contexts = max-templates=20000, max-templates-segments=32, derived=(0 2 4), checksum=?1, mtu=1500 Figure 2: CONNECT-IP with http-datagram-contexts request example HTTP/3 sample response (proxy to client): :status = 200 capsule-protocol = ?1 http-datagram-contexts = max-templates=65535, derived=(0 1), checksum=?0, mtu=1500 Figure 3: CONNECT-IP with http-datagram-contexts response example In this example, both peers support reusable templates. The proxy supports a subset of derived fields (ipv4-total-length, ipv4-udp- length and ipv4-header-checksum) and the checksum offload. The client supports a different subset of derived fields (ipv4-total- length and ipv6-payload-length) without the checksum offload. Both endpoints indicate that the maximum packet size after reconstruction must not exceed 1500 bytes. 4. Processing Context Capsules This specification defines multiple capsule types to construct, acknowledge, and delete processing contexts. Rosomakho & Pauly Expires 7 January 2027 [Page 8] Internet-Draft HTTP Datagram Compression July 2026 4.1. Processing Context Overview 4.1.1. Processing Context Construction Processing contexts are created using capsules that define a new unique non-zero Context ID encoded as a variable-length integer. A Context ID MUST NOT be reused. As specified in Section 4 of [CONNECT-UDP], even-numbered Context IDs are allocated by the client and odd-numbered by the proxy. Each processing context MAY reference an already-defined parent context using Next Context ID encoded as a variable-length integer. A context MUST reference only a Context ID previously defined by the peer. Forward references are not permitted. Processing context without a parent is identified by Next Context ID set to 0. A processing chain MUST NOT contain more than one context of the same type. Other processing context chains can also have invalid combinations, if they include contradictory or mutually exclusive steps. Any capsule definition used for these contexts needs to define such cases if they are possible (such as for checksum offload contexts, Section 4.4). A receiver that detects such an invalid processing chain condition MUST treat the context as malformed and follow the error-handling procedure defined in Section 3.3 of [HTTP-DATAGRAMS]. A receiver of an *_ASSIGN capsule with an invalid Context ID or unknown Next Context ID MUST treat it as malformed and follow the error-handling procedure defined in Section 3.3 of [HTTP-DATAGRAMS]. 4.1.2. Processing Context Acknowledgement For each *_ASSIGN capsule received, the receiver MUST transmit the corresponding *_ACK capsule after successfully installing the context. Endpoints MAY transmit datagrams referencing contexts prior to receiving the *_ACK. A receiver MAY buffer datagrams referencing unknown Context IDs but MUST bound buffering by time and memory. A receiver of an *_ACK capsule with an unknown Context ID or any data after Context ID MUST treat it as malformed and follow the error- handling procedure defined in Section 3.3 of [HTTP-DATAGRAMS]. 4.1.3. Processing Context Closure Processing Contexts are retired by sending corresponding *_CLOSE capsule. Closing a context implicitly closes all contexts that reference it directly or transitively. Rosomakho & Pauly Expires 7 January 2027 [Page 9] Internet-Draft HTTP Datagram Compression July 2026 A receiver of a *_CLOSE capsule SHOULD retain the closed context and its descendants for a short period to allow in-flight datagrams to arrive, but MUST bound the retention time and memory usage. *_CLOSE capsules with unknown Context ID or any data after Context ID MUST be treated as malformed. Receiver of such capsules MUST follow the error-handling procedure defined in Section 3.3 of [HTTP-DATAGRAMS]. 4.2. Template Capsules 4.2.1. TEMPLATE_ASSIGN Capsule TEMPLATE_ASSIGN Capsule { Type (i) = 0x3ee3143f, Length (i), Context ID (i), Next Context ID (i), Static Segment (..) ... } Figure 4: TEMPLATE_ASSIGN Capsule Format The TEMPLATE_ASSIGN capsule contains a sequence of one or more Static Segments. Static Segment { Segment Offset (i), Segment Length (i), Segment Payload (..), } Figure 5: Static Segment Format Each Static Segment contains following fields: Segment Offset: Byte offset from the start of the reconstructed packet, encoded as a variable-length integer Segment Length: Length of the Segement Payload field, encoded as a variable-length integer Segment Payload: Static bytes to insert at the Segment Offset Rosomakho & Pauly Expires 7 January 2027 [Page 10] Internet-Draft HTTP Datagram Compression July 2026 4.2.1.1. Parsing and validation The receiver parses a TEMPLATE_ASSIGN capsule by reading, in order: the Context ID, the Next Context ID, and one or more static segments whose encodings consume exactly the remaining length of the capsule. Context ID and Next Context ID processing is described in Section 4.1.1. Each Static Segment consists of a Segment Offset, a Segment Length, and exactly Segment Length octets of Segment Payload. Static segments MUST appear in strictly increasing Segment Offset order and MUST NOT overlap. There MUST be at least 1 byte between consecutive segments. A receiver that advertised a max-templates-segments limit MUST ensure that the template does not contain more static segments. A receiver that advertised a mtu limit in http-datagram-contexts MUST ensure that the sum of Segment Offset and Segment Length of the final segment does not exceed the MTU limit. Final reconstructed packet size validation is performed during packet reconstruction (Section 5.2). The capsule MUST end immediately after the last static segment. If any of the capsule fields are malformed upon reception, the receiver of the capsule MUST follow the error-handling procedure defined in Section 3.3 of [HTTP-DATAGRAMS]. A receiver that has already accepted the maximum number of templates it advertised via the max-templates member in http-datagram-contexts MUST treat any additional TEMPLATE_ASSIGN capsule an error and MUST follow the same error-handling procedure. Per-packet validation uses the reconstruction procedure described in Section 5.2. 4.2.2. TEMPLATE_ACK Capsule TEMPLATE_ACK Capsule { Type (i) = 0x3ee31440, Length (i), Context ID (i), } Figure 6: TEMPLATE_ACK Capsule Format Processing of the TEMPLATE_ACK capsule is described in Section 4.1.2 Rosomakho & Pauly Expires 7 January 2027 [Page 11] Internet-Draft HTTP Datagram Compression July 2026 4.2.3. TEMPLATE_CLOSE Capsule TEMPLATE_CLOSE Capsule { Type (i) = 0x3ee31441, Length (i), Context ID (i), } Figure 7: TEMPLATE_CLOSE Capsule Format Processing of the TEMPLATE_CLOSE capsule is described in Section 4.1.3 4.3. Derived Field Capsules 4.3.1. DERIVED_ASSIGN Capsule DERIVED_ASSIGN Capsule { Type (i) = 0x3ee31442, Length (i), Context ID (i), Next Context ID (i), Derived Field Type (i) ... } Figure 8: DERIVED_ASSIGN Capsule Format The DERIVED_ASSIGN capsule defines a processing context that generates and inserts one or more derived fields into the reconstructed packet. The sender does not transmit these fields in the datagram payload. The Derived Field Types defined by this document and their reconstruction procedures are specified in Section 6. The numeric code points for these field types are registered in Section 9.3. 4.3.1.1. Parsing and validation The receiver parses a DERIVED_ASSIGN capsule by reading, in order: the Context ID, the Next Context ID, and one or more Derived Field Type values encoded as variable-length integers. Context ID and Next Context ID processing is described in Section 4.1.1. If a Derived Field Type is not present in the receiver's advertised derived capability list in http-datagram-contexts or if any Derived Field Type appears more than once in the capsule, the receiver MUST treat the capsule as malformed and follow the error-handling procedure defined in Section 3.3 of [HTTP-DATAGRAMS]. Rosomakho & Pauly Expires 7 January 2027 [Page 12] Internet-Draft HTTP Datagram Compression July 2026 Per-packet validation uses the reconstruction procedure described in Section 5.2. 4.3.2. DERIVED_ACK Capsule DERIVED_ACK Capsule { Type (i) = 0x3ee31443, Length (i), Context ID (i), } Figure 9: DERIVED_ACK Capsule Format Processing of the DERIVED_ACK capsule is described in Section 4.1.2 4.3.3. DERIVED_CLOSE Capsule DERIVED_CLOSE Capsule { Type (i) = 0x3ee31444, Length (i), Context ID (i), } Figure 10: DERIVED_CLOSE Capsule Format Processing of the DERIVED_CLOSE capsule is described in Section 4.1.3 4.4. Checksum Offload Capsules 4.4.1. CHECKSUM_ASSIGN Capsule CHECKSUM_ASSIGN Capsule { Type (i) = 0x3ee31445, Length (i), Context ID (i), Next Context ID (i), Checksum Field Offset (i), Checksum Start Offset (i), } Figure 11: CHECKSUM_ASSIGN Capsule Format The CHECKSUM_ASSIGN capsule defines a processing context that completes an Internet checksum for the reconstructed packet using a sender-provided partial checksum. In addition to Context ID and Next Context ID CHECKSUM_ASSIGN capsule contains following fields encoded as variable-length integers: Rosomakho & Pauly Expires 7 January 2027 [Page 13] Internet-Draft HTTP Datagram Compression July 2026 Checksum Field Offset: Byte offset of the 16-bit Internet checksum field within the reconstructed packet Checksum Start Offset: Byte offset where checksum coverage begins. Coverage runs from this offset to the end of the reconstructed packet. 4.4.1.1. Parsing and validation The receiver parses a CHECKSUM_ASSIGN capsule by reading, in order: the Context ID, the Next Context ID, Checksum Field Offset and Checksum Start Offset. Context ID and Next Context ID processing is described in Section 4.1.1. If the peer did not advertise checksum=?1 in http-datagram-contexts, the receiver MUST treat the capsule as malformed and follow the error-handling procedure defined in Section 3.3 of [HTTP-DATAGRAMS]. If Checksum Start Offset is 0, the receiver MUST treat the capsule as malformed and follow the same error-handling procedure. Per-packet validation uses the reconstruction procedure described in Section 5.2. Chaining a CHECKSUM_ASSIGN capsule with a DERIVED_ASSIGN capsule that defines derivation for a UDP or TCP checksum (Section 9.3) would create an invalid processing chain, as described in Section 4.1.1. Such chains MUST NOT be defined by senders, and MUST be treated as an error by receivers. 4.4.2. CHECKSUM_ACK Capsule CHECKSUM_ACK Capsule { Type (i) = 0x3ee31446, Length (i), Context ID (i), } Figure 12: CHECKSUM_ACK Capsule Format Processing of the CHECKSUM_ACK capsule is described in Section 4.1.2 4.4.3. CHECKSUM_CLOSE Capsule Rosomakho & Pauly Expires 7 January 2027 [Page 14] Internet-Draft HTTP Datagram Compression July 2026 CHECKSUM_CLOSE Capsule { Type (i) = 0x3ee31447, Length (i), Context ID (i), } Figure 13: CHECKSUM_CLOSE Capsule Format Processing of the CHECKSUM_CLOSE capsule is described in Section 4.1.3 5. Processing Context Operation This section defines how endpoints construct and consume HTTP Datagram payloads using Processing Contexts. A datagram carries a Context Identifier that selects the initial Processing Context. A context MAY reference a parent context using Next Context ID. The complete behavior is defined by recursively following parent contexts until reaching Context ID 0. Context ID 0 indicates that no processing is applied and the payload is delivered unchanged to the underlying HTTP Datagram protocol. 5.1. Sender behavior When sending a datagram using a Processing Context, the sender constructs the payload so that the receiver can reconstruct the final packet after applying the processing chain. The sender MUST use a Context ID only after the corresponding *_ASSIGN capsule has been transmitted. 5.1.1. Template Contexts If the selected context chain contains a Template context, the sender constructs the datagram payload as the concatenation of all variable byte regions not covered by static segments. Variable regions are emitted in strictly increasing offset order starting at offset 0. If the context chain contains no Template context, the payload MUST be the complete packet. Rosomakho & Pauly Expires 7 January 2027 [Page 15] Internet-Draft HTTP Datagram Compression July 2026 5.1.2. Derived Field Contexts Derived fields are not transmitted by the sender. When a derived context is in use, the sender MUST remove the octets corresponding to derived fields from the datagram payload. These octets are supplied by the receiver during reconstruction. The sender MUST construct the payload as if the derived field octets were not part of the variable regions. That is, the payload MUST contain only the remaining variable octets in strictly increasing offset order. 5.1.3. Checksum Offload Contexts If the context chain contains a checksum offload context, the sender MUST place a precomputed partial Internet checksum value into the checksum field at Checksum Field Offset in the reconstructed packet image prior to transmission. This value is combined with the receiver computation as described in Section 5.2. 5.1.4. Context Selection If a packet does not match any available Processing Context, the sender MUST use Context ID 0 and transmit the complete packet. In such cases, if the packet is transmitted in an HTTP/3 Datagram, it might not fit within the current path MTU towards the peer. When the packet is larger than sizes known to fit within the path MTU as HTTP/3 Datagrams, the sender SHOULD instead send the packet in a DATAGRAM Capsule according to Section 3.5 of [HTTP-DATAGRAMS], which will be encoded on the HTTP data stream and fragmented across QUIC packets if necessary. To avoid this suboptimal behavior, senders SHOULD define broad contexts that will be able to handle most or all expected traffic. 5.1.5. Conservative Template Composition Reusable templates are most effective when they remain valid for many datagrams. Senders SHOULD construct templates conservatively by including only fields that are expected to remain stable for the lifetime of the Processing Context. Fields whose values can change during the lifetime of a flow SHOULD remain in the variable portion of the datagram unless the sender has specific knowledge that those fields will remain constant or be particularly frequent for some period of time. Fields that are commonly suitable for static segments include fields that identify the packet format or the flow, such as: Rosomakho & Pauly Expires 7 January 2027 [Page 16] Internet-Draft HTTP Datagram Compression July 2026 * Ethernet source and destination addresses, when stable for the frame sequence * EtherType * 802.1Q tag * IP version * Source and destination IP addresses * IPv4 TTL / IPv6 Hop Limit * IPv4 Protocol / IPv6 Next Header * Source and destination transport ports Fields that commonly vary during a flow, or that can be modified by endpoints or network devices, are generally poor candidates for static segments. Examples include: * IPv4 DSCP and ECN bits, and IPv6 Traffic Class * IPv4 Identification * IPv4 Flags and Fragment Offset, unless packets using the template are known not to be fragmented * IPv6 Flow Label, unless the sender knows it is stable for the flow * TCP Sequence Number * TCP Acknowledgement Number * TCP Flags * TCP Window * TCP Timestamp values * Packet length fields * Checksum fields When a field can be represented as a Derived Field defined by this specification, implementations SHOULD prefer using the corresponding Derived Field instead of including that field in a static segment or transmitting it as part of the variable payload. Packet length Rosomakho & Pauly Expires 7 January 2027 [Page 17] Internet-Draft HTTP Datagram Compression July 2026 fields and complete checksums are examples of fields that are generally better represented using Derived Fields when supported by the peer. The suitability of a field for inclusion in a static segment depends on the deployment and the traffic being carried. For example, some deployments might preserve DSCP values while others rewrite them, and some applications might intentionally vary the IPv6 Flow Label. Implementations are encouraged to prefer templates that remain valid across many datagrams, even if those templates omit fewer bytes than a more aggressive template. 5.2. Receiver behavior Upon receiving an HTTP Datagram with a non-zero Context ID, the receiver retrieves the referenced Processing Context and recursively resolves its parent contexts until Context ID 0 is reached. If any referenced context is unknown, the receiver MAY buffer the datagram as described in Section 4.1.2 or drop it. If multiple processing contexts are present in a chain, the receiver MUST apply them in the following order: 1. Template reconstruction (if present) 2. Derived field processing (if present) 3. Checksum offload processing (if present) 5.2.1. Template Reconstruction If a Template context is present, the receiver reconstructs the packet as follows: 1. Allocate a buffer large enough to contain the reconstructed packet. 2. Insert static segment bytes at their specified offsets. 3. Fill all remaining gaps using bytes from the datagram payload in strictly increasing offset order. If payload bytes are exhausted before all gaps have been filled the datagram MUST be dropped. Packets larger than the advertised mtu in http-datagram-contexts MUST be dropped. Rosomakho & Pauly Expires 7 January 2027 [Page 18] Internet-Draft HTTP Datagram Compression July 2026 5.2.2. Derived Field Processing For each derived field present in the context chain, the receiver computes the field value and inserts it into the reconstructed packet at the location defined by the derived field type. Derived fields are inserted into the packet image and therefore increase the reconstructed packet size. The receiver MUST compute derived field values based on the final reconstructed packet size and structure. Initial field definitions and reconstruction procedures are specified in Section 6. If the required header cannot be located, the packet MUST be dropped. 5.2.3. Checksum Offload Processing If a checksum offload context is present, the receiver completes the Internet checksum after all derived fields have been inserted. The receiver completes the checksum as follows: 1. Treat the checksum field as zero. 2. Compute the one's-complement sum from Checksum Start Offset to L. 3. Add (fold) the 16-bit value currently present at the checksum field. 4. Write the final one's-complement result to the checksum field. If any offset exceeds the reconstructed packet length, the packet MUST be dropped. 6. Derived Field Definitions This section defines the initial Derived Field Types registered by this document in Section 9.3. All offsets in this section are in octets from the beginning of the reconstructed packet or frame. All multi-octet integer fields are encoded in network byte order. For CONNECT-IP, the IP header starts at offset 0. Rosomakho & Pauly Expires 7 January 2027 [Page 19] Internet-Draft HTTP Datagram Compression July 2026 For CONNECT-ETHERNET, the IP- and transport-layer Derived Field Types defined in this section apply to Ethernet II frames carrying IPv4 or IPv6, including frames with a single IEEE 802.1Q VLAN tag. For an untagged Ethernet II frame [IEEE802.3], the EtherType field is located at offset 12 and the IP header starts at offset 14. For an Ethernet II frame with a single IEEE 802.1Q VLAN tag [IEEE802.1Q], the Tag Protocol Identifier (TPID) field is located at offset 12 and has value 0x8100. The encapsulated EtherType field is located at offset 16 and the IP header starts at offset 18. Frames with multiple VLAN tags or other link-layer encapsulations are not processed by these Derived Field Types unless a future specification defines how the relevant network-layer header is located. The EtherType value 0x0800 identifies IPv4, and the EtherType value 0x86dd identifies IPv6. If the relevant EtherType does not identify the protocol required by the Derived Field Type, the sender MUST NOT use a Processing Context containing that Derived Field Type for the frame. If the receiver cannot locate the header required by a Derived Field Type in the selected Processing Context, the datagram MUST be dropped. When multiple derived fields are present in a processing chain, the receiver computes length fields before checksum fields. In particular, IPv4 Total Length, IPv6 Payload Length, and UDP Length fields are computed before IPv4 header, TCP, or UDP checksums. Where this section requires locating an upper-layer header in an IPv6 packet, the sender and receiver traverse the IPv6 Next Header chain starting from the fixed IPv6 header. The traversal follows extension headers that identify the following header using a Next Header field and whose length can be determined from the packet contents. If traversal encounters an IPv6 Fragment header before locating the required upper-layer header, or if traversal reaches a header whose following header cannot be determined, the required header is considered not located and derived field compression cannot be used. If a packet is too short to contain a field being derived, if a required protocol header cannot be located, or if a computed value cannot be represented in the target field, the packet MUST be dropped. 6.1. IPv4 Total Length The ipv4-total-length field corresponds to the Total Length field of the IPv4 header defined in Section 3.1 of [IPv4]. Rosomakho & Pauly Expires 7 January 2027 [Page 20] Internet-Draft HTTP Datagram Compression July 2026 The field location is: +==============+==================================+========+ | Field | Offset from start of IPv4 header | Length | +==============+==================================+========+ | Total Length | 2 | 2 | +--------------+----------------------------------+--------+ Table 1 6.1.1. Sender Behavior When using this Derived Field Type, the sender removes the IPv4 Total Length field from the datagram payload. The sender MUST only use this Derived Field Type for packets whose IPv4 header can be located according to the rules in Section 6. The sender MUST verify that the first four bits of the located IP header contain the IPv4 version value 4 before using this Derived Field Type. The sender MUST verify that the value of the IPv4 Total Length field in the original packet is equal to the number of octets from the start of the IPv4 header to the end of the IPv4 packet that will be reconstructed by the receiver. If the value does not match, the sender MUST NOT use this Derived Field Type for that packet. 6.1.2. Receiver Behavior The receiver locates the IPv4 header according to the rules in Section 6. The first four bits of the header MUST contain the IPv4 version value 4. The Internet Header Length (IHL) field MUST indicate an IPv4 header length of at least 20 octets and no larger than the reconstructed IPv4 packet. The receiver computes the field value as the number of octets from the start of the IPv4 header to the end of the reconstructed IPv4 packet. If the computed value is greater than 65535, the packet MUST be dropped. The receiver writes the computed value into the IPv4 Total Length field. 6.2. IPv6 Payload Length The ipv6-payload-length field corresponds to the Payload Length field of the IPv6 header defined in Section 3 of [IPv6]. Rosomakho & Pauly Expires 7 January 2027 [Page 21] Internet-Draft HTTP Datagram Compression July 2026 The field location is: +================+==================================+========+ | Field | Offset from start of IPv6 header | Length | +================+==================================+========+ | Payload Length | 4 | 2 | +----------------+----------------------------------+--------+ Table 2 6.2.1. Sender Behavior When using this Derived Field Type, the sender removes the IPv6 Payload Length field from the datagram payload. The sender MUST only use this Derived Field Type for packets whose IPv6 header can be located according to the rules in Section 6. The sender MUST verify that the first four bits of the located IP header contain the IPv6 version value 6 before using this Derived Field Type. The sender MUST verify that the value of the IPv6 Payload Length field in the original packet is equal to the number of octets following the fixed 40-octet IPv6 header in the IPv6 packet that will be reconstructed by the receiver. If the value does not match, the sender MUST NOT use this Derived Field Type for that packet. This Derived Field Type does not support IPv6 jumbograms ([IPv6-JUMBO]). If the IPv6 Payload Length field in the original packet is zero, the sender MUST NOT use this Derived Field Type for that packet. 6.2.2. Receiver Behavior The receiver locates the IPv6 header according to the rules in Section 6. The first four bits of the header MUST contain the IPv6 version value 6. The receiver computes the field value as the number of octets following the fixed 40-octet IPv6 header in the reconstructed IPv6 packet. If the computed value is 0 or greater than 65535, the packet MUST be dropped. The receiver writes the computed value into the IPv6 Payload Length field. Rosomakho & Pauly Expires 7 January 2027 [Page 22] Internet-Draft HTTP Datagram Compression July 2026 6.3. UDP Length over IPv4 The ipv4-udp-length field corresponds to the Length field of the UDP header defined in [UDP] when UDP is carried over IPv4. The field location is: +========+=================================+========+ | Field | Offset from start of UDP header | Length | +========+=================================+========+ | Length | 4 | 2 | +--------+---------------------------------+--------+ Table 3 6.3.1. Sender Behavior When using this Derived Field Type, the sender removes the UDP Length field from the datagram payload. The sender MUST only use this Derived Field Type for packets whose IPv4 header can be located according to the rules in Section 6. The sender MUST verify that the first four bits of the located IP header contain the IPv4 version value 4 before using this Derived Field Type. The sender MUST verify that the IPv4 Protocol field contains the UDP protocol number 17. The sender MUST verify that the IPv4 packet is not fragmented. In particular, the sender MUST verify that the More Fragments flag is 0 and that the Fragment Offset field is 0 before using this Derived Field Type. The sender determines the UDP header offset from the IPv4 Internet Header Length (IHL) field. The sender MUST verify that the IPv4 packet contains at least 8 octets starting at that offset. The sender MUST verify that the value of the UDP Length field in the original packet is equal to the number of octets from the start of the UDP header to the end of the IPv4 packet that will be reconstructed by the receiver. If the value does not match, the sender MUST NOT use this Derived Field Type for that packet. Rosomakho & Pauly Expires 7 January 2027 [Page 23] Internet-Draft HTTP Datagram Compression July 2026 6.3.2. Receiver Behavior The receiver locates the IPv4 header according to the rules in Section 6. The first four bits of the header MUST contain the IPv4 version value 4. The Internet Header Length (IHL) field MUST indicate an IPv4 header length of at least 20 octets and no larger than the reconstructed IPv4 packet. The IPv4 Protocol field MUST contain the UDP protocol number 17. The IPv4 packet MUST NOT be fragmented. The More Fragments flag MUST be 0 and the Fragment Offset field MUST be 0. The receiver determines the UDP header offset from the IPv4 Internet Header Length (IHL) field. If the reconstructed IPv4 packet does not contain at least 8 octets starting at that offset, the packet MUST be dropped. The receiver computes the UDP Length field as the number of octets from the start of the UDP header to the end of the reconstructed IPv4 packet. If the computed value is less than 8 or greater than 65535, the packet MUST be dropped. The receiver writes the computed value into the UDP Length field. 6.4. UDP Length over IPv6 The ipv6-udp-length field corresponds to the Length field of the UDP header defined in [UDP] when UDP is carried over IPv6. The field location is: +========+=================================+========+ | Field | Offset from start of UDP header | Length | +========+=================================+========+ | Length | 4 | 2 | +--------+---------------------------------+--------+ Table 4 6.4.1. Sender Behavior When using this Derived Field Type, the sender removes the UDP Length field from the datagram payload. Rosomakho & Pauly Expires 7 January 2027 [Page 24] Internet-Draft HTTP Datagram Compression July 2026 The sender MUST only use this Derived Field Type for packets whose IPv6 header can be located according to the rules in Section 6. The sender MUST verify that the first four bits of the located IP header contain the IPv6 version value 6 before using this Derived Field Type. The sender MUST locate the UDP header by traversing the IPv6 Next Header chain starting from the fixed IPv6 header. The sender MUST NOT use this Derived Field Type for a packet if this traversal does not identify a UDP header, if the UDP header is not fully contained in the IPv6 packet, or if the traversal encounters an IPv6 Fragment header before reaching the UDP header. The sender MUST verify that the value of the UDP Length field in the original packet is equal to the number of octets from the start of the UDP header to the end of the IPv6 packet that will be reconstructed by the receiver. If the value does not match, the sender MUST NOT use this Derived Field Type for that packet. 6.4.2. Receiver Behavior The receiver locates the IPv6 header according to the rules in Section 6. The first four bits of the header MUST contain the IPv6 version value 6. The receiver locates the UDP header by traversing the IPv6 Next Header chain starting from the fixed IPv6 header. If traversal does not identify a UDP header, if traversal encounters an IPv6 Fragment header before reaching the UDP header, or if the reconstructed IPv6 packet does not contain a complete UDP header at the resulting offset, the packet MUST be dropped. The receiver computes the UDP Length field as the number of octets from the start of the UDP header to the end of the reconstructed IPv6 packet. If the computed value is less than 8 or greater than 65535, the packet MUST be dropped. The receiver writes the computed value into the UDP Length field. 6.5. IPv4 Header Checksum The ipv4-header-checksum field corresponds to the Header Checksum field of the IPv4 header defined in Section 3.1 of [IPv4]. The field location is: Rosomakho & Pauly Expires 7 January 2027 [Page 25] Internet-Draft HTTP Datagram Compression July 2026 +=================+==================================+========+ | Field | Offset from start of IPv4 header | Length | +=================+==================================+========+ | Header Checksum | 10 | 2 | +-----------------+----------------------------------+--------+ Table 5 6.5.1. Sender Behavior When using this Derived Field Type, the sender removes the IPv4 Header Checksum field from the datagram payload. The sender MUST only use this Derived Field Type for packets whose IPv4 header can be located according to the rules in Section 6. The sender MUST verify that the first four bits of the located IP header contain the IPv4 version value 4 before using this Derived Field Type. The sender MUST verify that the Internet Header Length (IHL) field indicates an IPv4 header length of at least 20 octets and no larger than the original IPv4 packet. The sender MUST verify that the value of the IPv4 Header Checksum field in the original packet is equal to the Internet checksum computed over the IPv4 header, with the IPv4 Header Checksum field treated as zero for the computation. If the value does not match, the sender MUST NOT use this Derived Field Type for that packet. 6.5.2. Receiver Behavior The receiver locates the IPv4 header according to the rules in Section 6. The first four bits of the header MUST contain the IPv4 version value 4. The Internet Header Length (IHL) field MUST indicate an IPv4 header length of at least 20 octets and no larger than the reconstructed IPv4 packet. The receiver computes the IPv4 header checksum over the IPv4 header, with the IPv4 Header Checksum field treated as zero for the computation. The receiver writes the computed value into the IPv4 Header Checksum field. Rosomakho & Pauly Expires 7 January 2027 [Page 26] Internet-Draft HTTP Datagram Compression July 2026 6.6. TCP Checksum over IPv4 The ipv4-tcp-checksum field corresponds to the Checksum field of the TCP header defined in Section 3.1 of [TCP] when TCP is carried over IPv4. The field location is: +==========+=================================+========+ | Field | Offset from start of TCP header | Length | +==========+=================================+========+ | Checksum | 16 | 2 | +----------+---------------------------------+--------+ Table 6 6.6.1. Sender Behavior When using this Derived Field Type, the sender removes the TCP Checksum field from the datagram payload. The sender MUST only use this Derived Field Type for packets whose IPv4 header can be located according to the rules in Section 6. The sender MUST verify that the first four bits of the located IP header contain the IPv4 version value 4 before using this Derived Field Type. The sender MUST verify that the IPv4 Protocol field contains the TCP protocol number 6. The sender MUST verify that the IPv4 packet is not fragmented. In particular, the sender MUST verify that the More Fragments flag is 0 and that the Fragment Offset field is 0 before using this Derived Field Type. The sender determines the TCP header offset from the IPv4 Internet Header Length (IHL) field. The sender MUST verify that the IPv4 packet contains at least 20 octets starting at that offset. The sender MUST verify that the TCP Data Offset field indicates a TCP header length of at least 20 octets and no larger than the TCP segment contained in the IPv4 packet. The TCP header length is the value of the TCP Data Offset field multiplied by 4. Rosomakho & Pauly Expires 7 January 2027 [Page 27] Internet-Draft HTTP Datagram Compression July 2026 The sender MUST verify that the value of the TCP Checksum field in the original packet is equal to the Internet checksum computed over the IPv4 pseudo-header, the TCP header, and the TCP payload, with the TCP Checksum field treated as zero for the computation. If the value does not match, the sender MUST NOT use this Derived Field Type for that packet. 6.6.2. Receiver Behavior The receiver locates the IPv4 header according to the rules in Section 6. The first four bits of the header MUST contain the IPv4 version value 4. The Internet Header Length (IHL) field MUST indicate an IPv4 header length of at least 20 octets and no larger than the reconstructed IPv4 packet. The IPv4 Protocol field MUST contain the TCP protocol number 6. The IPv4 packet MUST NOT be fragmented. The More Fragments flag MUST be 0 and the Fragment Offset field MUST be 0. The receiver determines the TCP header offset from the IPv4 Internet Header Length (IHL) field. If the reconstructed IPv4 packet does not contain at least 20 octets starting at that offset, the packet MUST be dropped. The TCP Data Offset field MUST indicate a TCP header length of at least 20 octets and no larger than the TCP segment contained in the reconstructed IPv4 packet. The TCP header length is the value of the TCP Data Offset field multiplied by 4. The receiver computes the TCP Checksum over the IPv4 pseudo-header, the TCP header, and the TCP payload, with the TCP Checksum field treated as zero for the computation. The receiver writes the computed value into the TCP Checksum field. 6.7. TCP Checksum over IPv6 The ipv6-tcp-checksum field corresponds to the Checksum field of the TCP header defined in Section 3.1 of [TCP] when TCP is carried over IPv6. The field location is: Rosomakho & Pauly Expires 7 January 2027 [Page 28] Internet-Draft HTTP Datagram Compression July 2026 +==========+=================================+========+ | Field | Offset from start of TCP header | Length | +==========+=================================+========+ | Checksum | 16 | 2 | +----------+---------------------------------+--------+ Table 7 6.7.1. Sender Behavior When using this Derived Field Type, the sender removes the TCP Checksum field from the datagram payload. The sender MUST only use this Derived Field Type for packets whose IPv6 header can be located according to the rules in Section 6. The sender MUST verify that the first four bits of the located IP header contain the IPv6 version value 6 before using this Derived Field Type. The sender MUST locate the TCP header by traversing the IPv6 Next Header chain starting from the fixed IPv6 header. The sender MUST NOT use this Derived Field Type for a packet if this traversal does not identify a TCP header, if the TCP header is not fully contained in the IPv6 packet, or if the traversal encounters an IPv6 Fragment header before reaching the TCP header. The sender MUST verify that the TCP Data Offset field indicates a TCP header length of at least 20 octets and no larger than the TCP segment contained in the IPv6 packet. The TCP header length is the value of the TCP Data Offset field multiplied by 4. The sender MUST verify that the value of the TCP Checksum field in the original packet is equal to the Internet checksum computed over the IPv6 pseudo-header, the TCP header, and the TCP payload, with the TCP Checksum field treated as zero for the computation. If the value does not match, the sender MUST NOT use this Derived Field Type for that packet. 6.7.2. Receiver Behavior The receiver locates the IPv6 header according to the rules in Section 6. The first four bits of the header MUST contain the IPv6 version value 6. Rosomakho & Pauly Expires 7 January 2027 [Page 29] Internet-Draft HTTP Datagram Compression July 2026 The receiver locates the TCP header by traversing the IPv6 Next Header chain starting from the fixed IPv6 header. If traversal does not identify a TCP header, if traversal encounters an IPv6 Fragment header before reaching the TCP header, or if the reconstructed IPv6 packet does not contain a complete TCP header at the resulting offset, the packet MUST be dropped. The TCP Data Offset field MUST indicate a TCP header length of at least 20 octets and no larger than the TCP segment contained in the reconstructed IPv6 packet. The TCP header length is the value of the TCP Data Offset field multiplied by 4. The receiver computes the TCP Checksum over the IPv6 pseudo-header, the TCP header, and the TCP payload, with the TCP Checksum field treated as zero for the computation. The receiver writes the computed value into the TCP Checksum field. 6.8. UDP Checksum over IPv4 The ipv4-udp-checksum field corresponds to the Checksum field of the UDP header defined in [UDP] when UDP is carried over IPv4. The field location is: +==========+=================================+========+ | Field | Offset from start of UDP header | Length | +==========+=================================+========+ | Checksum | 6 | 2 | +----------+---------------------------------+--------+ Table 8 6.8.1. Sender Behavior When using this Derived Field Type, the sender removes the UDP Checksum field from the datagram payload. The sender MUST only use this Derived Field Type for packets whose IPv4 header can be located according to the rules in Section 6. The sender MUST verify that the first four bits of the located IP header contain the IPv4 version value 4 before using this Derived Field Type. The sender MUST verify that the IPv4 Protocol field contains the UDP protocol number 17. Rosomakho & Pauly Expires 7 January 2027 [Page 30] Internet-Draft HTTP Datagram Compression July 2026 The sender MUST verify that the IPv4 packet is not fragmented. In particular, the sender MUST verify that the More Fragments flag is 0 and that the Fragment Offset field is 0 before using this Derived Field Type. The sender determines the UDP header offset from the IPv4 Internet Header Length (IHL) field. The sender MUST verify that the IPv4 packet contains at least 8 octets starting at that offset. The sender MUST verify that the UDP Length field is at least 8 and no larger than the number of octets from the start of the UDP header to the end of the IPv4 packet. The sender MUST verify that the value of the UDP Checksum field in the original packet is equal to the Internet checksum computed over the IPv4 pseudo-header, the UDP header, and the UDP payload, with the UDP Checksum field treated as zero for the computation. If the computed checksum value is zero, the value to be compared is 0xffff. If the value does not match, the sender MUST NOT use this Derived Field Type for that packet. This Derived Field Type always generates a UDP checksum. The sender MUST NOT use this Derived Field Type for IPv4 UDP packets that use a UDP Checksum field value of zero to indicate that no checksum is present. 6.8.2. Receiver Behavior The receiver locates the IPv4 header according to the rules in Section 6. The first four bits of the header MUST contain the IPv4 version value 4. The Internet Header Length (IHL) field MUST indicate an IPv4 header length of at least 20 octets and no larger than the reconstructed IPv4 packet. The IPv4 Protocol field MUST contain the UDP protocol number 17. The IPv4 packet MUST NOT be fragmented. The More Fragments flag MUST be 0 and the Fragment Offset field MUST be 0. The receiver determines the UDP header offset from the IPv4 Internet Header Length (IHL) field. If the reconstructed IPv4 packet does not contain at least 8 octets starting at that offset, the packet MUST be dropped. The UDP Length field MUST be at least 8 and no larger than the number of octets from the start of the UDP header to the end of the reconstructed IPv4 packet. Rosomakho & Pauly Expires 7 January 2027 [Page 31] Internet-Draft HTTP Datagram Compression July 2026 The receiver computes the UDP Checksum over the IPv4 pseudo-header, the UDP header, and the UDP payload, with the UDP Checksum field treated as zero for the computation. If the computed checksum value is zero, the receiver writes 0xffff into the UDP Checksum field. Otherwise, the receiver writes the computed value into the UDP Checksum field. 6.9. UDP Checksum over IPv6 The ipv6-udp-checksum field corresponds to the Checksum field of the UDP header defined in [UDP] when UDP is carried over IPv6. The field location is: +==========+=================================+========+ | Field | Offset from start of UDP header | Length | +==========+=================================+========+ | Checksum | 6 | 2 | +----------+---------------------------------+--------+ Table 9 6.9.1. Sender Behavior When using this Derived Field Type, the sender removes the UDP Checksum field from the datagram payload. The sender MUST only use this Derived Field Type for packets whose IPv6 header can be located according to the rules in Section 6. The sender MUST verify that the first four bits of the located IP header contain the IPv6 version value 6 before using this Derived Field Type. The sender MUST locate the UDP header by traversing the IPv6 Next Header chain starting from the fixed IPv6 header. The sender MUST NOT use this Derived Field Type for a packet if this traversal does not identify a UDP header, if the UDP header is not fully contained in the IPv6 packet, or if the traversal encounters an IPv6 Fragment header before reaching the UDP header. The sender MUST verify that the UDP Length field is at least 8 and no larger than the number of octets from the start of the UDP header to the end of the IPv6 packet. The sender MUST verify that the value of the UDP Checksum field in the original packet is equal to the Internet checksum computed over the IPv6 pseudo-header, the UDP header, and the UDP payload, with the UDP Checksum field treated as zero for the computation. If the Rosomakho & Pauly Expires 7 January 2027 [Page 32] Internet-Draft HTTP Datagram Compression July 2026 computed checksum value is zero, the value to be compared is 0xffff. If the value does not match, the sender MUST NOT use this Derived Field Type for that packet. 6.9.2. Receiver Behavior The receiver locates the IPv6 header according to the rules in Section 6. The first four bits of the header MUST contain the IPv6 version value 6. The receiver locates the UDP header by traversing the IPv6 Next Header chain starting from the fixed IPv6 header. If traversal does not identify a UDP header, if traversal encounters an IPv6 Fragment header before reaching the UDP header, or if the reconstructed IPv6 packet does not contain a complete UDP header at the resulting offset, the packet MUST be dropped. The UDP Length field MUST be at least 8 and no larger than the number of octets from the start of the UDP header to the end of the reconstructed IPv6 packet. The receiver computes the UDP Checksum over the IPv6 pseudo-header, the UDP header, and the UDP payload, with the UDP Checksum field treated as zero for the computation. If the computed checksum value is zero, the receiver writes 0xffff into the UDP Checksum field. Otherwise, the receiver writes the computed value into the UDP Checksum field. 6.10. Ethernet Frame Check Sequence The ethernet-fcs field corresponds to the Frame Check Sequence (FCS) field of the Ethernet frame defined in [IEEE802.3]. This Derived Field Type applies only to CONNECT-ETHERNET. The field location is: +=============+=====================================+========+ | Field | Offset from start of Ethernet frame | Length | +=============+=====================================+========+ | Frame Check | Final 4 octets of frame | 4 | | Sequence | | | +-------------+-------------------------------------+--------+ Table 10 Rosomakho & Pauly Expires 7 January 2027 [Page 33] Internet-Draft HTTP Datagram Compression July 2026 6.10.1. Sender behavior When using this Derived Field Type, the sender removes the Ethernet Frame Check Sequence field from the datagram payload. The sender MUST only use this Derived Field Type for Ethernet frames that contain an FCS field. The sender MUST verify that the original Ethernet frame is long enough to contain the Destination MAC Address, Source MAC Address, EtherType or length field, and FCS field before using this Derived Field Type. The sender MUST verify that the value of the FCS field in the original Ethernet frame is equal to the Ethernet Frame Check Sequence computed over the frame starting at the Destination MAC Address field and ending immediately before the FCS field. If the value does not match, the sender MUST NOT use this Derived Field Type for that frame. 6.10.2. Receiver Behavior The receiver verifies that the reconstructed Ethernet frame is long enough to contain the Destination MAC Address, Source MAC Address, EtherType or length field, and FCS field. If the reconstructed frame is too short, the datagram MUST be dropped. The receiver computes the Ethernet Frame Check Sequence over the reconstructed Ethernet frame starting at the Destination MAC Address field and ending immediately before the FCS field. The receiver writes the computed value into the Ethernet Frame Check Sequence field. 7. Examples This section illustrates how contexts are created and how senders form compact payloads. All offsets and lengths are in bits in the packet diagrams and field tables. All offsets and lengths are in bytes in segment tables and sample capsules. The examples below are illustrative. Implementations are expected to follow Section 5.1.5 and select static and variable fields based on the traffic being carried and the stability of those fields in the relevant deployment. Rosomakho & Pauly Expires 7 January 2027 [Page 34] Internet-Draft HTTP Datagram Compression July 2026 7.1. CONNECT-IP: TCP over IPv6 with template, derived fields and checksum offload Original sample [TCP] over [IPv6] packet layout is illustrated below. In addition to basic IPv6 and TCP headers it contains Timestamp option as defined in Section 3 of [TCP-PERF]. This packet is to be transmitted from the client to the proxy over CONNECT-IP. Rosomakho & Pauly Expires 7 January 2027 [Page 35] Internet-Draft HTTP Datagram Compression July 2026 |0 7|8 15|16 23|16 31| +--------+-------+-------+--------+----------------+----------------+ |0 1 1 0 | 0x00 | 0x4bcde | ^ |Version | Traffic Class | Flow Label | | +--------+---------------+--------+----------------+----------------+ | | 0x0020 | 0x06 | 0x79 | I | Payload length | Next header | Hop limit | P +---------------------------------+----------------+----------------+ | | H | 2001:0db8:85a3:0000:0000:8a2e:0370:7334 | E | Source Address | A | | D +-------------------------------------------------------------------+ E | | R | 2001:0db8:a42b:0000:0000:7c3a:143a:1529 | | | Destination Address | | | | v +---------------------------------+---------------------------------+ | 0x0050 | 0xd475 | ^ | Source port | Destination port | | +---------------------------------+---------------------------------+ | | 0x6caa4bd7 | | | Sequence number | | +-------------------------------------------------------------------+ | | 0x9b16794e | T | Acknowledgment number | C +--------+------------------------+---------------------------------+ P |1 0 0 0 |0 0 0 0 0 0 0 1 0 0 0 0 | 0x041e | |Hdr Len | TCP Flags | Window | H +--------+------------------------+---------------------------------+ E | 0x8f6b | 0x0000 | A | Checksum | Urgent Pointer | D +----------------+----------------+----------------+----------------+ E | 0x01 | 0x01 | 0x08 | 0x0a | R | No-Op Option | No-Op Option |TimeStamp Option| Length | | +----------------+----------------+----------------+----------------+ | | 0x119a5db3 | | | Timestamp value | | +-------------------------------------------------------------------+ | | 0xd9b4d48d | | | Timestamp echo reply | v +-------------------------------------------------------------------+ Figure 14: Example TCP over IPv6 packet before optimization Rosomakho & Pauly Expires 7 January 2027 [Page 36] Internet-Draft HTTP Datagram Compression July 2026 This example assumes that the peer supports templates with at least two segments per template, IPv6 payload length derived field and checksum offloading. These capabilities were communicated using the following http-datagram-contexts HTTP field in proxy response confirming CONNECT-IP extended CONNECT. http-datagram-contexts = max-templates=1, max-templates-segments=2, derived=(1), checksum=?1, mtu=1500 Figure 15: http-datagram-contexts response example Since the proxy does not support TCP checksum derivation, but it supports checksum offloading, the client calculates checksum of IPv6 pseudo-header and places it in the TCP checksum field. Context for the offloaded checksum is defined using the CHECKSUM_ASSIGN capsule: CHECKSUM_ASSIGN Capsule { Type (i) = 0x3ee31445, Length (i) = 4, Context ID (i) = 2, Next Context ID (i) = 0, Checksum Field Offset (i) = 56, Checksum Start Offset (i) = 40, } Figure 16: CHECKSUM_ASSIGN Capsule for example IPv6/TCP packet Payload length field in IPv6 header can derived by the peer, so it is removed before calculating static segments. Resulting context for the derived field is defined using DERIVED_ASSIGN capsule: DERIVED_ASSIGN Capsule { Type (i) = 0x3ee31442, Length (i) = 3, Context ID (i) = 4, Next Context ID (i) = 2, Derived Field Type (i) = 1 } Figure 17: DERIVED_ASSIGN Capsule for example IPv6/TCP packet The table below illustrates fields present in IPv6 and TCP headers after derived field was removed, their offsets in bits from the beginning of the packet and whether they are likely to be static for most packets of a given traffic flow Rosomakho & Pauly Expires 7 January 2027 [Page 37] Internet-Draft HTTP Datagram Compression July 2026 +======+===============+======+==============================+======+ |Offset|Field name |Length|Value |Static| +======+===============+======+==============================+======+ |0 |Version |4 |0110b |Yes | +------+---------------+------+------------------------------+------+ |4 |Traffic Class |8 |0x00 |Yes | +------+---------------+------+------------------------------+------+ |12 |Flow label |20 |0x4bcde |Yes | +------+---------------+------+------------------------------+------+ |32 |Next header |8 |0x06 |Yes | +------+---------------+------+------------------------------+------+ |40 |Hop limit |8 |0x79 |Yes | +------+---------------+------+------------------------------+------+ |48 |Source address |128 |2001:0db8:85a3::8a2e:0370:7334|Yes | +------+---------------+------+------------------------------+------+ |176 |Destination |128 |2001:0db8:a42b::7c3a:143a:1529|Yes | | |address | | | | +------+---------------+------+------------------------------+------+ |304 |Source port |16 |0x0050 |Yes | +------+---------------+------+------------------------------+------+ |320 |Destination |16 |0xd475 |Yes | | |port | | | | +------+---------------+------+------------------------------+------+ |336 |Sequence number|32 |0x6caa4bd7 |No | +------+---------------+------+------------------------------+------+ |368 |Acknowledgement|32 |0x9b16794e |No | | |number | | | | +------+---------------+------+------------------------------+------+ |400 |TCP header |4 |1000b |Yes | | |length | | | | +------+---------------+------+------------------------------+------+ |404 |TCP Flags |12 |000000010000b |No | +------+---------------+------+------------------------------+------+ |416 |Window |16 |0x041e |No | +------+---------------+------+------------------------------+------+ |432 |Checksum |16 |0x8f6b |No | +------+---------------+------+------------------------------+------+ |448 |Urgent pointer |16 |0x0000 |Yes | +------+---------------+------+------------------------------+------+ |464 |No-Op option |8 |0x01 |Yes | +------+---------------+------+------------------------------+------+ |472 |No-Op option |8 |0x01 |Yes | +------+---------------+------+------------------------------+------+ |480 |Timestamp |8 |0x08 |Yes | | |option | | | | +------+---------------+------+------------------------------+------+ |488 |Timestamp |8 |0x0a |Yes | | |option length | | | | Rosomakho & Pauly Expires 7 January 2027 [Page 38] Internet-Draft HTTP Datagram Compression July 2026 +------+---------------+------+------------------------------+------+ |496 |Timestamp value|32 |0x119a5db3 |No | +------+---------------+------+------------------------------+------+ |528 |Timestamp echo |32 |0xd9b4d48d |No | | |reply | | | | +------+---------------+------+------------------------------+------+ Table 11: IPv6 and TCP header fields in example packet Static segments model the invariant parts except for the isolated 4-bit TCP header length. Resulting static segments: +=========+=========+===============+===============================+ | Segment | Segment | Segment | Segment Payload | | Offset | Length | Contents | | +=========+=========+===============+===============================+ | 0 | 42 | Version, | 0x6004bcde067920010db885a3... | | | | Traffic | | | | | Class, Flow | | | | | Label, Next | | | | | header, Hop | | | | | limit, | | | | | Source | | | | | address, | | | | | Destination | | | | | address, | | | | | Source port, | | | | | Destination | | | | | port | | +---------+---------+---------------+-------------------------------+ | 56 | 6 | Urgent | 0x00000101080a | | | | pointer, 2 | | | | | No-Op TCP | | | | | options, | | | | | Timestamp | | | | | option code | | | | | and length | | +---------+---------+---------------+-------------------------------+ Table 12: Static segments for example IPv6/TCP packet Resulting TEMPLATE_ASSIGN capsule with client-allocated even context id is illustrated below: Rosomakho & Pauly Expires 7 January 2027 [Page 39] Internet-Draft HTTP Datagram Compression July 2026 TEMPLATE_ASSIGN Capsule { Type (i) = 0x3ee3143f, Length (i) = 54, Context ID (i) = 6, Next Context ID (i) = 4, Static Segment { Segment Offset (i) = 0, Segment Length (i) = 42, Segment Payload = 0x6004bcde067920010db885a3000000008a2e0370733420010db8a42b000000007c3a143a15290050d475, }, Static Segment { Segment Offset (i) = 56, Segment Length (i) = 6, Segment Payload = 0x00000101080a, } } Figure 18: TEMPLATE_ASSIGN Capsule for example IPv6/TCP packet The resulting processing context chain reduces per-packet overhead by removing 50 bytes of repeated header material, increasing the effective MTU when datagrams are encapsulated in QUIC DATAGRAM frames. The sender concatenates all variable regions in increasing offset order. Packets that do not match this template (for example packets with IPv6 extension headers or without TCP options) are sent using Context ID 0 or associated with a new context. Upon receiving the datagram with Context ID 6, proxy re-assembles the datagram by concatenating static and variable segments according to the offsets, re-calculates Payload Length and inserts it into IPv6 header and completes the TCP checksum using the sender-provided pseudo-header partial checksum. 7.2. CONNECT-ETHERNET: UDP over IPv4 with template and derived fields Original sample [UDP] over [IPv4] Ethernet frame layout is illustrated below. This frame is to be transmitted from the proxy to the client over CONNECT-ETHERNET. Rosomakho & Pauly Expires 7 January 2027 [Page 40] Internet-Draft HTTP Datagram Compression July 2026 |0 7|8 15|16 23|24 31|32 39|40 47| +--------+--------+--------+--------+--------+--------+ | Destination MAC address | | 00:00:5E:00:53:01 | +--------+--------+--------+--------+--------+--------+ | Source MAC address | | 00:00:5E:00:53:02 | +--------+--------+--------+--------+--------+--------+ | 0x0800 | | EtherType | ETHERNET HEADER +-----------------+ |0 7|8 15|16 23|16 31| +--------+-------+----------------+----------------+----------------+ |0 1 0 0 |0 1 0 1| 0x02 | 0x04cc | ^ |Version |Hdr Len| Traffic Class | Total length | | +--------+-------+----------------+------+--------------------------+ I | 0x0000 |0 1 0 |0 0 0 0 0 0 0 0 0 0 0 0 0 | P | Identification |Flags | Fragment offset | +----------------+----------------+------+--------------------------+ H | 0x40 | 0x11 | 0xb21b | E | TTL | Protocol | Header checksum | A +----------------+----------------+---------------------------------+ D | 192.0.2.1 | E | Source Address | R +-------------------------------------------------------------------+ | | 192.0.2.2 | | | Destination Address | v +---------------------------------+---------------------------------+ | 0xc199 | 0x1151 | ^ | Source port | Destination port | | +---------------------------------+---------------------------------+ | | 0x04b8 | 0x72de | U | Length | Checksum | D +---------------------------------+---------------------------------+ P | | | | UDP payload (1200 bytes) | | | ... | v Figure 19: Example UDP over IPv4 Ethernet frame before optimization This example assumes that the peer supports templates, IPv4 total length, IPv4 header checksum, UDP length in IPv4 packet and UDP checksum in IPv4 packet derived field. These capabilities were communicated using the following http-datagram-contexts HTTP field in client requesting CONNECT-ETHERNET extended CONNECT. http-datagram-contexts = max-templates=1, max-templates-segments=1, derived=(0 2 4 7), mtu=1500 Rosomakho & Pauly Expires 7 January 2027 [Page 41] Internet-Draft HTTP Datagram Compression July 2026 Figure 20: http-datagram-contexts request example Total length and header checksum in IPv4 header as well as length and checksum in UDP header can be derived by the peer, so these fields are removed before calculating static segments. Resulting context for the derived field is defined using DERIVED_ASSIGN capsule: DERIVED_ASSIGN Capsule { Type (i) = 0x3ee31442, Length (i) = 6, Context ID (i) = 1, Next Context ID (i) = 0, Derived Field Type (i) = 0 Derived Field Type (i) = 2 Derived Field Type (i) = 4 Derived Field Type (i) = 7 } Figure 21: DERIVED_ASSIGN Capsule for example IPv4/UDP ethernet frame Table below illustrates fields present in Ethernet, IPv4 and UDP headers after derived fields were removed, their offsets in bits from the beginning of the frame and if they are likely to be static for most packets of a given traffic flow Rosomakho & Pauly Expires 7 January 2027 [Page 42] Internet-Draft HTTP Datagram Compression July 2026 +========+================+========+===================+========+ | Offset | Field name | Length | Value | Static | +========+================+========+===================+========+ | 0 | Destination | 48 | 00:00:5E:00:53:01 | Yes | | | MAC address | | | | +--------+----------------+--------+-------------------+--------+ | 48 | Source MAC | 48 | 00:00:5E:00:53:02 | Yes | | | address | | | | +--------+----------------+--------+-------------------+--------+ | 96 | EtherType | 16 | 0x0800 | Yes | +--------+----------------+--------+-------------------+--------+ | 112 | Version | 4 | 0100b | Yes | +--------+----------------+--------+-------------------+--------+ | 116 | Header length | 4 | 0101b | Yes | +--------+----------------+--------+-------------------+--------+ | 120 | Traffic Class | 8 | 0x02 | Yes | +--------+----------------+--------+-------------------+--------+ | 128 | Identification | 16 | 0x0000 | Yes | +--------+----------------+--------+-------------------+--------+ | 144 | Flags | 3 | 010b | Yes | +--------+----------------+--------+-------------------+--------+ | 147 | Fragment | 13 | 0000000000000b | Yes | | | offset | | | | +--------+----------------+--------+-------------------+--------+ | 160 | TTL | 8 | 0x40 | Yes | +--------+----------------+--------+-------------------+--------+ | 168 | Protocol | 8 | 0x11 | Yes | +--------+----------------+--------+-------------------+--------+ | 176 | Source address | 32 | 192.0.2.1 | Yes | +--------+----------------+--------+-------------------+--------+ | 208 | Destination | 32 | 192.0.2.2 | Yes | | | address | | | | +--------+----------------+--------+-------------------+--------+ | 240 | Source port | 16 | 0xc199 | Yes | +--------+----------------+--------+-------------------+--------+ | 256 | Destination | 16 | 0x1151 | Yes | | | port | | | | +--------+----------------+--------+-------------------+--------+ | 272 | UDP payload | 9600 | ... | No | +--------+----------------+--------+-------------------+--------+ Table 13: Ethernet, IPv4 and UDP header fields in example frame A single static segment model can be used for the initial part of the HTTP datagram after derived fields were removed: Rosomakho & Pauly Expires 7 January 2027 [Page 43] Internet-Draft HTTP Datagram Compression July 2026 +=======+=======+===============+======================================================================+ |Segment|Segment|Segment |Segment Payload | |Offset |Length |Contents | | +=======+=======+===============+======================================================================+ |0 |34 |Source MAC |0x00005E00530100005E00530208004502000040004011c0000201c0000202c1991151| | | |address, | | | | |Destination MAC| | | | |address, | | | | |EtherType, | | | | |Version, Header| | | | |length and | | | | |Traffic Class, | | | | |Identification,| | | | |Flags, Fragment| | | | |offset, TTL, | | | | |Protocol, | | | | |Source address,| | | | |Destination | | | | |address, Source| | | | |port and | | | | |Destination | | | | |port | | +-------+-------+---------------+----------------------------------------------------------------------+ Table 14: Static segment for example Ethernet/IPv4/UDP frame Resulting TEMPLATE_ASSIGN capsule with proxy-allocated odd Context ID is illustrated below: TEMPLATE_ASSIGN Capsule { Type (i) = 0x3ee3143f, Length (i) = 38, Context ID (i) = 3, Next Context ID (i) = 1, Static Segment { Segment Offset (i) = 0, Segment Length (i) = 34, Segment Payload = 0x00005E00530100005E00530208004502000040004011c0000201c0000202c1991151, } } Figure 22: TEMPLATE_ASSIGN Capsule for example IPv4/UDP ethernet frame The resulting processing context chain reduces per-frame overhead by removing 34 bytes of repeated header material, increasing the effective MTU when datagrams are encapsulated in QUIC DATAGRAM frames. Rosomakho & Pauly Expires 7 January 2027 [Page 44] Internet-Draft HTTP Datagram Compression July 2026 The sender concatenates all variable regions in increasing offset order. Upon receiving the datagram with Context ID 3, client re-assembles the datagram by appending variable segments to the static, re- calculates derived fields and inserts them at appropriate locations in the datagram. 8. Security Considerations This specification changes how HTTP Datagrams are reconstructed but does not weaken transport-layer integrity or confidentiality protections provided by the underlying HTTP mapping. All Capsules travel on the reliable control stream and inherit those protections. 8.1. Resource Exhaustion Processing contexts introduce receiver state and reconstruction work. An attacker could attempt to exhaust memory or CPU by creating excessive numbers of templates and static segments, purposely sending datagrams referencing not-yet-installed contexts and causing excessive buffering of unknown Context IDs. Implementations MUST enforce limits on number of active templates and static segments and restrict memory used for buffering datagrams with unknown contexts. 8.2. Amplification Derived fields and template reconstruction increase the size of the reconstructed packet relative to the received datagram payload. An attacker could exploit this to amplify processing cost and perform a denial-of-service attack. Endpoints MUST ensure that reconstructed packet size does not exceed the negotiated MTU and SHOULD apply rate limiting when expansion ratios are abnormally high. 9. IANA Considerations 9.1. HTTP Capsule Types Registration This specification registers the following values in the "HTTP Capsule Types" registry: Rosomakho & Pauly Expires 7 January 2027 [Page 45] Internet-Draft HTTP Datagram Compression July 2026 +============+=================+ | Value | Capsule Type | +============+=================+ | 0x3ee3143f | TEMPLATE_ASSIGN | +------------+-----------------+ | 0x3ee31440 | TEMPLATE_ACK | +------------+-----------------+ | 0x3ee31441 | TEMPLATE_CLOSE | +------------+-----------------+ | 0x3ee31442 | DERIVED_ASSIGN | +------------+-----------------+ | 0x3ee31443 | DERIVED_ACK | +------------+-----------------+ | 0x3ee31444 | DERIVED_CLOSE | +------------+-----------------+ | 0x3ee31445 | CHECKSUM_ASSIGN | +------------+-----------------+ | 0x3ee31446 | CHECKSUM_ACK | +------------+-----------------+ | 0x3ee31447 | CHECKSUM_CLOSE | +------------+-----------------+ Table 15 All of these new entries use the following values for these fields: Status: provisional (permanent if this document is approved) Reference: This document Change Controller: IETF Contact: MASQUE Working Group masque@ietf.org Notes: None 9.2. HTTP Field Name Registration This specification registers the following value in the "HTTP Field Name" registry: * Field Name: http-datagram-contexts * Status: provisional (permanent if approved) * Structured Type: Dictionary * Reference: This document Rosomakho & Pauly Expires 7 January 2027 [Page 46] Internet-Draft HTTP Datagram Compression July 2026 * Comments: None 9.3. HTTP Datagram Derived Field Types Registry IANA is requested to create a new registry titled "HTTP Datagram Derived Field Types". The registration policy is expert review as specified in Section 4.5 of [IANA-POLICY]. This new registry governs the Derived Field types that appear in DERIVED_ASSIGN capsule and derived list of http-datagram-contexts dictionary. Registrations are expected to reference a specification that defines how the field is derived. Such specifications are expected to describe the sender behavior and receiver behavior for the Derived Field Type, including how the relevant packet or frame header is located, the offset and length of the field, how the field value is computed, and any conditions under which the Derived Field Type is not applicable. This new registry contains five columns: Type: A positive integer identifying the field type Name: A short name of the field Description: A description of the field Protocols: A list of HTTP Upgrade Tokens that the derived field type can apply Reference: An optional reference defining the use of the entry. The registry's initial entries are as follows: +====+====================+==============+================+=========+ |Type|Name |Description |Protocols |Reference| +====+====================+==============+================+=========+ |0 |ipv4-total-length |IPv4 Total |connect-ip, |This | | | |Length field |connect-ethernet|document | | | |derived from | | | | | |reconstructed | | | | | |packet size | | | +----+--------------------+--------------+----------------+---------+ |1 |ipv6-payload-length |IPv6 Payload |connect-ip, |This | | | |Length field |connect-ethernet|document | | | |derived from | | | | | |reconstructed | | | | | |packet size | | | +----+--------------------+--------------+----------------+---------+ Rosomakho & Pauly Expires 7 January 2027 [Page 47] Internet-Draft HTTP Datagram Compression July 2026 |2 |ipv4-udp-length |UDP Length |connect-ip, |This | | | |derived from |connect-ethernet|document | | | |UDP header to | | | | | |end of IPv4 | | | | | |packet | | | +----+--------------------+--------------+----------------+---------+ |3 |ipv6-udp-length |UDP Length |connect-ip, |This | | | |derived from |connect-ethernet|document | | | |UDP header to | | | | | |end of IPv6 | | | | | |packet | | | +----+--------------------+--------------+----------------+---------+ |4 |ipv4-header-checksum|IPv4 header |connect-ip, |This | | | |checksum |connect-ethernet|document | | | |computed over | | | | | |IPv4 header | | | +----+--------------------+--------------+----------------+---------+ |5 |ipv4-tcp-checksum |TCP checksum |connect-ip, |This | | | |computed over |connect-ethernet|document | | | |IPv4 pseudo- | | | | | |header and | | | | | |segment | | | +----+--------------------+--------------+----------------+---------+ |6 |ipv6-tcp-checksum |TCP checksum |connect-ip, |This | | | |computed over |connect-ethernet|document | | | |IPv6 pseudo- | | | | | |header and | | | | | |segment | | | +----+--------------------+--------------+----------------+---------+ |7 |ipv4-udp-checksum |UDP checksum |connect-ip, |This | | | |computed over |connect-ethernet|document | | | |IPv4 pseudo- | | | | | |header and | | | | | |segment | | | +----+--------------------+--------------+----------------+---------+ |8 |ipv6-udp-checksum |UDP checksum |connect-ip, |This | | | |computed over |connect-ethernet|document | | | |IPv6 pseudo- | | | | | |header and | | | | | |segment | | | +----+--------------------+--------------+----------------+---------+ |9 |ethernet-fcs |Ethernet |connect-ethernet|This | | | |Frame Check | |document | | | |Sequence | | | | | |computed over | | | | | |the | | | | | |reconstructed | | | | | |Ethernet | | | Rosomakho & Pauly Expires 7 January 2027 [Page 48] Internet-Draft HTTP Datagram Compression July 2026 | | |frame | | | +----+--------------------+--------------+----------------+---------+ Table 16 10. References 10.1. Normative References [CONNECT-ETHERNET] Sedeño, A., "Proxying Ethernet Frames in HTTP", Work in Progress, Internet-Draft, draft-ietf-masque-connect- ethernet-10, 30 June 2026, . [CONNECT-IP] Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A., Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP", RFC 9484, DOI 10.17487/RFC9484, October 2023, . [CONNECT-UDP] Schinazi, D., "Proxying UDP in HTTP", RFC 9298, DOI 10.17487/RFC9298, August 2022, . [HTTP-DATAGRAMS] Schinazi, D. and L. Pardue, "HTTP Datagrams and the Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August 2022, . [INCREMENTAL-CHECKSUM] Rijsinghani, A., Ed., "Computation of the Internet Checksum via Incremental Update", RFC 1624, DOI 10.17487/RFC1624, May 1994, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Rosomakho & Pauly Expires 7 January 2027 [Page 49] Internet-Draft HTTP Datagram Compression July 2026 [STRUCTURED-HTTP] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, . 10.2. Informative References [IANA-POLICY] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [IEEE802.1Q] "IEEE Standard for Local and Metropolitan Area Networks-- Bridges and Bridged Networks", IEEE, DOI 10.1109/ieeestd.2022.10004498, ISBN ["9781504491884"], December 2022, . [IEEE802.3] "IEEE Standard for Ethernet", IEEE, DOI 10.1109/ieeestd.2022.9844436, ISBN ["9781504487252"], July 2022, . [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [IPv6-JUMBO] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, . [TCP] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . [TCP-PERF] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, . Rosomakho & Pauly Expires 7 January 2027 [Page 50] Internet-Draft HTTP Datagram Compression July 2026 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . Acknowledgments TODO acknowledge. Authors' Addresses Yaroslav Rosomakho Zscaler Email: yrosomakho@zscaler.com Tommy Pauly Apple Email: tpauly@apple.com Rosomakho & Pauly Expires 7 January 2027 [Page 51]