rfc-2507

IP Header Compression

M. Degermark, B. Nordgren, S. Pink
date1999-02 streamIETF areaint wgipngwg statusPROPOSED STANDARD pages47 canonicalhttps://www.rfc-editor.org/rfc/rfc2507 doi10.17487/RFC2507
This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. [STANDARDS-TRACK]

Extracted elements (27)

design-rationale §3.3.4

A soft-state scheme using periodic header refreshes with exponential backoff (compression slow-start) is chosen over a hard-state scheme requiring acknowledgment of full headers. The soft-state approach needs no handshake, works over simplex links (satellite, cable TV), and handles mobiles going out of range transparently, at the cost of slightly higher bandwidth for header refreshes.

ip

design-rationale §3.3.1

After a context change in a non-TCP stream, full headers are sent with an exponentially increasing interval (F_PERIOD starts at 1, doubles each time, up to F_MAX_PERIOD=256). The default F_MAX_PERIOD of 256 means full headers contribute less than 1.4 bits to the average header size at steady state, a negligible overhead.

ip

design-rationale §7.6

The Fragment Header Identification field is classified as RANDOM rather than NOCHANGE to avoid triggering a compression slow-start for every new original IP packet. Fragment streams are identified by source and destination address alone, not the Identification field.

ip

design-rationale §6

The R-octet carrying ECN bits (bits 6–7 of TOS/Traffic Class) and the TCP Reserved field MUST NOT update the context because if it did, the TCP checksum would no longer reliably catch erroneously decompressed headers. ECN bits are expected to change frequently due to Explicit Congestion Notification.

ip, tcp, ecn

interoperability-note §5.3

Header compression requires that the link layer provide accurate packet length and add no deliverable padding to payloads, and that UDP packets and tunneled packets contain no extra padding. These properties are needed to infer length field values and embed CID and generation in full headers without increasing packet size.

ip, udp

interoperability-note §5.1

On multi-access links, multiple compressors share a single decompressor's CID space, creating collision risk. Resolution approaches include per-compressor CID namespaces (using link-layer sender identity) or including a compressor-assigned enumeration number as part of the CID, which requires the 16-bit CID size.

ip

interoperability-note §3.2

This compression scheme is compatible with TCP's repair mechanisms: the compressor inspects TCP headers to detect retransmissions and sends a full header on retransmit, assuming the retransmission was caused by mismatched compression state. The compression method does not require that all packets in the same stream traverse the compressed link.

ip, tcp

interoperability-note §7.10

When an ESP header is used in tunnel mode, inner IP packet headers MAY be compressed before encryption at the tunnel entry point. The reordering mechanisms from section 11 MUST also be applied, since packets can be reordered inside the tunnel.

ip, ipsec, vpn

normative-requirement §8 MUST

A compressor MUST ensure that the generation value for a non-TCP CID does not wrap around in less than MIN_WRAP seconds. The generation MUST NOT be reset when a CID is reused for a new packet stream; instead it MUST be incremented by one.

ip

normative-requirement §10.2 SHOULD NOT

A decompressor SHOULD NOT send a CONTEXT_STATE packet every time a compressed packet refers to an invalid context; instead it should rate-limit such transmissions. Multiple invalid CIDs SHOULD be batched into a single CONTEXT_STATE packet rather than sending separate packets.

ip, tcp

normative-requirement §3.3 MUST

A decompressor that has been disconnected for more than MIN_WRAP seconds MUST wait for the next full header before decompressing non-TCP compressed headers. A compressor MUST wait at least MIN_WRAP seconds after booting before compressing non-TCP headers.

ip

normative-requirement §5.2 MUST NOT

An implementation MUST NOT compress more than the initial MAX_HEADER octets of a header and MUST NOT partially compress a subheader. The compressed portion is the longest initial sequence of complete subheaders whose total size does not exceed MAX_HEADER.

ip

normative-requirement §7.12.1 MUST

DELTA values for TCP sequence number, acknowledgment number, window, and urgent pointer MUST be coded as specified in RFC 1144. A Reserved field value passed via the R-flag MUST NOT update the context at either compressor or decompressor.

ip, tcp

normative-requirement §3 SHOULD NOT

Header compression SHOULD NOT be used for IPv4 without strong link-level checksums. Damaged frames discarded by the link layer can corrupt context state, leading to persistent incorrect decompression for an entire TCP sending window.

