| Internet-Draft | Context Management | July 2026 |
| Corneo & Westerlund | Expires 7 January 2027 | [Page] |
This document defines extensions to the Static Context Header Compression (SCHC) framework that improve context management efficiency. Two categories of mechanisms are introduced: rule referencing CDAs (ref and ref-edit) that enable composable rule definitions and reduce context storage, and a rule fragment branching CDA (branch) with associated Matching Operators that enable dynamic multi-layer protocol compression without combinatorial rule explosion.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-corneo-schc-ctx-mgmt/.¶
Discussion of this document takes place on the Static Context Header Compression Working Group mailing list (mailto:schc@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/schc/. Subscribe at https://www.ietf.org/mailman/listinfo/schc/.¶
Source for this draft and an issue tracker can be found at https://github.com/lorenzocorneo/draft-corneo-schc-ctx-mgmt.¶
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 (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.¶
Static Context Header Compression (SCHC), defined in [RFC8724], provides a mechanism for compressing protocol headers over constrained networks by defining rules in a context shared between sender and receiver.¶
SCHC was initially designed for low-power wide-area networks serving a small number of devices with small, static contexts. As the framework evolved to support scalable deployments, diverse technologies (cellular traffic, space communication), and multi-layer protocol stacks, several limitations emerged:¶
As the number and heterogeneity of devices increase, the context size grows. Dynamic approaches such as payload compression further increase the number of rules, potentially adding duplicate or partially duplicate field descriptions. Context updates become frequent, increasing protocol overhead and energy consumption.¶
As the rule set grows, rule matching time increases, potentially creating bottlenecks and additional latency.¶
Compressing multiple protocol layers (e.g., IPv6/UDP/RTP) in combined rules forces duplication of lower-layer field descriptions across rules, creating a combinatorial explosion. Supporting N variants of IPv6 addresses with M upper-layer protocols requires N*M rules.¶
Protocols with variable or optional headers (e.g., IPv6 extension headers) cannot be efficiently compressed, as each combination requires its own rule.¶
This document addresses these limitations by defining:¶
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:¶
A set of field descriptions within one rule that belong to a single protocol layer.¶
A rule (or subset of a rule) that has been selected to be merged into a new rule using referencing CDAs.¶
A rule that includes at least one of the referencing CDAs defined in this document.¶
A rule designed to compress a portion of a packet (e.g., a single protocol layer) and intended to be composed with other rule fragments via branching.¶
This section defines two novel Compression/Decompression Actions (CDAs) that enable SCHC rules to reference other rules in the context. These CDAs reduce context storage requirements and enable composable rule definitions.¶
The "ref" CDA references an existing rule within the SCHC context. When a field description uses ref(N), the compressor/decompressor MUST suspend processing of the current rule and apply Rule N to the corresponding portion of the packet. Once Rule N has been fully processed, the compressor/decompressor MUST resume processing the next field description in the original rule.¶
The argument N is the Rule ID of the referenced rule.¶
When ref(N) is used, the Target Value (TV) and Field Length (FL) fields in the referencing field description are not used for compression. Instead, the TVs and FLs of the referenced Rule N apply.¶
The following example illustrates the use of ref(N). Consider a dedicated IPv6 compression rule (Rule 2):¶
Rule 2 +----------------+--+--+--+---------+--------+------------+ | FID |FL|FP|DI| TV | MO | CDA | +----------------+--+--+--+---------+--------+------------+ |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent | |IPv6 Diffserv |8 |1 |Bi|0 | equal | not-sent | |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent | |IPv6 Length |16|1 |Bi| | ignore | compute-* | |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent | |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent | |IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent | |IPv6 DevIID |64|1 |Bi| | ignore | DevIID | |IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent | |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent | +----------------+--+--+--+---------+--------+------------+
A UDP compression rule can then reference Rule 2 for the IPv6 portion:¶
Rule 3 +--------------+--+--+--+---+-------+------------+ | FID |FL|FP|DI| TV| MO | CDA | +--------------+--+--+--+---+-------+------------+ |IPv6 Rule | |1 |Bi| | ignore| ref(2) | +--------------+--+--+--+---+-------+------------+ |UDP DevPort |16|1 |Dw|123| equal | not-sent | |UDP DevPort |16|1 |Up|124| equal | not-sent | |UDP AppPort |16|1 |Dw|124| equal | not-sent | |UDP AppPort |16|1 |Up|123| equal | not-sent | |UDP Length |16|1 |Bi| | ignore| compute-* | |UDP checksum |16|1 |Bi| | ignore| compute-* | +--------------+--+--+--+---+-------+------------+
Similarly, a TCP compression rule can reuse the same IPv6 rule. However, since Rule 2 specifies Next Header = 17 (UDP) with MO = equal, a TCP rule cannot use ref(2) directly — the Next Header value would fail to match TCP packets (Next Header = 6). Instead, Rule 4 uses ref-edit(2,1) to override the Next Header field description, demonstrating why ref-edit is necessary when a referenced rule contains a field value that differs for the referencing protocol:¶
Rule 4 +-----------------+--+--+--+---+-------+--------------+ | FID |FL|FP|DI| TV| MO | CDA | +-----------------+--+--+--+---+-------+--------------+ |IPv6 Rule | |1 |Bi| | ignore| ref-edit(2,1)| |IPv6 Next Header |8 |1 |Bi|6 | equal | not-sent | +-----------------+--+--+--+---+-------+--------------+ |TCP DevPort |16|1 |Dw|321| equal | not-sent | |TCP DevPort |16|1 |Up|421| equal | not-sent | |TCP AppPort |16|1 |Dw|421| equal | not-sent | |TCP AppPort |16|1 |Up|321| equal | not-sent | |TCP Length |16|1 |Bi| | ignore| compute-* | |TCP checksum |16|1 |Bi| | ignore| compute-* | +-----------------+--+--+--+---+-------+--------------+
In both cases, when the compressor/decompressor encounters a referencing CDA, it loads Rule 2 and applies it to the IPv6 header portion of the packet before resuming with the transport layer fields. For Rule 4, the ref-edit(2,1) CDA first replaces the IPv6 Next Header field description in Rule 2 with the override (TV = 6), then applies the modified rule.¶
The "ref-edit" CDA extends ref(N) by allowing modification of specific field descriptions in the referenced rule. The argument N is the Rule ID of the referenced rule, and M indicates the number of field descriptions immediately following the ref-edit field that specify modifications.¶
When processing ref-edit(N,M), the compressor/decompressor MUST:¶
Load the referenced Rule N.¶
For each of the next M field descriptions in the current rule, find the field description in Rule N with a matching Field ID (FID).¶
Replace the matched field description in Rule N with the one from the current rule.¶
Apply the modified Rule N to the packet.¶
The following example modifies the AppIID field from Rule 2:¶
+--------------+---+--+--+---------+--------+--------------+ | FID |FL |FP|DI| TV | MO | CDA | +--------------+---+--+--+---------+--------+--------------+ |IPv6 Rule | |1 |Bi| | ignore | ref-edit(2,1)| |IPv6 AppIID |64 |1 |Bi| ::3 | equal | not-sent | +--------------+---+--+--+---------+--------+--------------+
Here, the decompressor loads Rule 2, locates the IPv6 AppIID field description, replaces its TV with ::3, and then applies the modified rule.¶
The ref(N) and ref-edit(N,M) CDAs enable context compression procedures that merge rules sharing common field descriptions. One way to realize this is a procedure that operates as follows:¶
Iterate all rules in the context. For each rule, identify sets of adjacent field descriptions (field descriptions belonging to the same protocol layer).¶
Group identical sets of adjacent field descriptions that appear in multiple rules.¶
For each group exceeding a configured threshold of occurrences: a. Create a new rule containing the shared adjacent field descriptions. b. For each original rule containing the group, create a merged rule that uses ref(N) to reference the new rule, plus any remaining field descriptions.¶
Signal the new rules to all SCHC endpoints. Once confirmed, deprecated rules MAY be removed from the context.¶
This section defines a novel Compression/Decompression Action (CDA) and a novel Matching Operator (MO) that enable dynamic composition of SCHC rule fragments at compression time. These mechanisms allow a single rule to branch into different rule fragments based on packet content, solving the combinatorial explosion problem when compressing multi-layer protocol stacks or protocols with optional/variable headers.¶
The "branch" CDA encodes a selection among alternative rule fragments into the compression residual. branch takes as argument either a Rule ID identifying the next rule fragment to apply, or NULL indicating that no further rule processing follows.¶
A field description using branch contains a mapping table where each entry associates:¶
A Target Value (TV)¶
A Rule ID (or NULL) to apply next¶
A residual value to encode in the compressed packet¶
The number of bits in the residual is determined by the number of entries in the mapping table.¶
When the compressor encounters a field with branch CDA, it MUST:¶
Encode the residual value corresponding to the matched entry.¶
Queue the associated Rule ID for subsequent processing.¶
When the decompressor encounters a branch residual, it MUST:¶
Decode the residual to determine the index into the mapping table.¶
Use the corresponding Rule ID to decompress the next portion of the packet.¶
A branch to NULL indicates that no further rule processing follows after the current rule completes.¶
Two mechanisms determine which branch to take:¶
Explicit field matching (match-mapping MO, see Section 5.2): Used when a protocol header field directly indicates what follows. For example, the IPv6 Next Header field value 17 explicitly identifies UDP as the next protocol. This also applies to IPv6 extension headers (Fragment, Destination Options, Hop-by-Hop), each of which carries its own Next Header field — enabling a chain of branch decisions through successive extension headers until the transport layer is reached. The branch selection is encoded as a residual derived from matching the field value against a mapping table.¶
Implicit matching (match-rule MO, see Section 5.3): Used when no single header field identifies what follows. For example, after a UDP header, there is no field indicating whether the payload is RTP, CoAP, or something else. The compressor must attempt to match each candidate rule against the payload content — for instance, checking whether the payload starts with RTP version = 2 and valid SSRC fields. The branch selection is encoded as a residual indicating which rule succeeded.¶
The Field Length (FL) value of a field description using branch determines its usage:¶
FL > 0: The field corresponds to an actual packet header field of the indicated length. The branch is determined by the field value present in the packet (used with match-mapping MO).¶
FL = 0: There is no corresponding field in the packet. The branch residual encodes which rule fragment is used to compress the remainder of the packet after the current rule completes. This is used when the next protocol is implicit (used with match-rule MO).¶
When a rule contains multiple field descriptions with branch CDA, the Field Position (FP) determines the invocation order. Rule fragments are processed depth-first: a loaded rule fragment, including any branch within it, MUST be fully processed before the next queued branch from the parent rule is invoked.¶
Specifically, the compressor maintains a branch queue per rule. After completing all CDAs in the current rule, the compressor processes the queue starting with the lowest invocation number. Each dequeued Rule ID is loaded and its matching and compression operations are performed. The packet pointer (Current_Location) advances as each rule fragment is processed.¶
This sequential processing imposes a constraint on rule fragment design: rule fragments MUST be split at protocol boundaries where different subsequent processing of the packet can occur. A branch decision point can only appear at a location where the preceding fields have been fully compressed by the current rule fragment. Placing a branch mid-way through a protocol header is not supported, as the queue processes complete rule fragments in order.¶
If a loaded rule fragment fails to match the packet at the current location, the entire compression operation for this packet MUST fail. The compressor MUST transmit the packet uncompressed (using Rule ID 0).¶
A branch to NULL terminates further processing, even if there are queued invocations in parent rules.¶
As a consequence, when the packet content following a branch point may be unknown or not covered by any rule fragment, the branch mapping SHOULD include a branch(NULL) entry as a fallback. Without it, an unrecognized field value (in match-mapping) or a payload matching no candidate rule (in match-rule) will cause complete compression failure. Including branch(NULL) allows the compressor to gracefully terminate rule processing at that point, leaving the remainder of the packet uncompressed in the SCHC residual.¶
When branch is used with a non-zero FL, the existing match-mapping MO (defined in [RFC8724]) is used to determine which branch to take. The TV field contains an array of values. The MO matches when the packet field value equals one of the TV entries, and the index of the matching entry selects the corresponding branch argument.¶
The following example shows an IPv6 rule using match-mapping with branch on the Next Header field:¶
Rule 2 +----------------+--+--+--+---------+--------+--------------+------+ | FID |FL|FP|DI| TV | MO | CDA | Sent | +----------------+--+--+--+---------+--------+--------------+------+ |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent | | |IPv6 Diffserv |8 |1 |Bi|0 | equal | not-sent | | |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent | | |IPv6 Length |16|1 |Bi| | ignore | compute-* | | |IPv6 Next Header|8 |1 |Bi|17 | mapping| branch(3) |0b000 | | | | | |6 | mapping| branch(4) |0b001 | | | | | |44 | mapping| branch(5) |0b010 | | | | | |60 | mapping| branch(6) |0b011 | | | | | |41 | mapping| branch(7) |0b100 | | | | | |59 | mapping| branch(NULL) |0b101 | |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent | | |IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent | | |IPv6 DevIID |64|1 |Bi| | ignore | DevIID | | |IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent | | |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent | | +----------------+--+--+--+---------+--------+--------------+------+
The mapping table for the Next Header field is:¶
| TV | Next Rule | Residual |
|---|---|---|
| 17 | Rule 3 (UDP) | 0b000 |
| 6 | Rule 4 (TCP) | 0b001 |
| 44 | Rule 5 (Fragment) | 0b010 |
| 60 | Rule 6 (Dest Opts) | 0b011 |
| 41 | Rule 7 (IPv6-in-6) | 0b100 |
| 59 | NULL (No Next Hdr) | 0b101 |
When compressing, if the IPv6 Next Header field contains 17 (UDP), the compressor encodes 0b000 as residual and queues Rule 3 for processing after the current rule completes.¶
The "match-rule" MO is a novel Matching Operator for use with branch when FL = 0 (no corresponding packet field). It determines which rule fragment matches the remainder of the packet by attempting to match each referenced rule in order.¶
The match-rule MO takes a list of Rule IDs as argument. For each referenced Rule ID, in list order, the compressor MUST:¶
Save the current packet location.¶
Load the referenced rule and perform all its matching operations starting at the current location.¶
If all fields match successfully, return the index of this rule.¶
If any field fails to match, reset the packet location and proceed to the next Rule ID in the list.¶
If no rule matches and no NULL entry exists, the match-rule MO fails. If the list contains a NULL entry, it automatically matches when reached. Therefore, a NULL entry SHOULD be placed last in the list; any entries after NULL will never be evaluated.¶
The following example shows match-rule used in a UDP rule to branch into RTP or CoAP compression:¶
Rule 3 +--------------+--+--+--+----+-----------------+--------------+------+ | FID |FL|FP|DI| TV | MO | CDA | Sent | +--------------+--+--+--+----+-----------------+--------------+------+ |UDP.SrcPort |16|1 |Dw|1123| equal | not-sent | | |UDP.SrcPort |16|1 |Up|1124| equal | not-sent | | |UDP.DstPort |16|1 |Dw|1124| equal | not-sent | | |UDP.DstPort |16|1 |Up|1123| equal | not-sent | | |UDP.Length |16|1 |Bi| | ignore | compute-* | | |UDP.checksum |16|1 |Bi| | ignore | compute-* | | |UDP.PayProto |0 |1 |Bi| | match-rule(8) | branch(8) | 0b00 | | | | | | | match-rule(9) | branch(9) | 0b01 | | | | | | | match-rule(NULL)| branch(NULL) | 0b10 | +--------------+--+--+--+----+-----------------+--------------+------+
Here, after compressing the UDP header, the compressor attempts to match Rule 8 (RTP) against the UDP payload. If RTP matching succeeds, 0b00 is encoded and Rule 8 is used. Otherwise, Rule 9 (CoAP) is attempted. If neither matches, the NULL entry matches and no further compression is applied to the payload.¶
The branch CDA and the ref(N) CDA (defined in Section 4) are complementary mechanisms:¶
ref(N) provides static rule composition: the referenced rule is always applied unconditionally.¶
branch provides dynamic rule composition: the referenced rule fragment is selected based on packet content or rule matching at compression time.¶
Both mechanisms MAY be used within the same context. A rule fragment referenced by branch MAY itself contain ref(N) references to other rules.¶
This section provides comprehensive examples demonstrating the mechanisms defined in this document.¶
This example shows how ref(N) and ref-edit(N,M) eliminate duplication when multiple transport protocols share the same IPv6 compression rule.¶
Without referencing CDAs, compressing IPv6/UDP and IPv6/TCP requires two complete rules, each repeating 10 IPv6 field descriptions. With referencing CDAs, a single IPv6 rule (Rule 2 in Figure 1) is defined once and referenced by the UDP rule (Rule 3 in Figure 2) using ref(2), and the TCP rule (Rule 4 in Figure 3) using ref-edit(2,1) to override the Next Header value from 17 to 6.¶
For a context with 3 IPv6 address variants and 4 transport/application protocols, the traditional approach requires 12 rules with 10 duplicated IPv6 field descriptions each (120 total IPv6 field descriptions). Using referencing CDAs, only 3 IPv6 rules plus 4 transport rules are needed (3 + 4 = 7 rules, 30 IPv6 field descriptions).¶
This example demonstrates branch used with match-mapping to handle IPv6 packets with different next headers. Rule 2 in Figure 5 uses the IPv6 Next Header field to branch into different rule fragments for UDP, TCP, IPv6 Fragment Header, Destination Options, and IPv6-in-IPv6 tunneling.¶
The following rule fragments are referenced by the branch entries:¶
Rule 3 +--------------+--+--+--+----+-----------------+--------------+------+ | FID |FL|FP|DI| TV | MO | CDA | Sent | +--------------+--+--+--+----+-----------------+--------------+------+ |UDP.SrcPort |16|1 |Dw|1123| equal | not-sent | | |UDP.SrcPort |16|1 |Up|1124| equal | not-sent | | |UDP.DstPort |16|1 |Dw|1124| equal | not-sent | | |UDP.DstPort |16|1 |Up|1123| equal | not-sent | | |UDP.Length |16|1 |Bi| | ignore | compute-* | | |UDP.checksum |16|1 |Bi| | ignore | compute-* | | |UDP.PayProto |0 |1 |Bi| | match-rule(8) | branch(8) | 0b00 | | | | | | | match-rule(9) | branch(9) | 0b01 | | | | | | | match-rule(NULL)| branch(NULL) | 0b10 | +--------------+--+--+--+----+-----------------+--------------+------+
Rule 3 compresses the UDP header and then uses match-rule to determine whether the payload is RTP (Rule 8), CoAP (Rule 9), or unknown (NULL).¶
Rule 4 +--------------+--+--+--+----+--------+------------+------+ | FID |FL|FP|DI| TV | MO | CDA | Sent | +--------------+--+--+--+----+--------+------------+------+ |TCP.SrcPort |16|1 |Dw|1321| equal | not-sent | | |TCP.SrcPort |16|1 |Up|1421| equal | not-sent | | |TCP.DstPort |16|1 |Dw|1421| equal | not-sent | | |TCP.DstPort |16|1 |Up|1321| equal | not-sent | | |TCP.Length |16|1 |Bi| | ignore | compute-* | | |TCP.checksum |16|1 |Bi| | ignore | compute-* | | +--------------+--+--+--+----+--------+------------+------+
This rule handles the first fragment of a fragmented IPv6 packet. The Next Header field in the fragment header uses branch to determine what protocol follows.¶
Rule 5 +----------------+--+--+--+---+--------+--------------+------+ | FID |FL|FP|DI| TV| MO | CDA | Sent | +----------------+--+--+--+---+--------+--------------+------+ |Frag Next Header|8 |1 |Bi|17 | mapping| branch(3) |0b000 | | | | | | 6 | mapping| branch(4) |0b001 | | | | | |60 | mapping| branch(6) |0b010 | | | | | |41 | mapping| branch(7) |0b011 | | | | | |59 | mapping| branch(NULL) |0b100 | |Frag Reserved |8 |1 |Bi|0 | ignore | not-sent | | |Frag Offset |13|1 |Bi|0 | equal | not-sent | | |Frag Res |2 |1 |Bi|0 | equal | not-sent | | |Frag M flag |1 |1 |Bi|1 | equal | not-sent | | |Frag Ident |32|1 |Bi| | ignore | value-sent | | +----------------+--+--+--+---+--------+--------------+------+
For IPv6-in-IPv6 tunneling, the inner header may use different address prefixes than the outer header. This rule does not include IPv6-in-IPv6 as a further nesting option.¶
Rule 7 +----------------+--+--+--+---------+--------+--------------+------+ | FID |FL|FP|DI| TV | MO | CDA | Sent | +----------------+--+--+--+---------+--------+--------------+------+ |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent | | |IPv6 Diffserv |8 |1 |Bi|0 | equal | not-sent | | |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent | | |IPv6 Length |16|1 |Bi| | ignore | compute-* | | |IPv6 Next Header|8 |1 |Bi|17 | mapping| branch(3) |0b000 | | | | | | 6 | mapping| branch(4) |0b001 | | | | | |44 | mapping| branch(5) |0b010 | | | | | |60 | mapping| branch(6) |0b011 | | | | | |59 | mapping| branch(NULL) |0b100 | |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent | | |IPv6 DevPrefix |64|1 |Bi|2001::/64| equal | not-sent | | |IPv6 DevIID |64|1 |Bi| | ignore | DevIID | | |IPv6 AppPrefix |64|1 |Bi|2001::/64| equal | not-sent | | |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent | | +----------------+--+--+--+---------+--------+--------------+------+
Rule 8 +----------------+--+--+--+---------+--------+------------+------+ | FID |FL|FP|DI| TV | MO | CDA | Sent | +----------------+--+--+--+---------+--------+------------+------+ |RTP.version |2 |1 |Bi|2 | equal | not-sent | | |RTP.padding |1 |1 |Bi|0 | equal | not-sent | | |RTP.Extension |1 |1 |Bi|0 | ignore | value-sent | | |RTP.csrc-count |4 |1 |Bi|0b00 | MSB(2) | LSB(2) | | |RTP.marker |1 |1 |Bi|0 | ignore | value-sent | | |RTP.payloadType |7 |1 |Bi|0b1100000| MSB(2) | LSB(5) | | |RTP.SeqNr |16|1 |Bi|0 | ignore | value-sent | | |RTP.SSRC |32|1 |Bi|0 | ignore | value-sent | | +----------------+--+--+--+---------+--------+------------+------+
Consider an IPv6/UDP/RTP packet with the following header values:¶
IPv6 Next Header: 17 (UDP)¶
UDP Source Port: 1123 (downlink)¶
UDP Destination Port: 1124 (downlink)¶
RTP Version: 2¶
The compression proceeds as follows:¶
The compressor iterates through the rule set and attempts to match each rule against the packet. Rule 2 (Figure 5) is selected as the initial rule because its IPv6 field descriptions (Version, Diffserv, Flow Label, Hop Limit, prefixes, IIDs) all match the packet. Note that Rule 2 here uses branch rather than a fixed Next Header value, so matching succeeds regardless of the transport protocol.¶
IPv6 fields are matched and compressed. The Next Header field (value 17) matches the first mapping entry. The compressor encodes residual 0b000 and queues Rule 3 for processing.¶
After completing Rule 2, the compressor loads Rule 3 (Figure 7). UDP fields are matched and compressed.¶
The match-rule MO at the end of Rule 3 loads Rule 8 and attempts matching against the UDP payload. RTP version = 2 matches the first field. All other RTP fields match. The compressor encodes residual 0b00 and processes Rule 8.¶
The resulting compressed packet contains: Rule ID + IPv6 branch residual (3 bits) + UDP payload branch residual (2 bits) + RTP residual fields (Extension, csrc-count LSB, marker, payloadType LSB, SeqNr, SSRC).¶
The mechanisms defined in this document introduce new attack surfaces related to context provisioning and rule processing.¶
The ref(N), ref-edit(N,M), and branch CDAs create directed references between rules. If not validated, a malicious or misconfigured context could contain circular references (e.g., Rule A references Rule B which references Rule A), causing the compressor or decompressor to enter an infinite loop.¶
Implementations MUST detect circular references when a context is provisioned or updated. A simple approach is to verify that the rule reference graph is a directed acyclic graph (DAG). Alternatively, implementations MAY enforce a maximum reference depth and abort processing if exceeded.¶
Deeply nested rule references, large branch mapping tables, or extensive match-rule candidate lists can consume significant processing time and memory on constrained devices. An attacker able to provision or influence context content could craft rules designed to exhaust device resources.¶
Implementations SHOULD enforce limits on:¶
Maximum reference chain depth (number of nested ref/ref-edit/branch invocations).¶
Maximum number of entries in a branch mapping table.¶
Maximum number of candidate rules evaluated by match-rule.¶
Total processing time for a single packet compression/decompression operation.¶
If any limit is exceeded, the implementation MUST abort processing and transmit the packet uncompressed.¶
The security of these mechanisms depends on the integrity of the shared context. Unauthorized modification of rules (e.g., redirecting a ref(N) to a different rule, or altering branch mappings) could cause incorrect compression or decompression, leading to data corruption or information disclosure. Context provisioning and update mechanisms MUST ensure integrity and authenticity of rule definitions.¶
TODO¶