The RObust Header Compression (ROHC) Framework

RFC 4995 explicitly separates the ROHC framework from profiles (previously intermingled in RFC 3095) to simplify specification and profile development. Both documents remain independently usable and compatible, but RFC 4995 is intended as the base for all future profiles.

The 3-bit CRC is intentionally weak (probabilistic over multiple packets) and is unsuitable for single-packet context repair validation, while the 7-bit CRC is strong enough to validate a context repair from a single header; profiles should restrict which CRC sizes trigger context repair.

The ROHC segmentation protocol was designed without sequence numbers, relying solely on a 32-bit CRC and in-order delivery; it is not intended to replace link-layer segmentation, which should be preferred whenever available.

CID spaces are distinct per ROHC channel; CID 3 on channel A and CID 3 on channel B refer to different contexts even between the same endpoints, and associated bidirectional channels need not have CID spaces of the same size.

RFC 3095 profiles assume in-order delivery between compressor and decompressor, while ROHCv2 profiles (RFC 4996 companion) assume out-of-order delivery is possible; implementations mixing profile generations must respect these distinct ordering assumptions.

Acktype value 3 in FEEDBACK-2 is reserved and MUST NOT be used, as it is otherwise unparseable.

An IR-DYN packet MUST NOT be decompressed and delivered to upper layers if the context has not already been initialized.

At least one of Feedback or Header MUST be present in a ROHC packet.

If a non-segment ROHC packet directly follows a non-final segment, the decompressor MUST discard the non-final segments received so far on the channel, aborting reassembly.

If a parsing error occurs for any packet type, the decompressor MUST discard the packet without further processing.

If MRRU is negotiated to be 0, segmentation MUST NOT be used on the channel, and received segments MUST be discarded by the decompressor.

If the 8-bit CRC fails to verify an IR or IR-DYN header, the packet MUST NOT be decompressed and delivered to upper layers.

security

ROHC segmentation MUST NOT be used if in-order delivery between compressor and decompressor cannot be guaranteed, since the segmentation protocol assumes in-order delivery.

The 8-bit CRC in IR and IR-DYN headers MUST cover at least the initial part of the header ending with the Profile field, including the CID or Add-CID octet.

security

The CID space (small: 0-15, or large: 0-16383) MUST be established, possibly by negotiation, before any compressed packet may be sent over the ROHC channel.

security

The large CID field in a feedback element MUST NOT be encoded using more than 2 octets.

The PROFILES set after negotiation MUST NOT include more than one variant of the same profile (same 8 LSBs), and the compressor MUST NOT compress using a profile not in PROFILES.

The reconstructed unit MUST be discarded if it is 4 octets or less, if the 32-bit CRC fails, or if it is larger than the channel parameter MRRU.

The ROHC channel state MUST be established before the first ROHC packet may be sent; the decompressor MUST maintain established contexts within the MAX_CID space until the CID gets re-used or the channel is taken down.

ROHC defines three feedback message categories: ACK (successful decompression, context valid), NACK (dynamic context partially or fully invalid), and STATIC-NACK (entire static context invalid or unestablished). Feedback is encoded as FEEDBACK-1 (1 octet) or FEEDBACK-2 (at least 2 octets with Acktype field).

The IR-DYN packet can redefine the profile associated with an existing context but cannot initialize a non-initialized context; it has the same general format as IR with type octet 11111000.

The IR packet associates a CID with a profile and initializes or refreshes context; it carries an 8-bit CRC, a 1-octet Profile field (8 LSBs of profile identifier), optional CID octets, and profile-specific information of variable length.

The ROHC channel is a logical unidirectional point-to-point channel parameterized by LARGE_CIDS, MAX_CID, PROFILES, FEEDBACK_FOR, and MRRU. These parameters MUST be established before the first packet is sent, via negotiation, static provisioning, or out-of-band signaling.

The ROHC UNCOMPRESSED profile (0x0000) provides two packet types: an IR packet to initialize context, and a Normal packet that carries an uncompressed IP packet plus CID information with no further compression overhead beyond the CID.

IANA maintains the 'RObust Header Compression (ROHC) Profile Identifiers' registry. New assignments require Specification Required; LSBs 0-127 are reserved for IETF standards-track, 128-254 for other specifications, 255 reserved for future extensibility. Allocated identifiers include 0x0000 (uncompressed, RFC 4995) through 0x0008 (UDP-Lite, RFC 4019).

registry

A malfunctioning or malicious header compressor could cause the decompressor to reconstitute packets with valid headers that do not match originals; end-to-end authentication and integrity mechanisms are unaffected by compression and can detect such corruption. ROHC's internal CRCs reduce the probability of undetected incorrect decompression.

security

Denial-of-service attacks are possible if an intruder injects bogus IR, IR-DYN, or FEEDBACK packets onto the link, causing compression efficiency to degrade; however, such link-layer injection capability implies broader security issues beyond header compression.

security

Encryption eliminates the redundancy that header compression exploits, creating an inducement to forego header encryption on low-bandwidth links; implementers should weigh this trade-off carefully.

security, privacy

Decompressor context states: 'no context' (uninitialized) transitions to 'initialized' upon successful reception and CRC validation of an IR packet; IR-DYN can update an initialized context but cannot transition from 'no context'. Context is reset when IR arrives with a different profile.

Self-describing variable-length values use 1-4 octets: prefix 0 encodes 7 bits (0x00-0x7F), prefix 10 encodes 14 bits (0x8000-0xBFFF), prefix 110 encodes 21 bits, prefix 111 encodes 29 bits.

The Add-CID octet has the fixed prefix 1110 in bits 0-3 and carries 4 bits of CID (values 1-15) in bits 4-7; it encodes small CIDs 1 through 15 and immediately precedes the packet type indication.

The Feedback element format starts with type octet (11110|Code), an optional Size octet when Code=0, optional Add-CID or large CID, and a variable-length FEEDBACK data field (FEEDBACK-1: 1 octet; FEEDBACK-2: ≥2 octets with 2-bit Acktype).

The framework reserves specific packet type bit patterns: 11100000 (Padding), 1110nnnn (Add-CID), 11110 (Feedback), 11111000 (IR-DYN), 1111110 (IR), 1111111 (Segment); bit patterns starting with 0, 10, 110, 1111101, and 11111001 are available for profiles.

The Padding octet is encoded as 11100000 (0xE0) and MUST NOT be interpreted as an Add-CID octet for CID 0; zero or more padding octets may precede Feedback or Header in any ROHC packet.

The ROHC segment format has a 1-octet type field (1111111F) where the F bit indicates the final segment; segment payload is variable length; reconstructed unit ends with a 4-octet CRC.