Robust Header Compression (ROHC) over PPP

RFC 1332 is explicitly updated to allow multiple instances of the IP-Compression-Protocol configuration option with different values, enabling simultaneous use of ROHC and RFC 2507 TCP compression within a single PPP session.

ip

The LARGE_CIDS parameter from RFC 3095 is not used over PPP; instead, the PPP Data Link Layer Protocol field value (0x0003 vs. 0x0005) determines CID size, allowing a sender to switch CID format packet-by-packet.

ip

There is no need for the ROHC uncompressed profile over PPP because uncompressed packets can always be sent using normal PPP protocol demultiplexing, so no context number needs to be reserved for it.

ip

Two separate PPP protocol field values (0x0003, 0x0005) are defined to keep PPP packets self-describing. This avoids a conflict that would occur if IPCP and IPV6CP each negotiated CID format independently and arrived at different results.

ip

When ROHC is negotiated separately in IPCP and IPV6CP with different parameter values, the effective channel parameters are the logical union (maximum of MAX_CID, MRRU, MAX_HEADER; union of PROFILES sets), because IPCP and IPV6CP together constitute exactly one ROHC channel per PPP link.

ip

For ROHC over PPP links with strong error detection (RFC 1662), setting k_1=n_1=k_2=n_2=1 is recommended, but k/n must remain significantly less than 7/8 to account for the ~1/8 false-positive CRC success rate on damaged contexts.

ip

When using reordering mechanisms such as multiclass multilink PPP (RFC 2686), implementors must ensure that packets sharing the same ROHC compression context are not reordered, as ROHC assumes in-sequence delivery.

ip, multipath

All CIDs within one ROHC packet MUST be of the same size as indicated by the PPP Data Link Layer Protocol field (small or large), including embedded feedback CIDs.

ip

All packets contributing to a ROHC segment MUST be sent with the same Data Link Layer Protocol Field value (0x0003 or 0x0005). A unit reconstructed from packets with differing Protocol field values MUST be discarded.

ip

An outer IPv6 header MUST NOT be sent using ROHC if the ROHC IP-Compression-Protocol option was not negotiated for IPV6CP.

ip, v6ops

Any PPP ROHC receiver MUST be able to process both small-CID and large-CID ROHC packets, so no negotiation of CID format is required between peers.

mpls, ip

ROHC profile 0x0000 (uncompressed) MUST be implemented by all receivers and must not be rejected, per the ROHC specification.

ip

The PROFILES suboption MUST be supplied when negotiating ROHC over PPP. It defines the set of ROHC profiles supported by the decompressor.

ip

When a peer responds with Configure-Nak or Configure-Reject to multiple IP-Compression-Protocol option instances, the sender SHOULD reduce the number of options offered to one.

ip

The ROHC NCP configuration option (Type=2, IP-Compression-Protocol=0x0003) carries MAX_CID, MRRU, MAX_HEADER, and suboptions fields. It is used in both IPCP and IPV6CP to negotiate ROHC parameters.

ip

Two PPP Data Link Layer Protocol Field values are defined: 0x0003 for ROHC small-CID packets and 0x0005 for ROHC large-CID packets, enabling demultiplexing without link-layer type indication.

ip

IANA registry for ROHC suboption identifiers: values 0–127 are reserved for IETF standard-track specifications (Specification Required policy), 128–254 for other qualifying specifications, and 255 is reserved for future extensibility. Identifier 1 (Profiles) is allocated by this document.

registry, ip

Full RTP header compression is possible when only the RTP payload is encrypted (not the UDP/RTP headers), but this method is only appropriate when UDP/RTP header information need not be kept confidential.

security, rtp

Header compression can in rare cases cause misdelivery of packets; when packet confidentiality is required, encryption should be applied. IPsec encryption of IP headers precludes ROHC compression of those headers.

security, ip, ipsec

ROHC channel lifecycle follows PPP NCP state: taking down either IPCP or IPV6CP while the other remains open leaves ROHC contexts active; taking down LCP destroys the channel entirely and restarts ROHC with all contexts in no-context state when LCP is reopened.

ip

PROFILES suboption: Type (1 octet, value 1), Length (1 octet, 2n+2), followed by n octet-pairs in ascending order each identifying a supported ROHC profile.

ip

ROHC configuration option: Type (1 octet, value 2), Length (1 octet, ≥10), IP-Compression-Protocol (2 octets, 0x0003), MAX_CID (2 octets, 0–16383), MRRU (2 octets), MAX_HEADER (2 octets), followed by variable-length suboptions.

ip