rfc-6846

RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)

G. Pelletier, K. Sandlund, L-E. Jonsson, M. West
date2013-01 streamIETF wgnon working group statusPROPOSED STANDARD pages96 canonicalhttps://www.rfc-editor.org/rfc/rfc6846 doi10.17487/RFC6846 errataview
This document specifies a RObust Header Compression (ROHC) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as selective acknowledgments (SACKs) and Timestamps. ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. [STANDARDS-TRACK]

obsoletes

Extracted elements (30)

design-rationale §6.4.8

For TCP sequence number scaling, the payload size serves as the scaling factor and is inferred by the decompressor from the payload length—no explicit transmission needed. For ACK number scaling, an explicit ack_stride is transmitted because the opposite-direction packet sizes required to derive the stride may not be locally available to the compressor.

tcp

design-rationale §6.1.1

No TCP header field is suitable as a master sequence number—unlike UDP/IP profiles—because the TCP Sequence Number may fluctuate within the TCP window due to retransmissions and is not monotonically increasing per compressed packet. ROHC-TCP therefore introduces the compressor-created MSN field as a stable per-packet reference for feedback correlation and IP-ID inference.

tcp, ip

design-rationale §6.1.3

When the ECN control field is set, ECN bits from all IP headers (not just the innermost) are included in the irregular chain. This is necessary to efficiently support the RFC 3168 'full-functionality option' in tunneled flows, where inner IP ECN bit changes propagate to outer headers. For 'limited-functionality' flows this wastes one extra octet per tunnel header, a trade-off the designers accepted.

tcp, ip, ecn

errata §9

RFC 6846 obsoletes RFC 4996 primarily to fix a technical issue with SACK compression. Section 9 documents both functional changes (SACK fix and encoding clarifications) and non-functional changes relative to RFC 4996.

tcp

interoperability-note §4.2.2

ROHC-TCP assumes that if a feedback channel is used at least once for a specific context, it will be available for the entire compression operation for that context. If the feedback channel disappears after being established, compression for the affected context should be restarted.

tcp, ip

interoperability-note §4.2.2

ROHC-TCP's feedback mechanism using LSB-encoded MSN bits in FEEDBACK-2 is not suitable when MSN bits could wrap around within one round-trip time. In such environments, unidirectional operation—where the compressor periodically sends larger context-updating IR/IR-DYN packets—is more appropriate than using feedback.

tcp, ip

normative-requirement §6.3.5 MUST

A compressed list of TCP options that is part of the dynamic chain (IR or IR-DYN packets) must have all list items present; all X-bits in the XI list MUST be set, ensuring the full options context is transmitted during initialization.

tcp

normative-requirement §6.1.2 MUST NOT

A compressor MUST NOT assign sequential (NBO) or sequential byte-swapped IP-ID behavior to outer (tunneling) IP headers. Only the innermost IP header's IP-ID may be treated as sequentially changing, because only it has sufficient correlation with the MSN.

ip, tcp

normative-requirement §6.3.2 MUST

If a decompressor receives an index without an accompanying item in a compressed list and has no context entry for that index, the header MUST be discarded and a NACK SHOULD be sent.

tcp

normative-requirement §5.2.1.1 MUST

If field X changes value, the compressor MUST use a packet type containing an encoding for X until it is confident the decompressor has received at least one packet with the new value. The compressor SHOULD choose the compressed format with the smallest header that can convey the required changes (the optimistic approach).

tcp, ip

normative-requirement §5.3.1.3 MUST NOT

In the NC state, only IR and IR-CR packets may be decompressed; any other packet type MUST NOT be decompressed or delivered to upper layers. Successful decompression in NC MUST cause an immediate transition to the FC state.

tcp, ip

normative-requirement §5.2.2.2 SHOULD

On NACK reception, the compressor SHOULD assume only the static context is valid and re-send all dynamic information via IR or IR-DYN the next time it compresses for that flow, unless it is already confident that subsequently sent packets provide a suitable response.

tcp, ip

normative-requirement §5.2.2.2 SHOULD

On STATIC-NACK reception, the compressor SHOULD assume the decompressor has no valid context and re-send all static and dynamic information via an IR packet next time it compresses for that flow, unless subsequent packets already provide a suitable response.

tcp, ip

normative-requirement §5.3.2 REQUIRED

Once a feedback channel is established for a context, the decompressor is REQUIRED to continue sending NACKs or STATIC-NACKs for as long as the context is associated with profile 0x0006, following the state-specific feedback logic defined in Section 5.3.1.

tcp, ip

normative-requirement §6.4.8 MUST NOT

The compressor MUST NOT use scaled encoding with a scaling_factor of zero. If the residue changes or a different scaling factor is used, scaled encoding MUST NOT be applied until the decompressor has received the updated values; this also applies when the unscaled field wraps around.

tcp, ip

normative-requirement §5.2.1.2 SHOULD

