RObust Header Compression (ROHC): A Compression Profile for IP
updated by
- rfc-4815 — RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095
Extracted elements (23)
No IP-only compression profile existed in RFC 3095, which only defined profiles for IP/UDP/RTP, IP/ESP, IP/UDP, and uncompressed streams. The uncompressed profile could tunnel arbitrary packets but provided no header compression, creating a gap for IP-only traffic that this document fills.
RFC 3095's general compressed header formats support at most two levels of IP headers (Inner and Outer), and list compression cannot be used for additional IP headers. The IP-only profile overcomes this limitation by appending a dynamic chain of header portions for each IP level beyond the first two, enabling compression of arbitrary IP header chain depths.
Some IPv4 stacks use a constant value for the IP Identifier field. Standard offset IP-ID encoding cannot compress a constant IP-ID, and sending it uncompressed wastes bandwidth. The SID flag was introduced to signal this condition and allow the IP-ID to be omitted from compressed packets entirely.
The mode transition cancellation mechanism (Mode=0 meaning 'Cancel') was introduced because RFC 3095 compels the compressor to honor all mode transition requests from the decompressor. For IP-only streams, it was deemed useful to allow the compressor to decline such requests and keep the current compression mode.
Profile 0x0004 is based on the ROHC UDP profile (0x0002) from RFC 3095 with UDP removed and extensions for arbitrary IP header chain depth. Implementations must follow RFC 3095 mechanisms and formats except where explicitly overridden by this document.
D_MODE MUST remain unchanged when receiving a UOR-2, IR-DYN, or IR packet sent with the mode parameter set to '0' (cancel mode transition).
The decompressor must store the explicit chain termination indication (MSB of IP version field set to 1) in the context for correct decompression of subsequent headers, and must restore the IP version field to its original value in decompressed headers.
Upon receiving the Mode parameter set to '0' (Cancel Mode Transition), the decompressor MUST stay in its current mode of operation and SHOULD refrain from sending further mode transition requests for the declined mode for a certain amount of time.
When receiving a CONTEXT_MEMORY option, the compressor SHOULD take actions to compress the packet stream in a way that requires less decompressor memory, or stop compressing the packet stream.
For compressed headers in profile 0x0004, information for the initial two IP headers is carried as in ROHC UDP, and a variable-length chain of dynamic header information is appended for each additional IP header beyond the first two. The length of this chain is inferred from the static chain in context.
For IP-only compression, the static chain in IR headers is terminated when the 'Next Header / Protocol' field indicates anything other than IP (IPinIP or IPv6). Alternatively, the compressor may explicitly terminate the chain by setting the MSB of the IP version field to 1 (0xC for IPv4, 0xE for IPv6), and the decompressor must store this indication in context while restoring the original IP version value in decompressed headers.
In IR and IR-DYN packets for profile 0x0004, a two-octet SN field is present at the end of the dynamic chain, added only once regardless of the number of IP levels. The static and dynamic chains may be of arbitrary length.
ROHC IP context initialization can be performed either via an IR packet (profile 0x0004, static chain ending at a non-IP Next Header) or by reusing an existing context via an IR-DYN packet. In both cases, SN is initialized to a random value when the first such packet is sent.
The CONTEXT_MEMORY feedback option (Opt Type=9, Opt Len=0, 1 octet total) informs the compressor that the decompressor lacks sufficient memory to handle the current context. It is a new feedback option introduced by profile 0x0004.
The IP-ID compression logic for compressed headers (non-IR/IR-DYN): if RND=0 and SID=0, IP-ID is compressed using Offset IP-ID encoding with p=0 and default-slope=0; if RND=0 and SID=1, IP-ID is constant and omitted, reconstructed from context; if RND=1, IP-ID is sent uncompressed as additional octets after the compressed header.
The Mode parameter value 0 in UOR-2, IR, and IR-DYN packets is redefined for profile 0x0004 to mean 'Cancel Mode Transition' (C), allowing the compressor to decline a mode transition requested by the decompressor, rather than the mode-0 meaning used in RFC 3095.
The ROHC IP compression profile (0x0004) generates a 16-bit sequence number (SN) that increases by one for each compressed packet, analogous to ROHC UDP. The most important differences from ROHC UDP are static chain termination and handling of multiple IP headers.
The SID (Static IP Identifier) flag indicates that the IPv4 IP-ID field is constant. When context(SID)=1 and RND=0, the IP-ID is compressed away entirely and reconstructed from context. Only IR and IR-DYN packets can update context(SID).
ROHC profile identifier 0x0004 has been reserved by IANA for the IP-only compression profile defined in this document.
The security considerations of RFC 3095 apply equally to this document without exceptions or additions. No new security issues specific to the IP-only compression profile are identified.
Mode transition cancellation procedure: Compressor sets C_TRANS=Pending on receiving mode request, sends IR/IR-DYN/UOR-2 with Mode=C (cancel), decompressor sets D_TRANS=Pending and keeps D_MODE unchanged; compressor sets C_TRANS=Done upon receiving ACK for that packet; decompressor sets D_TRANS=Done upon receiving packet type 0 or 1.
The general compressed packet format for profile 0x0004 omits the UDP checksum present in ROHC UDP. Instead, it ends with a variable-length list of dynamic chains for additional IP headers (beyond the first two), with no SN at the end of this list since SN appears in the compressed base header.
The IPv4 dynamic header part adds a SID (Static IP Identifier) flag in a flag byte alongside the existing DF, RND, and NBO flags. The dynamic part contains: Type of Service (1 octet), Time to Live (1 octet), Identification (2 octets), a flags byte with DF/RND/NBO/SID fields, and a variable-length generic extension header list.