rfc-8724

SCHC: Generic Framework for Static Context Header Compression and Fragmentation

A. Minaburo, L. Toutain, C. Gomez, D. Barthel, JC. Zuniga
date2020-04 streamIETF areaint wglpwan statusPROPOSED STANDARD pages71 canonicalhttps://www.rfc-editor.org/rfc/rfc8724 doi10.17487/RFC8724
This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.

updated by

Extracted elements (30)

design-rationale §8.4

Multiple F/R modes (No-ACK, ACK-Always, ACK-on-Error) are provided to accommodate the range of LPWAN link characteristics: No-ACK suits unidirectional or variable-MTU links with no feedback; ACK-Always suits reliable bidirectional links; ACK-on-Error suits out-of-order variable-MTU links requiring error recovery.

ip

design-rationale §1

SCHC uses a static Context shared by both ends to avoid resynchronization traffic. In LPWANs the return path may be restricted, expensive, or entirely unavailable; a compression protocol depending on feedback is incompatible with these constraints. The static approach also exploits the high predictability of LPWAN application traffic.

ip, udp

design-rationale §1

Technology-specific parameters (MTU, RuleID sizes, timer values, WINDOW_SIZE, etc.) are deliberately delegated to Profiles defined in separate documents rather than fixed in this specification. This keeps the SCHC framework technology-independent while allowing full parameterization for specific LPWAN technologies.

ip

interoperability-note §5.2

Both ends of a SCHC communication MUST be provisioned with the same Profile information and the same set of Rules before communication starts. Rules for compression/decompression and for fragmentation/reassembly share the same RuleID space within the scope of a given Dev-to-infrastructure link.

ip, udp

normative-requirement §8.4.2 MUST

In ACK-Always mode, the W field MUST be present with size M=1 bit. Each Profile MUST define: N, WINDOW_SIZE (strictly less than 2^N), RCS size/algorithm, T, MAX_ACK_REQUESTS, Retransmission Timer expiry, and Inactivity Timer expiry.

ip

normative-requirement §8.4.3 MUST

In ACK-on-Error mode, all tiles except the last and penultimate MUST be of equal (regular) size; each tile MUST be at least one L2 Word. The W field MUST be present and wide enough to unambiguously represent an absolute window number. SCHC ACKs are only sent for windows with missing tiles.

ip

normative-requirement §8.4.1 MUST NOT

In No-ACK mode, the W field MUST NOT be present; SCHC ACK and SCHC ACK REQ MUST NOT be sent; SCHC Receiver-Abort MUST NOT be sent; SCHC Sender-Abort MAY be sent. N (FCN field size) is RECOMMENDED to be 1. Tiles must be transmitted in the order they appear in the SCHC Packet.

ip

normative-requirement §8.2.4 MUST

The DTag field MUST carry the same value for all SCHC F/R messages belonging to the same fragmented SCHC Packet, and MUST carry different values for messages belonging to different SCHC Packets that are simultaneously in transit under the same RuleID.

ip

normative-requirement §8.2.3 MUST

The integrity of the fragmentation/reassembly process of a SCHC Packet MUST be checked at the receiver. A Profile MUST specify the method. CRC32 polynomial 0xEDB88320 (reversed polynomial, Ethernet standard) is RECOMMENDED as the default RCS algorithm.

ip, security

normative-requirement §8.2.3 MUST

The RCS MUST be computed over the full SCHC Packet concatenated with any padding bits of the last SCHC Fragment, because the SCHC reassembler cannot determine the boundary between the last tile and padding without decompressing the packet, which is outside the reassembler's scope.

ip, security

normative-requirement §8.1 MUST

The same SCHC F/R mode MUST be used for all SCHC Fragments of a given SCHC Packet. At least one RuleID MUST be allocated to tag packets for which compression was not possible; such packets MUST be sent uncompressed using that dedicated RuleID.

ip

normative-requirement §7 MUST

The SCHC C/D Contexts MUST be stored at both ends; they can be learned via a provisioning protocol, out-of-band means, or pre-provisioning. The SCHC C/Ds on both sides MUST share the same set of Rules, as must the SCHC F/Rs on both sides.

ip, udp

privacy-consideration §12.2.4

SCHC header fields (RuleID, DTag, W, FCN) visible to observers reveal communication patterns: the RuleID exposes the compression/fragmentation profile in use, and DTag values identify concurrent packet streams. These fields can contribute to device fingerprinting and traffic analysis on LPWAN networks.

privacy, security

protocol-element §7.1

A SCHC C/D Rule contains an ordered list of Field Descriptors, each specifying: Field Identifier (FID), Field Length (FL), Field Position (FP), Direction Indicator (DI, one of Up/Dw/Bi), Target Value (TV), Matching Operator (MO), and Compression/Decompression Action (CDA). Field Descriptors are ordered as they appear in the packet header.

ip, udp

protocol-element §5.1

A SCHC Packet consists of a Compressed Header (RuleID concatenated with Compression Residue) immediately followed by the original packet payload. Both RuleID and Compression Residue are variable in size and need not be byte-aligned; the Compression Residue may be empty.