ip, security

normative-requirement §10.2 MUST

On receipt of a CONTEXT_STATE packet, the compressor MUST mark the listed CIDs invalid so that the next packet on each of those streams is a FULL_HEADER or COMPRESSED_TCP_NODELTA packet.

ip, tcp

normative-requirement §7.6 MUST NOT

The chain of subheaders following a Fragment Header MUST NOT be compressed, because fragments can arrive out of order and the compressor cannot reliably examine inner subheaders for stream identification.

ip

normative-requirement §9 MUST

When a decompressor receives a compressed TCP header whose CID has not been initialized by a full header, the packet MUST be discarded. For non-TCP packets whose CID context has a different generation than the packet carries, the packet must either be discarded immediately or stored temporarily until a matching full header arrives.

ip, tcp

protocol-element §5.1

A Context Identifier (CID) is an 8- or 16-bit number identifying which stored context to use for decompression. The CID spaces for TCP and non-TCP packet streams are separate, so a TCP CID and a non-TCP CID with the same value never identify the same context, effectively doubling the available CID space.

ip

protocol-element §3

A generation is a 6-bit value carried in full and compressed non-TCP headers that identifies the version of the context for a given CID. The generation is incremented whenever the context changes; compressed headers carry the generation so the decompressor can detect stale or mismatched context without requiring a handshake.

ip, udp

protocol-element §3.1

Five packet types are defined: FULL_HEADER (uncompressed header with CID and, for non-TCP, a generation), COMPRESSED_TCP (differential-encoded TCP header with a flag octet), COMPRESSED_NON_TCP (compressed non-TCP header with CID and generation), COMPRESSED_TCP_NODELTA (full TCP field values without differential encoding, sent only in response to header requests), and CONTEXT_STATE (sent from decompressor to compressor to signal lost synchronization on listed TCP CIDs).

ip, tcp, udp

protocol-element §7

Four field classifications govern how each subheader field is treated during compression: NOCHANGE (constant; any change forces a full header), DELTA (predictably changing; encoded as difference from previous value; TCP streams only), RANDOM (unpredictable; sent as-is in every compressed header), and INFERRED (derivable from link-layer frame size or other fields; omitted entirely).

ip, tcp, udp

protocol-element §10.1

The 'twice' algorithm allows a decompressor to repair a corrupted TCP context without a round-trip: after a TCP checksum failure, the decompressor re-applies the current segment's delta one or two additional times and recomputes the checksum to verify success. Analysis of TCP traces shows 83–99% repair success for data streams; success is lower (53–99%) for acknowledgment streams.

ip, tcp

security-consideration §17

Header compression does not introduce new security vulnerabilities. The Authentication Header's Authentication Data field is classified as RANDOM and transmitted as-is in every compressed header, preserving its integrity guarantee. The ESP header ends the compressible chain because subsequent data is encrypted, ensuring confidentiality is not weakened.

security, ip, ipsec

wire-format §5.3

Full headers embed CID and generation in existing length fields to avoid increasing packet size. The generation occupies the high-order octet of the first available length field; an 8-bit CID occupies the low-order octet of that same field; a 16-bit CID additionally uses the second available length field.

ip

wire-format §6

The COMPRESSED_NON_TCP header with 8-bit CID is: 1 octet CID, 1 octet '0|D|Generation' (6-bit generation), optional 1-octet data (if D=1), then RANDOM fields. The 16-bit CID variant reorders to: MSB of CID, '1|D|Generation', LSB of CID, optional data, then RANDOM fields.

ip, udp

wire-format §6

The COMPRESSED_TCP header starts with an 8-bit CID, then an 8-bit flag octet (R O I P S A W U), then a 16-bit TCP checksum, followed in order by: RANDOM fields implied by context, optional R-octet (if R=1), Urgent Pointer absolute value (if U=1), Window Delta (if W=1), Acknowledgment Number Delta (if A=1), Sequence Number Delta (if S=1), IPv4 Identification Delta (if I=1), and full Options/Padding (if O=1).

ip, tcp

wire-format §10.2

The CONTEXT_STATE packet begins with a 1-octet type code (value 3 for TCP header requests), followed by a 1-octet count of CIDs, then that many 1-octet CIDs identifying TCP streams that have lost synchronization. The packet requires no IP header because it is sent over a single link.

ip, tcp