RFC 2393 (rfc2393) - Page 2 of 10
IP Payload Compression Protocol (IPComp)
Alternative Format: Original Text Document
RFC 2393 IPComp December 1998
This document defines the IP payload compression protocol (IPComp),
the IPComp packet structure, the IPComp Association (IPCA), and
several methods to negotiate the IPCA.
Other documents shall specify how a specific compression algorithm
can be used with the IP payload compression protocol. Such
algorithms are beyond the scope of this document.
1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC-2119].
2. Compression Process
The compression processing of IP datagrams has two phases:
compressing of outbound IP datagrams ("compression") and
decompressing of inbound datagrams ("decompression"). The
compression processing MUST be lossless, ensuring that the IP
datagram, after being compressed and decompressed, is identical to
the original IP datagram.
Each IP datagram is compressed and decompressed by itself without any
relation to other datagrams ("stateless compression"), as IP
datagrams may arrive out of order or not arrive at all. Each
compressed IP datagram encapsulates a single IP payload.
Processing of inbound IP datagrams MUST support both compressed and
non-compressed IP datagrams, in order to meet the non-expansion
policy requirements, as defined in section 2.2.
The compression of outbound IP datagrams MUST be done before any IP
security processing, such as encryption and authentication, and
before any fragmentation of the IP datagram. In addition, in IP
version 6 [RFC-2460], the compression of outbound IP datagrams MUST
be done before the addition of either a Hop-by-Hop Options header or
a Routing Header, since both carry information that must be examined
and processed by possibly every node along a packet's delivery path,
and therefore MUST be sent in the original form.
Similarly, the decompression of inbound IP datagrams MUST be done
after the reassembly of the IP datagrams, and after the completion of
all IP security processing, such as authentication and decryption.
Shacham, et. al. Standards Track