The RObust Header Compression (ROHC) Framework
obsoletes
- rfc-4995 — The RObust Header Compression (ROHC) Framework
Extracted elements (32)
The 3-bit CRC is intentionally weak—useful only for probabilistic context damage detection across multiple packets—while the 7-bit CRC is strong enough to validate a context repair from a single packet. This distinction drives the rule that headers with only a 3-bit CRC should not be used for context repair after context invalidation.
The ROHC framework and profile specifications were separated into distinct documents (this document and RFC 5225) to address implementer feedback that RFC 3095 was complex and obscure, and to make development of additional profiles more tractable. The framework definition does not modify RFC 3095's framework, so implementations of both are interoperable.
RFC 4995 erroneously redefined the Size field in ROHC feedback to mean the size of the FEEDBACK data only (excluding the CID field), diverging from RFC 3095. RFC 5795 corrects this: the Size field indicates the total size of the FEEDBACK data field and the CID field combined, restoring interoperability.
RFC 5795 fixes an interoperability issue erroneously introduced in RFC 4995: the Size field in ROHC feedback now correctly indicates the total size of the FEEDBACK data field and the CID field combined, consistent with RFC 3095. Implementations based on RFC 5795 and RFC 3095 are compatible and interoperable; RFC 4995 implementations using the incorrect Size interpretation are not.
ROHCv1 profiles (RFC 3095) assume in-order delivery between compressor and decompressor; ROHCv2 profiles (RFC 5225) are designed to tolerate out-of-order delivery. Both handle reordering before the compression point.
A 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 MRRU channel parameter.
At least one of Feedback or Header MUST be present in each ROHC packet; a packet containing neither is invalid.
If a parsing error occurs for any packet type, the decompressor MUST discard the packet without further processing; for example, a large CID field encoded with more than 2 octets (first bits 110 or 111) triggers a parsing error.
If an IR-DYN packet is received but the context has not already been initialized, the packet MUST NOT be decompressed and delivered to upper layers.
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 the integrity of an IR or IR-DYN header, the packet MUST NOT be decompressed and delivered to upper layers.
It is RECOMMENDED that profiles disallow the decompressor from attempting decompression of packets carrying only a 3-bit CRC after the dynamic context has been invalidated, until a packet with a 7- or 8-bit CRC is successfully verified.
ROHC segmentation MUST NOT be used if in-order delivery between the compressor and decompressor cannot be guaranteed, because the protocol uses only a CRC for error detection and has no sequence numbers.
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 any CID or Add-CID octet; padding and feedback are excluded.
The Acktype value 3 in FEEDBACK-2 is reserved and MUST NOT be used; its use would make the feedback unparsable.
The decompressor MUST maintain established contexts within the negotiated MAX_CID space until either the CID is re-used by a new context or the channel is taken down. 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.
Whether the CID space is large (0–16383) or small (0–15) MUST be established, possibly by negotiation, before any compressed packet may be sent over the ROHC channel.
Profile 0x0000 (ROHC UNCOMPRESSED) allows IP packets to be sent without compression, using only CID overhead. It supports IR packets (with optional embedded IP packet) and Normal packets (raw IP with CID prefix); the only feedback defined is ACK via FEEDBACK-1 with a zero octet.
ROHC defines three feedback types: ACK (successful decompression, context valid), NACK (dynamic part of context considered invalid), and STATIC-NACK (entire static context invalid or not established). Additional types may be defined per profile.
The ROHC channel is parameterized by: LARGE_CIDS (boolean, selects small CID 0–15 vs. large CID 0–16383), MAX_CID (highest CID the compressor may use), PROFILES (set of mutually-negotiated 16-bit profile identifiers), FEEDBACK_FOR (optional reference to reverse channel), and MRRU (maximum reconstructed unit size for segmentation). These MUST be established before the first packet.
The 'RObust Header Compression (ROHC) Profile Identifiers' registry was created by RFC 3095 and is maintained by IANA. New values require Specification Required policy; 8-LSB values 0–127 are reserved for IETF Standards Track, 128–254 for other specifications, and 255 is reserved for future extensibility.
A malfunctioning or malicious compressor could cause the decompressor to reconstruct packets with valid headers but mismatched content; ROHC's internal CRC reduces this probability, and end-to-end authentication and integrity mechanisms provide further protection. An attacker injecting bogus IR, IR-DYN, or feedback packets can degrade compression efficiency as a DoS attack.
Encryption eliminates header redundancy and thus creates an incentive to forgo header encryption to enable compression over low-bandwidth links, which is a potential security trade-off operators should be aware of.
A feedback element begins with a 1-octet feedback type field (11110|Code); Code 0 means a Size octet follows indicating total CID+data length in octets; Code 1–7 encodes the length directly. An optional Add-CID or large CID field follows, then variable-length FEEDBACK data.
Each ROHC segment has a 1-octet type field (1111111F) where F is the Final bit; a 4-octet 32-bit CRC is appended at the end of the last segment's reconstructed unit. Segments carry no per-segment CID.
FEEDBACK-2 starts with a 2-bit Acktype field (0=ACK, 1=NACK, 2=STATIC-NACK, 3=reserved) in the first octet, followed by at least 2 octets total of profile-specific information.
Four CRC variants are defined: 8-bit (polynomial x^8+x^2+x+1, covers IR/IR-DYN header integrity), 3-bit (polynomial x^3+x+1, compressed header verification), 7-bit (polynomial x^7+x^6+x^3+x^2+x+1, stronger compressed header verification), and 32-bit (PPP-style polynomial, segmentation CRC). All initialize the CRC register to all 1s.
Self-describing variable-length (SDVL) encoding uses 1–4 octets: first bit 0 → 7 bits (up to 127); first bits 10 → 14 bits (up to 16383); first bits 110 → 21 bits; first bits 111 → 29 bits. Large CIDs are restricted to a maximum of 2 octets under this scheme.
The Add-CID octet encodes CIDs 1–15 in the low 4 bits with the fixed prefix 1110 in the high 4 bits; it is 1 octet in length and is used only in the small CID space.
The IR-DYN header format is similar to IR but uses a fixed type octet of 11111000; it cannot initialize a non-initialized context, though it can refresh or redefine a profile on an existing context.
The IR header format includes: optional Add-CID octet, a type octet (1111110x), 0–2 octets of large CID, a 1-octet Profile field (8 LSBs of profile identifier), a 1-octet 8-bit CRC, and variable-length profile-specific information.
The Padding octet is encoded as the fixed 8-bit pattern 11100000 (0xE0). It MUST NOT be interpreted as an Add-CID octet for CID 0, even though it shares the same bit pattern.