SCHC Compute-Address Compression/Decompression Actions for Dynamically Assigned IP Addresses

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.¶

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.¶

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.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.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.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.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.¶

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.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.¶

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)¶

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.¶

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.¶

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.¶

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.¶

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.¶

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.¶

• 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.¶

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:¶

  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.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.¶

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.¶

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, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4291]

Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/rfc/rfc4291>.

[RFC5869]

Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.

[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, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[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, <https://www.rfc-editor.org/rfc/rfc8724>.

[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, <https://www.rfc-editor.org/rfc/rfc8981>.

13.2. Informative References

[RFC4862]

Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/rfc/rfc4862>.

[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, <https://www.rfc-editor.org/rfc/rfc7217>.

[RFC8200]

Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/rfc/rfc8200>.

[RFC8376]

Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, <https://www.rfc-editor.org/rfc/rfc8376>.