IP Payload Compression Protocol (IPComp)
obsoleted by
- rfc-3173 — IP Payload Compression Protocol (IPComp)
Extracted elements (28)
An adaptive algorithm is recommended to avoid performance penalties when previously compressed data (e.g., already-compressed upper-layer payloads) fails to compress further under IPComp.
IP payload compression is especially useful when encryption is applied, because encryption renders lower-layer compression (e.g., PPP CCP) ineffective by making the data appear random; compression must therefore precede encryption.
Stateless (per-datagram) compression is used because IP datagrams may arrive out of order or not at all, making stateful (stream-based) compression impractical.
The non-expansion policy (sending non-compressed if compressed payload is not smaller) is designed to save decompression cycles and avoid IP fragmentation when an expanded datagram would exceed the MTU.
In IPv6, IPComp is placed using the same rules as the IPv6 Fragment Header, but if both are present, the Fragment Header MUST precede the IPComp header.
When negotiating a well-known compression algorithm, nodes MAY select a CPI in the pre-defined range 0-63. Each node independently selects a CPI value for its outbound direction; there is no relationship between the two separately chosen CPIs.
Compression processing MUST be lossless, ensuring that the IP datagram, after being compressed and decompressed, is identical to the original IP datagram.
Dynamic IPCA negotiations SHOULD use ISAKMP where IPSec is present.
If an IPv6 packet contains both an IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header MUST precede the IPComp header.
If both compression and encryption are required, compression MUST be applied before encryption.
If the total size of a compressed ULP payload and IPComp header is not smaller than the original ULP payload, the IP datagram MUST be sent in the original non-compressed form without adding an IPComp header.
In IPComp, compression MUST not apply to hop-by-hop, routing, and fragmentation IPv6 extension headers.
In IPv6, compression MUST be done before the addition of a Hop-by-Hop Options header or a Routing Header, since these must be examined by nodes along the delivery path.
Processing of inbound IP datagrams MUST support both compressed and non-compressed IP datagrams to meet the non-expansion policy requirements.
The compression of outbound IP datagrams MUST be done before any IP security processing (encryption and authentication) and before any fragmentation of the IP datagram.
The decompression of inbound IP datagrams MUST be done after reassembly and after the completion of all IP security processing such as authentication and decryption.
The IPComp header Flags field MUST be set to zero by the sender and MUST be ignored by the receiving node.
The outbound IPComp header MUST use the CPI value chosen by the decompressing node.
The size of a compressed payload generated by the compression algorithm MUST be in whole octet units.
Two nodes MUST first establish an IPComp Association (IPCA) before utilizing the IPComp protocol.
Each IP datagram is compressed and decompressed independently without relation to other datagrams (stateless compression), because IP datagrams may arrive out of order or not arrive at all.
The Compression Parameter Index (CPI) is a 16-bit field identifying the compression algorithm. Values 0-63 are well-known algorithms for manual setup; 64-255 are reserved; 256-61439 are negotiated; 61440-65535 are for private use.
The IPComp Association (IPCA) is the set of parameters required for IPComp operation, including the CPI, mode of operation, compression algorithm, and algorithm parameters. It can be established dynamically (via ISAKMP) or by manual configuration.
The IPv4 Protocol field and IPv6 Next Header field are set to 108 (IPComp Datagram) to indicate an IPComp-encapsulated datagram; the original Next Header/Protocol value is stored in the IPComp header.
To allow IPComp in environments requiring packet filtering, a mechanism must be in place for the receiving node to securely communicate the IPComp Association to the border router.
When IPComp is used in the context of IPSec, it is believed not to degrade or alter the underlying security architecture or the encryption technologies used to implement it.
When IPComp is used without IPSec, it potentially reduces Internet security similar to IP encapsulation: border routers cannot easily filter by header fields because the original Protocol field and transport-layer header fields (e.g., port numbers) are neither in their normal positions nor in their original values after compression.
The IPComp header is a four-octet structure containing: Next Header (8 bits), Flags (8 bits, reserved), and Compression Parameter Index/CPI (16 bits, network order).