Until the decompressor has established a feedback channel, the compressor SHOULD periodically send IR and/or IR-DYN packets to refresh the context, based on timeouts, packet counts, or other implementation-specific strategies. Once feedback is established, the compressor MAY stop periodic refreshes.

tcp, ip

normative-requirement §5.3.1.1 MUST

When decompressing IR or IR-DYN packets, the decompressor MUST validate header integrity using CRC-8; on failure the packet MUST NOT be delivered to upper layers. For CO packets, CRC verification MUST be performed; repair attempts must also pass CRC verification before delivery, and the context MUST NOT be updated on any failure.

tcp, ip, security

protocol-element §6.2

ROHC-TCP defines four chain types for each compressed header: static chain (IR packets only), dynamic chain (IR and IR-DYN), replicate chain (IR-CR only), and irregular chain (CO packets only). Each chain groups header fields by characteristic—static, dynamic, replicable, or irregular—and is assembled by appending one item per header in order of appearance.

tcp, ip

protocol-element §6.1.2

ROHC-TCP defines four IPv4 IP-ID compression behaviors: sequential network byte order (NBO), sequential byte-swapped, random (RND), and constant zero. A control field tracks which behavior is active and determines the set of packet formats and irregular chain contents for each IP header.

ip, tcp

protocol-element §6.1.3

The ECN control field in the TCP dynamic chain indicates whether ECN (RFC 3168) is in use for the flow. When set, all IP and TCP headers in the irregular chain include ECN bits; to preserve octet alignment, all TCP reserved bits and the full TOS/TC field of outer IP headers are also included.

tcp, ip, ecn

protocol-element §6.1.1

The Master Sequence Number (MSN) is a compressor-created control field absent from the TCP header. It is incremented by one per packet sent, transmitted as a 16-bit value in IR/IR-DYN packets and LSB-encoded in CO packets. It serves two functions: differentiating packets when sending feedback, and inferring incrementing fields such as IP-ID.

tcp, ip

protocol-element §1

The profile identifier for ROHC-TCP (TCP/IP compression) is 0x0006. This value is carried in IR and IR-CR packets to identify the compression profile and is used when initializing a context with profile number 0x06.

tcp, ip

protocol-element §6.3.4

The TCP option item table maps well-known options to fixed indices: NOP=0, EOL=1, MSS=2, WINDOW SCALE=3, TIMESTAMP=4, SACK-PERMITTED=5, SACK=6, and Generic options=7-15. The table is limited to 16 entries. Both compressor and decompressor MUST use these fixed mappings when performing list compression of TCP options.

tcp, registry

registry §11

ROHC-TCP uses profile identifier 0x0006, registered in the IANA ROHC Profile Identifiers registry. Section 8.3.2 defines four feedback options for FEEDBACK-2: REJECT, MSN-NOT-VALID, MSN, and CONTEXT_MEMORY, used within the ROHC feedback option registry.

registry, tcp, ip

security-consideration §10

ROHC-TCP uses CRC computed over the reconstructed headers as the primary integrity verification mechanism at the decompressor; a corrupted or injected compressed packet that passes CRC may update the decompressor context incorrectly. The IPv4 header checksum is not transmitted and is recomputed at the decompressor—this is safe only if the compressor does not forward a corrupted header, as an undetected corruption would cause the recomputed checksum to differ from the original.

tcp, ip, security

state-machine §5.3.1

The decompressor operates in three states: No Context (NC), Static Context (SC), and Full Context (FC). It always starts in NC; successful decompression always transitions it to FC. Repeated CRC failures cause downward transitions: FC to SC on dynamic context damage, SC to NC on static context damage.

tcp, ip

wire-format §6.3.3

Each XI item in a compressed list encodes an X bit (1 = full item present in this list, 0 = item carried in the irregular chain instead) and an Index into the item table. 4-bit XI (PS=0) packs two per octet; 8-bit XI (PS=1) uses one octet with 3 reserved bits and a 4-bit Index.

tcp

wire-format §6.3.3

The compressed list of TCP options uses a 1-octet header encoding Reserved(3 bits, MUST be zero), PS(1 bit, selects 4-bit or 8-bit XI fields), and m(4 bits, count of XI items). This is followed by m XI items, optional 4-bit padding when PS=0 and m is odd, and variable-length item data for options whose X bit is set.

tcp

wire-format §7.1

The IR-DYN packet carries only the dynamic chain. Its type octet is 0xF8 (11111000 binary), followed by 0-2 CID octets, a 1-octet Profile=0x06, a 1-octet 8-bit CRC covering the entire IR-DYN header, a variable-length dynamic chain, and optional payload.

tcp, ip

wire-format §7.1

The IR packet carries the full static and dynamic chains. Its type octet is 0xFD (11111101 binary), followed by 0-2 CID octets (large CID mode), a 1-octet Profile=0x06 field, a 1-octet 8-bit CRC covering the entire IR header, a variable-length static chain, a variable-length dynamic chain, and optional payload.

tcp, ip