Static Context Header Compression M. Westerlund Internet-Draft L. Corneo Intended status: Standards Track Ericsson Expires: 7 January 2027 6 July 2026 SCHC Compute-Address Compression/Decompression Actions for Dynamically Assigned IP Addresses draft-westerlund-schc-compute-address-00 Abstract This document defines new Matching Operators (MOs) and Compression/ Decompression Actions (CDAs) for the Static Context Header Compression and fragmentation (SCHC) framework defined in RFC 8724. These extensions enable efficient compression of dynamically assigned IP addresses, including IPv4 addresses assigned via DHCP, IPv6 prefixes learned through SLAAC or DHCPv6, IPv6 Interface Identifiers (IIDs), and IPv6 temporary privacy addresses generated per RFC 8981. The mechanism relies on both the compressor and decompressor sharing knowledge of the set of addresses assigned to the device. Addresses are organized into deterministically sorted tables, allowing compression to a small index value. For temporary IPv6 addresses, a synchronized generation algorithm enables compression to an epoch and counter value. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Static Context Header Compression Working Group mailing list (schc@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/schc/. Source for this draft and an issue tracker can be found at https://github.com/gloinul/schc-compute-address. 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/. Westerlund & Corneo Expires 7 January 2027 [Page 1] Internet-Draft SCHC Compute-Address CDAs July 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Architecture and Assumptions . . . . . . . . . . . . . . . . 6 5. Address Table Construction . . . . . . . . . . . . . . . . . 7 5.1. Address Categories . . . . . . . . . . . . . . . . . . . 7 5.2. Input Filtering . . . . . . . . . . . . . . . . . . . . . 7 5.3. Sorting and Indexing . . . . . . . . . . . . . . . . . . 8 5.4. Address Table Caching . . . . . . . . . . . . . . . . . . 9 6. Compute-Address MO and CDA . . . . . . . . . . . . . . . . . 9 6.1. comp-addr-v4 . . . . . . . . . . . . . . . . . . . . . . 9 6.1.1. Matching Operator . . . . . . . . . . . . . . . . . . 9 6.1.2. Compression/Decompression Action . . . . . . . . . . 9 6.1.3. Rule Field Descriptor . . . . . . . . . . . . . . . . 10 6.2. comp-addr-prefix . . . . . . . . . . . . . . . . . . . . 10 6.2.1. Matching Operator . . . . . . . . . . . . . . . . . . 10 6.2.2. Compression/Decompression Action . . . . . . . . . . 10 6.2.3. Rule Field Descriptor . . . . . . . . . . . . . . . . 11 6.3. comp-addr-iid . . . . . . . . . . . . . . . . . . . . . . 11 6.3.1. Matching Operator . . . . . . . . . . . . . . . . . . 11 6.3.2. Compression/Decompression Action . . . . . . . . . . 11 6.3.3. Rule Field Descriptor . . . . . . . . . . . . . . . . 12 6.4. Example Rule . . . . . . . . . . . . . . . . . . . . . . 12 7. Compute Temporary IPv6 IID . . . . . . . . . . . . . . . . . 14 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 Westerlund & Corneo Expires 7 January 2027 [Page 2] Internet-Draft SCHC Compute-Address CDAs July 2026 7.2. Shared State Requirements . . . . . . . . . . . . . . . . 14 7.3. Epoch and Time Derivation . . . . . . . . . . . . . . . . 15 7.4. IID Generation Algorithm . . . . . . . . . . . . . . . . 16 7.5. Matching Operator: comp-temp-iid . . . . . . . . . . . . 17 7.6. Compression/Decompression Action: comp-temp-iid . . . . . 18 7.7. Rule Field Descriptor . . . . . . . . . . . . . . . . . . 18 7.8. Temporary IID Caching . . . . . . . . . . . . . . . . . . 19 8. Address Table Updates . . . . . . . . . . . . . . . . . . . . 19 9. Address Set Provisioning . . . . . . . . . . . . . . . . . . 20 9.1. General Mechanisms . . . . . . . . . . . . . . . . . . . 20 9.2. Mobile Network Considerations . . . . . . . . . . . . . . 20 9.2.1. Stable Privacy Addresses on Mobile Devices . . . . . 21 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. IPv4 Single Address (DHCP) . . . . . . . . . . . . . . . 22 10.2. IPv6 Dual Prefix (SLAAC + DHCPv6-PD) . . . . . . . . . . 22 10.3. Temporary Privacy Address . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11.1. Secret Key Management . . . . . . . . . . . . . . . . . 23 11.2. Clock Desynchronization . . . . . . . . . . . . . . . . 24 11.3. Address Table Inconsistency . . . . . . . . . . . . . . 24 11.4. Privacy Considerations . . . . . . . . . . . . . . . . . 24 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . 26 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction Static Context Header Compression and fragmentation (SCHC) [RFC8724] provides a mechanism for compressing protocol headers over constrained links. SCHC relies on a shared static context (a set of Rules) between the compressor and decompressor. Each Rule describes how individual header fields are matched and compressed using Matching Operators (MOs) and Compression/Decompression Actions (CDAs). The CDAs defined in [RFC8724] assume that address field values are either known at Rule provisioning time (enabling the use of "not- sent" or "mapping-sent" CDAs) or can be derived from Layer 2 information (using "DevIID" or "AppIID" CDAs). However, in many modern network deployments, IP addresses are assigned dynamically and may change over time. Examples include: * IPv4 addresses assigned via DHCP Westerlund & Corneo Expires 7 January 2027 [Page 3] Internet-Draft SCHC Compute-Address CDAs July 2026 * IPv6 prefixes learned through Router Advertisements (SLAAC [RFC4862]) or DHCPv6 Prefix Delegation * IPv6 Interface Identifiers generated per RFC 7217 * IPv6 temporary privacy addresses generated per [RFC8981] Furthermore, in mobile network architectures (e.g., 3GPP), there are no Layer 2 addresses available at the packet level, rendering the DevIID and AppIID CDAs from [RFC8724] inapplicable. This document defines new MOs and CDAs that enable efficient compression of dynamically assigned addresses by leveraging shared knowledge of the device's assigned address set between the compressor and decompressor. The new CDAs are: * comp-addr-v4: for IPv4 addresses * comp-addr-prefix: for IPv6 address prefixes * comp-addr-iid: for IPv6 Interface Identifiers * comp-temp-iid: for IPv6 temporary privacy IIDs 2. Terminology 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. This document uses the terminology defined in [RFC8724]. The following additional terms are used: Address Table: A deterministically sorted list of address information elements of a given category, derived from the set of addresses assigned to the device. The Address Table is maintained per-context and shared between compressor and decompressor. Address Category: A classification of address information. This document defines three categories: IPv4 full address, IPv6 prefix, and IPv6 Interface Identifier (IID). Address Index: A zero-based integer identifying an entry's position in an Address Table. Epoch: A time interval identifier used in the generation of Westerlund & Corneo Expires 7 January 2027 [Page 4] Internet-Draft SCHC Compute-Address CDAs July 2026 temporary IPv6 IIDs. The epoch counter identifies which time interval was used as input to the IID generation function. DAD Counter: A counter used to resolve Duplicate Address Detection collisions during temporary IID generation, as defined in [RFC8981]. 3. Problem Statement SCHC was originally designed for Low-Power Wide Area Networks (LPWANs) [RFC8376] where devices typically have fixed, pre-configured IP addresses. In such environments, the address can be stored as a Target Value (TV) in the Rule and compressed using the "not-sent" CDA, achieving maximum compression efficiency. However, when SCHC is applied to networks where addresses are dynamically assigned, several problems arise: 1. *Dynamic assignment:* Networks using DHCP, DHCPv6, or SLAAC assign addresses that may change each time the device connects. Storing these in the Rule's TV requires updating the Rule set on every address change, which conflicts with SCHC's static context design. 2. *Multiple addresses:* A device may be assigned multiple IPv4 addresses, multiple IPv6 prefixes (e.g., via DHCPv6 Prefix Delegation for tethering), and multiple IIDs. The existing "mapping-sent" CDA could handle a fixed list, but the list itself is dynamic. 3. *Temporary privacy addresses:* RFC 8981 defines temporary addresses with randomized IIDs that change periodically. Sending the full 64-bit IID as a residual negates the benefit of compression. 4. *No Layer 2 addresses:* In mobile networks (e.g., 3GPP), there are no Layer 2 addresses in the packet headers that could be used to derive the IPv6 IID. The DevIID and AppIID CDAs from [RFC8724] are therefore not applicable in these environments. Without the extensions defined in this document, the only option for compressing dynamic addresses in SCHC is to use the "value-sent" CDA, which transmits the full address field (32 bits for IPv4, 64 bits for an IPv6 prefix or IID, or 128 bits for a full IPv6 address [RFC8200]) as the compression residual. This results in poor compression efficiency for the address fields. Westerlund & Corneo Expires 7 January 2027 [Page 5] Internet-Draft SCHC Compute-Address CDAs July 2026 4. Architecture and Assumptions The mechanisms defined in this document rely on the following architectural assumptions: 1. *Shared address knowledge:* Both the compressor and decompressor have access to the same set of addresses assigned to the device. How this knowledge is obtained is deployment-specific and discussed informatively in Section 9. 2. *Per-context Address Tables:* The Address Tables are maintained per SCHC context (i.e., per device). Multiple Rules within the same context MAY reference the same Address Table. The table SHOULD be cached and only rebuilt when the underlying address set changes. 3. *Synchronized state:* Both endpoints MUST maintain synchronized address sets. When the address set changes (e.g., new address assigned, address expired), both sides MUST rebuild their Address Tables. Mechanisms for ensuring this synchronization are outside the scope of this document and may require further extensions. 4. *Clock synchronization (for comp-temp-iid):* For the temporary IID mechanism, both endpoints MUST have roughly synchronized wall clocks. The required accuracy depends on the configured time interval length but is typically in the order of seconds. Figure 1 illustrates the relationship between the address assignment infrastructure and the SCHC compressor/decompressor. +--------+ +------------+ +-----------+ | Device |<-------->| Network |<------->| SCHC | | (UE) | Address | Address | Address | Network | | | Assign. | Assignment | State | Compressor| | SCHC | | Function | | /Decompr. | | Compr/ | | (DHCP/SMF/ | | | | Decomp | | SLAAC) | | | +--------+ +------------+ +-----------+ | | | Both maintain same Address Tables | |<==========================================>| Figure 1: Architecture Overview Westerlund & Corneo Expires 7 January 2027 [Page 6] Internet-Draft SCHC Compute-Address CDAs July 2026 5. Address Table Construction The compute-address CDAs defined in this document operate on Address Tables that are derived from the set of IP addresses assigned to the device's network interface(s). This section defines how these tables are constructed. 5.1. Address Categories The assigned addresses are classified into three categories, each producing a separate Address Table: IPv4 Address Table: Contains full 32-bit IPv4 addresses assigned to the device. IPv6 Prefix Table: Contains IPv6 prefixes (by default the first 64 bits of each assigned IPv6 address). The prefix length is configurable but defaults to 64 bits. IPv6 IID Table: Contains IPv6 Interface Identifiers (by default bits 64-127 of each assigned IPv6 address, where bit 0 is the most significant bit). The offset and length are configurable but default to offset 64, length 64 bits. Each category's table is independent. A single IPv6 address contributes one entry to the IPv6 Prefix Table and one entry to the IPv6 IID Table. 5.2. Input Filtering Before constructing the Address Tables, the set of assigned addresses MUST be filtered as follows: * Loopback addresses (127.0.0.0/8 for IPv4, ::1/128 for IPv6) MUST be excluded. * Link-local addresses (169.254.0.0/16 for IPv4, fe80::/10 for IPv6) SHOULD be excluded unless the Rule specifically targets link-local communication. * Multicast addresses MUST be excluded. The filtering criteria are determined by the address type filter associated with the MO/CDA in the Rule. The default filter includes only unicast global addresses. Westerlund & Corneo Expires 7 January 2027 [Page 7] Internet-Draft SCHC Compute-Address CDAs July 2026 5.3. Sorting and Indexing After filtering, the entries in each Address Table MUST be sorted in ascending binary order (treating the address or address portion as an unsigned integer). This produces a deterministic ordering that is identical on both the compressor and decompressor, provided they have the same input address set. Each entry is assigned a zero-based index: the entry with the lowest binary value receives index 0, the next receives index 1, and so on. Duplicate entries (e.g., two IPv6 addresses sharing the same prefix) MUST be deduplicated before indexing. Only unique values appear in the table. Device assigned addresses: IPv4: 198.51.100.34 IPv6: 2001:db8::a38d:1841:2a6f:124b:763e IPv6: 2001:db8::1234:c84a:e8ff:fe45:ad7f After filtering (loopback/link-local removed) and categorization: IPv4 Address Table: +-------+----------------+ | Index | Address | +-------+----------------+ | 0 | 198.51.100.34 | +-------+----------------+ IPv6 Prefix Table (first 64 bits, deduplicated): +-------+----------------+ | Index | Prefix | +-------+----------------+ | 0 | 2001:db8:: | +-------+----------------+ IPv6 IID Table (bits 64-127, sorted ascending): +-------+---------------------------+ | Index | IID | +-------+---------------------------+ | 0 | 1234:c84a:e8ff:fe45:ad7f | | 1 | a38d:1841:2a6f:124b:763e | +-------+---------------------------+ Figure 2: Example Address Table Construction Westerlund & Corneo Expires 7 January 2027 [Page 8] Internet-Draft SCHC Compute-Address CDAs July 2026 5.4. Address Table Caching Implementations SHOULD cache the constructed Address Tables to avoid recomputation on every packet. The cached tables MUST be invalidated and rebuilt when the underlying set of assigned addresses changes (e.g., new address assigned, existing address expired or released). Since the Address Tables are per-context, they are shared across all Rules in the same context. A single table rebuild serves all Rules that reference the same address category. 6. Compute-Address MO and CDA This section defines three named Matching Operators and Compression/ Decompression Actions for dynamically assigned addresses. Each operates on the corresponding Address Table defined in Section 5. In all three cases, the MO and CDA share the same name. The Rule's Field Descriptor specifies the number of bits allocated for the residual, which determines the maximum number of entries that can be indexed (2^bits entries). 6.1. comp-addr-v4 The comp-addr-v4 MO and CDA operate on the IPv4 Address Table. They are used to compress full 32-bit IPv4 addresses that have been dynamically assigned to the device. 6.1.1. Matching Operator The comp-addr-v4 MO compares the packet's field value (a 32-bit IPv4 address) against all entries in the IPv4 Address Table. The MO returns True if the field value matches any entry in the table AND the matching entry's index is representable within the number of residual bits allocated in the Rule. The MO returns False otherwise (no match found, or the matching entry's index exceeds the maximum representable value). 6.1.2. Compression/Decompression Action On compression: the CDA looks up the field value in the IPv4 Address Table, obtains the matching entry's index, and encodes this index as the compression residual using the number of bits specified in the Rule. Westerlund & Corneo Expires 7 January 2027 [Page 9] Internet-Draft SCHC Compute-Address CDAs July 2026 On decompression: the CDA reads the residual bits, decodes the index value, looks up the corresponding entry in the IPv4 Address Table, and writes the 32-bit IPv4 address into the packet field. 6.1.3. Rule Field Descriptor A Field Descriptor using comp-addr-v4 has the following characteristics: * FID: The IPv4 address field (e.g., IPv4 Source Address or IPv4 Destination Address) * FL: 32 (the original field length) * TV: Not used (left empty) * MO: comp-addr-v4 * CDA: comp-addr-v4 * Sent bits: The number of bits for the index residual (e.g., 2 bits for up to 4 addresses) 6.2. comp-addr-prefix The comp-addr-prefix MO and CDA operate on the IPv6 Prefix Table. They are used to compress IPv6 address prefixes that have been dynamically assigned to the device (e.g., via SLAAC Router Advertisements or DHCPv6 Prefix Delegation). 6.2.1. Matching Operator The comp-addr-prefix MO extracts the prefix portion (by default the first 64 bits) from the packet's IPv6 address field and compares it against all entries in the IPv6 Prefix Table. The MO returns True if the extracted prefix matches any entry in the table AND the matching entry's index is representable within the allocated residual bits. The MO returns False otherwise. 6.2.2. Compression/Decompression Action On compression: the CDA extracts the prefix from the field value, looks it up in the IPv6 Prefix Table, and encodes the matching entry's index as the residual. Westerlund & Corneo Expires 7 January 2027 [Page 10] Internet-Draft SCHC Compute-Address CDAs July 2026 On decompression: the CDA reads the residual, decodes the index, looks up the prefix in the IPv6 Prefix Table, and writes it into the appropriate portion of the IPv6 address field. 6.2.3. Rule Field Descriptor A Field Descriptor using comp-addr-prefix has the following characteristics: * FID: The IPv6 address prefix field (e.g., IPv6 Dev Prefix or IPv6 App Prefix) * FL: 64 (default prefix length) * TV: Not used (left empty) * MO: comp-addr-prefix * CDA: comp-addr-prefix * Sent bits: The number of bits for the index residual (e.g., 2 bits for up to 4 prefixes) 6.3. comp-addr-iid The comp-addr-iid MO and CDA operate on the IPv6 IID Table. They are used to compress IPv6 Interface Identifiers that have been assigned to the device, including stable IIDs generated per [RFC7217]. 6.3.1. Matching Operator The comp-addr-iid MO extracts the IID portion (by default bits 64-127) from the packet's IPv6 address field and compares it against all entries in the IPv6 IID Table. The MO returns True if the extracted IID matches any entry in the table AND the matching entry's index is representable within the allocated residual bits. The MO returns False otherwise. 6.3.2. Compression/Decompression Action On compression: the CDA extracts the IID from the field value, looks it up in the IPv6 IID Table, and encodes the matching entry's index as the residual. Westerlund & Corneo Expires 7 January 2027 [Page 11] Internet-Draft SCHC Compute-Address CDAs July 2026 On decompression: the CDA reads the residual, decodes the index, looks up the IID in the IPv6 IID Table, and writes it into the appropriate portion of the IPv6 address field. 6.3.3. Rule Field Descriptor A Field Descriptor using comp-addr-iid has the following characteristics: * FID: The IPv6 IID field (e.g., IPv6 Dev IID or IPv6 App IID) * FL: 64 (default IID length) * TV: Not used (left empty) * MO: comp-addr-iid * CDA: comp-addr-iid * Sent bits: The number of bits for the index residual (e.g., 4 bits for up to 16 IIDs) 6.4. Example Rule The following example shows a compression Rule for an IPv6/UDP packet where the device has dynamically assigned IPv6 addresses. The device prefix and IID are compressed using comp-addr-prefix and comp-addr- iid respectively. Westerlund & Corneo Expires 7 January 2027 [Page 12] Internet-Draft SCHC Compute-Address CDAs July 2026 +=========+==+==+==+==========+===============+===============+====+ |FID |FL|FP|DI|TV | MO | CDA |Sent| +=========+==+==+==+==========+===============+===============+====+ |IPv6 |4 |1 |Bi|6 | equal | not-sent | | |Version | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |IPv6 |8 |1 |Bi|0 | equal | not-sent | | |DiffServ | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |IPv6 Flow|20|1 |Bi|0 | equal | not-sent | | |Label | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |IPv6 |16|1 |Bi| | ignore | compute-* | | |Length | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |IPv6 Next|8 |1 |Bi|17 | equal | not-sent | | |Header | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |IPv6 Hop |8 |1 |Bi|255 | ignore | not-sent | | |Limit | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |IPv6 |64|1 |Up| | comp-addr-prf | comp-addr-prf |2 | |DevPrefix| | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |IPv6 |64|1 |Up| | comp-addr-iid | comp-addr-iid |4 | |DevIID | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |IPv6 |64|1 |Up|2001:db8::| equal | not-sent | | |AppPrefix| | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |IPv6 |64|1 |Up|::1 | equal | not-sent | | |AppIID | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |UDP |16|1 |Bi|5683 | equal | not-sent | | |DevPort | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |UDP |16|1 |Bi|5683 | equal | not-sent | | |AppPort | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |UDP |16|1 |Bi| | ignore | compute-* | | |Length | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ |UDP |16|1 |Bi| | ignore | compute-* | | |Checksum | | | | | | | | +---------+--+--+--+----------+---------------+---------------+----+ Table 1: Example Rule Using Compute-Address CDAs Westerlund & Corneo Expires 7 January 2027 [Page 13] Internet-Draft SCHC Compute-Address CDAs July 2026 In this example, the device's IPv6 source prefix is compressed to 2 bits (supporting up to 4 prefixes) and the IID to 4 bits (supporting up to 16 IIDs). The total residual for the device's full 128-bit IPv6 address is only 6 bits. 7. Compute Temporary IPv6 IID This section defines the comp-temp-iid MO and CDA for compressing IPv6 temporary privacy addresses generated per [RFC8981]. Unlike the table-index approach of the compute-address CDAs in Section 6, this mechanism uses a synchronized generation algorithm that allows both endpoints to derive the same IID from a small set of parameters transmitted as the compression residual. 7.1. Overview RFC 8981 defines a procedure for generating temporary IPv6 IIDs using a pseudorandom function (PRF) with several inputs. The comp-temp-iid mechanism constrains these inputs such that both the device and the network-side compressor/decompressor can independently generate the same IID given: * Shared static context (secret key, interface identifier, network identifier) * The IPv6 prefix (known via other means, e.g., comp-addr-prefix) * A time epoch counter (transmitted in the residual) * A DAD counter (transmitted in the residual) The compression residual consists of the epoch counter (N bits) and the DAD counter (M bits), where N and M are configured per-rule. This typically results in fewer than 10 bits of residual instead of the full 64-bit IID. 7.2. Shared State Requirements The following information MUST be available to both the device-side and network-side compressor/decompressor for the comp-temp-iid mechanism to function: secret_key: A device-specific secret key of at least 128 bits, used as input to the PRF. This key MUST be unique per device and MUST NOT be used for any other purpose. It MAY be derived from existing device credentials (e.g., from 3GPP security keys using a key derivation function such as HKDF [RFC5869]) or MAY be provisioned as part of the SCHC context setup. Westerlund & Corneo Expires 7 January 2027 [Page 14] Internet-Draft SCHC Compute-Address CDAs July 2026 Net_Iface: A network interface identifier. In networks without Layer 2 addresses (e.g., 3GPP), this MUST be set to a deterministic value known to both endpoints, such as a value derived from the device's network identity. Network_ID: A network-specific identifier for the subnet or attachment point. This SHOULD be employed if available (e.g., an SSID for Wi-Fi, or a cell/network identifier for mobile networks). Time_Offset: A fixed time offset that defines when intervals begin, expressed as an offset within the interval period (e.g., minutes and seconds past the hour). Both compressor and decompressor MUST use the same offset value. Interval_Length: The duration of each time interval, in seconds. This determines how frequently new temporary IIDs are generated. Typical values range from 900 seconds (15 minutes) to 3600 seconds (1 hour). Max_Lifetime: The maximum lifetime of a temporary address, in seconds. This bounds how far back in time a valid epoch can refer. Prefix: The IPv6 prefix used as input to the generation function. This is typically known through other compression mechanisms (e.g., comp-addr-prefix) or network configuration. 7.3. Epoch and Time Derivation The epoch counter identifies which time interval was used to generate a particular temporary IID. It is derived from the wall clock time as follows: 1. Read the current wall clock time Tc (e.g., as a UNIX timestamp or NTP timestamp). 2. Compute the interval start time Tis by rounding Tc down to the most recent interval boundary. The interval boundaries are defined by Time_Offset and Interval_Length: Tis = Time_Offset + floor((Tc - Time_Offset) / Interval_Length) * Interval_Length 3. Compute the epoch counter as the number of complete intervals since a fixed reference point (e.g., UNIX epoch of 1970-01-01T00:00:00Z): epoch = floor((Tis - Time_Offset) / Interval_Length) Westerlund & Corneo Expires 7 January 2027 [Page 15] Internet-Draft SCHC Compute-Address CDAs July 2026 4. The N least significant bits of the epoch counter are used as the epoch value in the compression residual. The number of bits N MUST be large enough that the epoch value does not wrap around within the Max_Lifetime of any valid temporary address. Specifically: N >= ceil(log2(Max_Lifetime / Interval_Length + 1)) For example, with Interval_Length = 1800 seconds (30 minutes) and Max_Lifetime = 86400 seconds (24 hours), N >= ceil(log2(49)) = 6 bits. 7.4. IID Generation Algorithm The temporary IID is generated using the following algorithm, which is a constrained application of the procedure in Section 3.3.2 of [RFC8981]: Step 1: Compute the Random Identifier (RID): RID = F(Prefix, Net_Iface, Network_ID, Tis, DAD_Counter, secret_key) Where: * F() is a pseudorandom function. This document RECOMMENDS HMAC- SHA-256 [RFC6234] with the secret_key as the HMAC key and the concatenation of the other parameters as the message. The output is truncated to 64 bits for use as the IID. * Prefix is the IPv6 prefix (typically 64 bits). * Net_Iface is the network interface identifier. * Network_ID is the network identifier. * Tis is the interval start time computed in Section 7. * DAD_Counter starts at 0 and is incremented if the generated IID is found to be a duplicate or reserved. Step 2: Derive the IID from RID. Take the least significant 64 bits of the PRF output. Set bits 6 and 7 (the "u" and "g" bits in the Modified EUI-64 format) to 0, as specified in [RFC4291] Section 2.5.1 for non-globally-unique identifiers. Westerlund & Corneo Expires 7 January 2027 [Page 16] Internet-Draft SCHC Compute-Address CDAs July 2026 Step 3: Check the generated IID against reserved subnet anycast addresses and other reserved IID values. If the IID is reserved, or if Duplicate Address Detection (DAD) fails, increment DAD_Counter and repeat from Step 1. The PRF input SHOULD be constructed as the concatenation of the parameters in a fixed, well-defined order: PRF_input = Prefix || Net_Iface || Network_ID || Tis || DAD_Counter IID = truncate_64(HMAC-SHA-256(secret_key, PRF_input)) IID[6] = 0 (clear bit 6, the "u" bit) IID[7] = 0 (clear bit 7, the "g" bit) Note: The choice of PRF is an open issue. Future versions of this document may allow alternative PRFs or make the PRF selection configurable via the SCHC profile. 7.5. Matching Operator: comp-temp-iid The comp-temp-iid MO extracts the IID portion (bits 64-127) from the packet's IPv6 address field and attempts to match it against temporary IIDs that could have been generated using the shared state. The matching procedure is: 1. Check the IID cache (see Section 7.8). If the IID is found in the cache with a valid (epoch, DAD_Counter) pair, the MO returns True. 2. If not cached, iterate over recent epochs (starting from the current epoch and working backwards) and for each epoch iterate over DAD_Counter values (starting from 0), generating IIDs until a match is found or the search space is exhausted. 3. The search space is bounded by: epochs from current back to (current - 2^N + 1), and DAD_Counter from 0 to (2^M - 1), where N and M are the bit widths configured in the Rule. 4. If a match is found AND the epoch and DAD_Counter are representable in the allocated residual bits, the MO returns True. 5. Otherwise, the MO returns False. Westerlund & Corneo Expires 7 January 2027 [Page 17] Internet-Draft SCHC Compute-Address CDAs July 2026 7.6. Compression/Decompression Action: comp-temp-iid On compression: the CDA encodes the epoch counter (N bits) followed by the DAD_Counter (M bits) as the compression residual. The N least significant bits of the epoch counter value are placed in the most significant N bits of the residual. The DAD_Counter is encoded as an M-bit unsigned integer in the remaining bits. Residual format: +----------+-------------+ | Epoch | DAD_Counter | | (N bits) | (M bits) | +----------+-------------+ On decompression: the CDA reads N + M bits from the residual, extracts the epoch and DAD_Counter values, and either: * Looks up the IID in the cache using (epoch, DAD_Counter) as the key, or * Generates the IID using the algorithm in Section 7 with the decoded epoch (converted back to Tis) and DAD_Counter. The generated or cached IID is then written into the appropriate portion of the IPv6 address field. 7.7. Rule Field Descriptor A Field Descriptor using comp-temp-iid has the following characteristics: * FID: The IPv6 IID field (e.g., IPv6 Dev IID) * FL: 64 * TV: Not used (left empty) * MO: comp-temp-iid * CDA: comp-temp-iid * Sent bits: N + M (e.g., 6 + 2 = 8 bits) The values of N (epoch bits) and M (DAD counter bits) are configured per-rule. They MUST be specified as part of the Rule definition. Westerlund & Corneo Expires 7 January 2027 [Page 18] Internet-Draft SCHC Compute-Address CDAs July 2026 7.8. Temporary IID Caching Implementations SHOULD maintain a cache of generated temporary IIDs with their associated (epoch, DAD_Counter) metadata. This avoids the computational cost of iterating over the parameter space for every packet. On the device side, when a new temporary address is generated and assigned to an interface, the device SHOULD store the epoch and DAD_Counter used in its generation alongside the address. On the network side, the compressor/decompressor SHOULD observe IIDs used in uplink (device-to-network) packets and cache them with the corresponding (epoch, DAD_Counter) values determined during the MO matching process. This ensures that subsequent packets using the same temporary address can be processed efficiently without re- iterating. Cache entries SHOULD be expired when the corresponding temporary address exceeds its Max_Lifetime. 8. Address Table Updates The Address Tables defined in Section 5 are derived from the set of addresses currently assigned to the device. This set may change over time due to: * New address assignment (e.g., DHCP lease renewal with a new address, new prefix via Router Advertisement) * Address expiration or release * DHCPv6 Prefix Delegation changes * Network handover in mobile networks When the address set changes, both the compressor and decompressor MUST rebuild the affected Address Table(s) using the procedure in Section 5. Since the table is sorted deterministically, both sides will produce identical tables provided they have the same input address set. Note that rebuilding a table may change the indices of existing entries (e.g., a new address with a lower binary value shifts all higher entries up by one). Compressed packets in flight at the time of a table rebuild may be decompressed incorrectly if the decompressor has already updated its table while the compressor used the old table, or vice versa. Westerlund & Corneo Expires 7 January 2027 [Page 19] Internet-Draft SCHC Compute-Address CDAs July 2026 Detailed mechanisms for synchronizing table updates between compressor and decompressor, and for handling packets in flight during transitions, are outside the scope of this document and are expected to be addressed in future extensions. 9. Address Set Provisioning This section provides informational guidance on how the network-side compressor/decompressor can obtain knowledge of the device's assigned addresses. The exact mechanisms are deployment-specific and outside the normative scope of this document. 9.1. General Mechanisms In networks using standard IP address assignment protocols, the network-side compressor/decompressor can learn the device's addresses from: * *DHCP/DHCPv6 server state:* The DHCP server maintains lease information that maps devices to their assigned IPv4 addresses or IPv6 prefixes. This information can be made available to the compressor. * *RADIUS/Diameter attributes:* In networks using AAA infrastructure, address assignments may be communicated via RADIUS or Diameter attributes. * *Router Advertisement monitoring:* For SLAAC, the network knows which prefixes have been advertised. Combined with knowledge of the device's IID generation method, the full address can be determined. 9.2. Mobile Network Considerations In 3GPP mobile networks (4G/5G), the following characteristics are relevant: * *No Layer 2 addresses:* Unlike Ethernet or LoRaWAN, 3GPP radio bearers do not carry Layer 2 addresses in the packet headers. The DevIID and AppIID CDAs from [RFC8724] are therefore not applicable. This is a primary motivation for the compute-address CDAs defined in this document. Westerlund & Corneo Expires 7 January 2027 [Page 20] Internet-Draft SCHC Compute-Address CDAs July 2026 * *Address assignment by SMF:* In 5G, the Session Management Function (SMF) is responsible for IP address allocation to the UE (User Equipment). The compressor, which may be located in the gNB (base station), CU (Central Unit), or UPF (User Plane Function), needs a mechanism to receive the assigned address information from the SMF. * *Multiple PDU sessions:* A UE may have multiple PDU sessions, each with different IP addresses or prefixes. The compressor needs to know which addresses are associated with which session. * *Prefix Delegation:* A UE may receive delegated prefixes (e.g., for tethering). These additional prefixes must also be known to the compressor for efficient compression of traffic using those prefixes. The specific 3GPP signaling extensions needed to convey address information to the compressor are outside the scope of this document. 9.2.1. Stable Privacy Addresses on Mobile Devices Modern mobile operating systems (e.g., Android since version 10) generate stable IPv6 IIDs using the algorithm defined in [RFC7217] rather than the legacy EUI-64 derivation. The typical inputs are: * A device-local secret key (persisted across reboots) * The interface name (e.g., "rmnet0") * The assigned IPv6 prefix * A DAD counter Since the secret key is generated and stored locally on the device, the network-side compressor has no direct way to predict the resulting stable IID. This IID therefore cannot be elided using the DevIID CDA from [RFC8724], nor can it be placed in the Rule's Target Value at provisioning time (since it depends on the prefix, which is dynamic). The comp-addr-iid CDA defined in this document addresses this case: the network-side compressor learns the device's stable IID through the address provisioning mechanism (see Section 9) and both sides reference it via a small table index. This avoids transmitting the full 64-bit IID as a residual on every packet while requiring no changes to the device's existing address generation behavior. Westerlund & Corneo Expires 7 January 2027 [Page 21] Internet-Draft SCHC Compute-Address CDAs July 2026 10. Examples 10.1. IPv4 Single Address (DHCP) A device is assigned a single IPv4 address 198.51.100.34 via DHCP. The IPv4 Address Table contains one entry: IPv4 Address Table: Index 0: 198.51.100.34 Rule Field Descriptor: FID=IPv4 Src Addr, FL=32, MO=comp-addr-v4, CDA=comp-addr-v4, Sent=1 bit Compression: field value 198.51.100.34 matches index 0 -> residual: 0b0 (1 bit) Decompression: residual 0b0 -> index 0 -> 198.51.100.34 10.2. IPv6 Dual Prefix (SLAAC + DHCPv6-PD) A device has two IPv6 prefixes: 2001:db8:1::/64 from SLAAC and 2001:db8:2::/64 from DHCPv6 Prefix Delegation. IPv6 Prefix Table (sorted ascending): Index 0: 2001:db8:1:: (2001:0db8:0001:0000) Index 1: 2001:db8:2:: (2001:0db8:0002:0000) Rule Field Descriptor: FID=IPv6 DevPrefix, FL=64, MO=comp-addr-prefix, CDA=comp-addr-prefix, Sent=1 bit Packet with source prefix 2001:db8:2:: Compression: matches index 1 -> residual: 0b1 (1 bit) Decompression: residual 0b1 -> index 1 -> 2001:db8:2:: 10.3. Temporary Privacy Address A device generates a temporary IID using the comp-temp-iid algorithm with the following parameters: Westerlund & Corneo Expires 7 January 2027 [Page 22] Internet-Draft SCHC Compute-Address CDAs July 2026 Shared state: secret_key: 0x4a7f... (128 bits) Net_Iface: 0x00000001 (device-specific) Network_ID: "mobile-net-1" Time_Offset: 0 seconds (intervals aligned to midnight) Interval_Length: 1800 seconds (30 minutes) Max_Lifetime: 86400 seconds (24 hours) Rule configuration: N = 6 bits (epoch), M = 2 bits (DAD counter) Total residual: 8 bits Current time: 2026-06-01T14:45:00Z Epoch calculation: Tis = 2026-06-01T14:30:00Z (rounded down to interval boundary) epoch = (number of 30-min intervals since reference) mod 64 Suppose epoch = 42 (0b101010), DAD_Counter = 0 (0b00) Compression residual: 0b10101000 (8 bits) Decompression: epoch = 42, DAD_Counter = 0 Tis = derive from epoch IID = truncate_64(HMAC-SHA-256(secret_key, Prefix || Net_Iface || Network_ID || Tis || 0)) Write IID into packet field. 11. Security Considerations 11.1. Secret Key Management The comp-temp-iid mechanism relies on a shared secret key between the device and the network-side compressor/decompressor. Compromise of this key would allow an attacker to predict all temporary IIDs generated by the device, defeating the privacy protection intended by [RFC8981]. The secret key MUST be stored securely on both endpoints. It SHOULD be derived from existing security associations where possible (e.g., from 3GPP security keys using HKDF) rather than being transmitted in the clear. The secret key MUST NOT be reused for any purpose other than temporary IID generation for SCHC compression. Westerlund & Corneo Expires 7 January 2027 [Page 23] Internet-Draft SCHC Compute-Address CDAs July 2026 11.2. Clock Desynchronization If the clocks of the compressor and decompressor drift apart beyond the tolerance of the time interval, the decompressor may generate a different IID than the one used by the device. This would result in packet misdelivery or discard. Implementations SHOULD monitor for decompression failures that may indicate clock drift and trigger resynchronization. The Interval_Length SHOULD be chosen to be significantly larger than the expected maximum clock drift between synchronization events. 11.3. Address Table Inconsistency If the compressor and decompressor have different views of the device's assigned address set, the Address Tables will differ, leading to incorrect compression/decompression. This could result in packets being delivered to the wrong address or being discarded. Deployments MUST ensure that address assignment changes are propagated to both endpoints before the new addresses are used in packet headers. The exact mechanism for ensuring this is deployment- specific. 11.4. Privacy Considerations The compression residual for comp-addr-v4, comp-addr-prefix, and comp-addr-iid reveals the index of the address in the sorted table. An observer of the compressed traffic can determine: * How many addresses the device has (from the maximum index value observed) * Whether the device is using the same or different addresses across packets (same index = same address) This information leakage is inherent to the compression mechanism and should be considered acceptable given that SCHC is typically used over links where the observer would already have access to the uncompressed traffic (e.g., the radio link in a mobile network). For comp-temp-iid, the epoch value in the residual reveals when the temporary address was generated. This is less information than the full IID but still provides some temporal correlation capability to an observer. Westerlund & Corneo Expires 7 January 2027 [Page 24] Internet-Draft SCHC Compute-Address CDAs July 2026 12. IANA Considerations This document defines new Matching Operators and Compression/ Decompression Actions for the SCHC framework. When IANA registries are established for SCHC MOs and CDAs, the following entries should be registered: New Matching Operators: * comp-addr-v4 * comp-addr-prefix * comp-addr-iid * comp-temp-iid New Compression/Decompression Actions: * comp-addr-v4 * comp-addr-prefix * comp-addr-iid * comp-temp-iid Note: At the time of writing, no IANA registry exists for SCHC MOs and CDAs. If such registries are created, the above values should be registered. Otherwise, this document serves as the definition of these MO and CDA names. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . Westerlund & Corneo Expires 7 January 2027 [Page 25] Internet-Draft SCHC Compute-Address CDAs July 2026 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, . [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, . 13.2. Informative References [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, . Westerlund & Corneo Expires 7 January 2027 [Page 26] Internet-Draft SCHC Compute-Address CDAs July 2026 Acknowledgements The authors would like to thank the members of the IETF SCHC Working Group for their feedback and discussions. Contributors Edgar Ramos Ericsson FI- Jorvas Finland Email: edgar.ramos@ericsson.com Ari Keränen Ericsson FI- Jorvas Finland Email: ari.keranen@ericsson.com Authors' Addresses Magnus Westerlund Ericsson Kista Sweden Email: magnus.westerlund@ericsson.com Lorenzo Corneo Ericsson FI- Jorvas Finland Email: lorenzo.corneo@ericsson.com Westerlund & Corneo Expires 7 January 2027 [Page 27]