ip, udp

protocol-element §7.3

Four Matching Operators are defined: 'equal' (exact field-to-TV match), 'ignore' (always True), 'MSB(x)' (match if the x most-significant bits equal the TV), and 'match-mapping' (match if the field value equals any entry in the TV list, identified by index).

ip, udp

protocol-element §7.4

Seven Compression/Decompression Actions (CDAs) are defined: not-sent (elide, restore from TV), value-sent (send full field), mapping-sent (send index into TV list), LSB (send least-significant bits), compute-* (elide, recompute at decompressor), DevIID (elide, derive IID from L2 Dev address), AppIID (elide, derive IID from L2 App address).

ip, udp

protocol-element §8.2.2

Tiles are non-empty, pairwise disjoint fragments of a SCHC Packet whose union equals the full SCHC Packet. When windows are used, all windows except the last contain exactly WINDOW_SIZE tiles; tile indices within a window decrement from WINDOW_SIZE-1 downward. The FCN All-1 value marks the very last tile; the FCN All-0 value marks the last tile of a non-last window.

ip

security-consideration §12.2.1

A buffer reservation attack sends many fragments with distinct DTag values, exhausting reassembler memory. Receivers that are under-resourced MUST respond with a SCHC Receiver-Abort or MUST silently drop messages they cannot process, to avoid unbounded resource consumption.

security, ip

security-consideration §12.1.1

An attacker who knows the Rules can forge a SCHC Packet. Depending on CDAs used (e.g., not-sent with ignore MO), the decompressed packet may differ from what the original sender would have produced. Network access to SCHC devices should be restricted to legitimate devices.

security, ip

security-consideration §12.2.3

Fragmentation can be exploited to bypass network inspection: individual SCHC Fragments carrying partial packet data cannot be independently inspected by middleboxes. This is analogous to classical IP fragmentation attacks, and the same network-level mitigations apply.

security, ip

security-consideration §12.1.2

The size of a compressed SCHC Packet can act as a side channel: if a secret token (e.g., a one-time password or cookie) appears in a header field compressed with an MSB/LSB CDA, an observer can count the residue bits to narrow down or recover the token value.

security, privacy

state-machine §8.4.2.1

ACK-Always sender alternates between 'blind transmission' (sends all tiles of a window in decreasing FCN order) and 'retransmission phase' (awaits SCHC ACK; retransmits missing tiles; increments Attempts). On Retransmission Timer expiry, if Attempts < MAX_ACK_REQUESTS, sends SCHC ACK REQ; otherwise sends Sender-Abort. Advances to next window only after all tiles confirmed received.

ip

state-machine §8.4.3

ACK-on-Error receiver operates in three phases: 'acceptance phase' (receives fragments, updates Bitmap), 'retransmission phase' (sends SCHC ACK with missing-tile Bitmap, accepts retransmissions), and 'clean-up phase' (responds to late ACK REQs after successful reassembly). Sender and receiver operate in a decoupled fashion; sender may advance to later windows before earlier ones are confirmed.

ip

wire-format §8.3.1.1

A Regular SCHC Fragment header contains: RuleID, optional DTag (T bits), optional W field (M bits), and FCN (N bits). The FCN field MUST NOT contain all bits set to 1 in regular fragments. All regular fragments except the last are intrinsically L2-Word-aligned without padding.

ip

wire-format §8.3.1.2

The All-1 SCHC Fragment header contains: RuleID, optional DTag (T bits), optional W (M bits), FCN with all bits set to 1, optional RCS (U bits), and optional Fragment Payload. At least one of the RCS field or Fragment Payload MUST be present. Only this fragment may require padding.

ip

wire-format §8.3.2.1

The Compressed Bitmap in a SCHC ACK is derived by trimming trailing 1-bits from the right of the full Bitmap until reaching an L2 Word boundary of the SCHC ACK message; bits to the right of that boundary are dropped. The original Bitmap can be reconstructed by the sender because it knows WINDOW_SIZE.

ip

wire-format §8.3.2

The SCHC ACK message contains: RuleID, optional DTag, optional W field, and a 1-bit C field. C=1 signals successful integrity check (no Bitmap follows). C=0 signals failure or no check; if windows are used a Compressed Bitmap for the window referenced by W follows.

ip

wire-format §8.3.5

The SCHC Receiver-Abort shares the SCHC ACK header format (C=1, W=all-ones). After the header, bits are appended to reach the next L2 Word boundary (all set to 1), followed by exactly one additional L2 Word with all bits set to 1. This pattern is guaranteed to never occur in a legitimate SCHC ACK.

ip

wire-format §7.4.2

Variable-length field residues are prefixed with a compact size field: sizes 0–14 are encoded as a 4-bit unsigned integer; sizes 15–254 are encoded as 0b1111 followed by an 8-bit integer; larger sizes use 0xfff followed by a 16-bit integer. The most significant bit of the size is stored leftmost.

ip, udp