IP Payload Compression Protocol (IPComp)
obsoletes
- rfc-2393 — IP Payload Compression Protocol (IPComp)
Extracted elements (25)
An adaptive algorithm should be implemented to avoid the performance hit of repeatedly attempting compression on previously compressed payloads; if i consecutive compressions fail, the next k datagrams are sent uncompressed, increasing the skip count on subsequent failures.
IP payload compression is especially useful when encryption is applied, because encryption renders compression at lower protocol layers (e.g., PPP CCP) ineffective. If both compression and encryption are required, compression must be applied before encryption.
Small IP datagrams are likely to expand as a result of compression, so a numeric threshold should be applied before compression; IP datagrams smaller than the threshold are sent in original form. The threshold is implementation dependent.
IPCAs become non-unique when two or more IPComp sessions are established between two nodes using the same well-known CPI. To ensure uniqueness when multiple IPCAs use the same algorithm, CPIs SHOULD be in the negotiated range (256-61439).
When proposing well-known CPIs via IKE, a Proposal Payload with a single Transform Payload may use a pre-defined CPI (0-63). When two or more Transform Payloads are present in one Proposal Payload, the CPI MUST be in the negotiated range (256-61439).
An IPComp proposal MUST include an Encapsulation Mode attribute when proposing a non-default mode (such as Tunnel Mode); the default is Transport Mode. An IPComp proposal MUST NOT be rejected because it lacks attributes of other protocols in a Protection Suite.
Compression of outbound IP datagrams MUST be done before any IP security processing (encryption and authentication) and before any fragmentation. In IPv6, compression MUST also precede addition of Hop-by-Hop Options or Routing Headers.
Compression processing MUST be lossless, ensuring that the IP datagram, after being compressed and decompressed, is identical to the original IP datagram.
Decompression of inbound IP datagrams MUST be done after reassembly and after completion of all IP security processing (authentication and decryption).
Dynamic IPCA negotiations SHOULD use the Internet Key Exchange (IKE) protocol where IPsec is present; they MAY be implemented through a different protocol.
Each IP datagram is compressed and decompressed independently ('stateless compression'), as IP datagrams may arrive out of order or not arrive at all.
If the total size of a compressed payload and the IPComp header is not smaller than the size of the original payload, the IP datagram MUST be sent in the original non-compressed form with no IPComp header added.
In the IPv6 context, IPComp MUST NOT apply to hop-by-hop, routing, and fragmentation extension headers.
Processing of inbound IP datagrams MUST support both compressed and non-compressed IP datagrams, in order to meet the non-expansion policy requirements.
The CPI SHOULD be sent as a 16-bit number in the IKE SPI field (SPI size=2). It MAY be sent as a 32-bit value (SPI size=4), with the CPI in the two least significant octets and the two most significant octets set to zero and ignored. The receiving node MUST be able to process both forms.
The Flags field of the IPComp header MUST be set to zero by the sender and MUST be ignored by the receiving 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, and MUST negotiate a compression algorithm in each direction for which they establish an IPCA.
An IPComp Association (IPCA) must be established between two nodes before using IPComp; it includes the CPI, mode of operation, compression algorithm, and any algorithm-specific parameters. There is no default compression algorithm.
The Compression Parameter Index (CPI) is a 16-bit field: values 0-63 are well-known algorithms for manual setup; 64-255 reserved; 256-61439 negotiated between nodes; 61440-65535 for private use. The outbound IPComp header MUST use the CPI chosen by the decompressing node.
A filtering border router can filter IPComp-compressed datagrams only if it shares the IPComp Association used for compression. A mechanism must be in place for the receiving node to securely communicate the IPCA to the border router in environments requiring packet filtering.
When IPComp is used without IPsec, it may make it difficult for border routers to filter datagrams based on header fields, since the original Protocol field value and transport layer headers (e.g., port numbers) are not in their normal positions or original values after compression.
For IPv4, the Protocol field is set to 108 (IPComp Datagram), Total Length reflects the encapsulated size including IPComp header and compressed payload, and Header Checksum is recalculated; all other fields remain unchanged.
For IPv6, the Next Header field is set to 108 (IPComp Datagram) and Payload Length reflects the compressed payload. The IPComp header is placed using the same rules as the IPv6 Fragment Header, but if both are present, the Fragment Header MUST precede the IPComp header.
The IPComp header is a fixed four-octet structure: Next Header (8-bit, stores original protocol/next-header value), Flags (8-bit, reserved, MUST be zero), and Compression Parameter Index or CPI (16-bit, network order).