Summary

  • IPComp compresses each IP datagram independently and losslessly. A receiver must accept both compressed and original packets under the same relationship because packet loss and reordering rule out dependence on a previous datagram.
  • The non-expansion rule is decisive: when compressed payload plus the four-octet IPComp header is not smaller than the original payload, the sender must transmit the original form without any IPComp header.
  • A CPI is a directional, destination-scoped lookup value chosen by the decompressor, not a credential or global algorithm identity. Negotiation establishes capability; only packet and endpoint evidence shows whether compression ran, succeeded and helped.

An agreement with an empty place on the wire

Protocol negotiation usually invites a binary reading. A feature is agreed or it is not. Once agreed, an observer expects its marker to appear. IPComp broke that shortcut deliberately. Two nodes could share a valid IPComp Association while a particular packet crossed between them in its ordinary form, carrying neither protocol number 108 nor an IPComp header.

That absence was not a fallback improvised after failure. It was the required result when compression could not justify its own overhead. The association described how a receiver would decompress a packet that arrived compressed. It did not order every eligible payload to become one.

This distinction matters because compression is not a property of a tunnel alone. It is a relation between an algorithm and the bytes presented on one attempt. A repetitive payload may shrink. A small control packet may grow. A payload already compressed by an application may consume CPU and emerge no shorter. A stable configuration cannot know the result of every future datagram in advance.

Compression had to happen before secrecy made it useless

RFC 2393 introduced IPComp in December 1998. Its motivation sat beside IPsec. Encryption makes data appear random; once a payload has been encrypted, a lower layer normally has little repeated structure left to remove. If compression and encryption are both wanted, compression must precede encryption.

The processing order followed from that observation. Outbound compression occurs before authentication or encryption and before fragmentation. Inbound decompression waits until fragments have been reassembled and IP security processing has authenticated and decrypted the packet. The compressor sees the original payload; the decompressor sees it only after the surrounding protection has done its work.

The outer IP header is not swallowed indiscriminately. In IPv4, compression begins after that header. In an IPsec tunnel, however, the inner IP header belongs to the outer payload and can therefore be compressed. In IPv6, headers that intermediate nodes must examine remain outside the compressed region. When a Fragment Header and IPComp both exist, fragmentation remains earlier in the received header chain.

This was a small specification in the useful sense. It fixed the order and the visible boundary while leaving local machinery free to decide whether an individual input deserved transformation.

Every datagram carried its own proof of compressibility

IPComp is stateless across datagrams. Each packet is compressed and decompressed by itself. A decompressor does not require a dictionary carried forward from a previous packet, because the previous packet may be late or may never arrive. Successful reconstruction must not depend on delivery history.

The design puts a strong limit on what one result can say about the next. A good ratio on packet 41 does not authorize the compressor to assume packet 42 will also shrink. It may be sensible to use recent failures as a performance hint, but that hint cannot alter the receiver's wire contract.

RFC 3173 therefore permits an adaptive implementation to stop trying for several packets after consecutive failures, then test again later. It also allows an algorithm-specific compressibility test to halt work early. The counts, thresholds and backoff are local implementation choices. They are not carried as universal constants in the IPComp header.

RFC 2394 supplies a concrete example for DEFLATE. Based on informal tests, it recommends not attempting buffers below 90 bytes. It does not make 90 a universal IPComp boundary, and it defines no additional compressibility test. A different algorithm, processor, link or traffic mix can justify a different local threshold.

The non-expansion rule made omission normative

The central comparison includes the protocol's own cost. IPComp does not ask whether the compressed payload alone is shorter. It asks whether that payload plus the four-octet IPComp header is smaller than the original payload. If not, the sender must transmit the original, uncompressed datagram. It adds no IPComp header.

The rule protects two scarce resources. It avoids spending decompression cycles on a non-saving result. It also avoids turning an original packet that fit below the path MTU into a larger packet that must fragment merely because an optimization was attempted.

This creates an unusual evidentiary boundary. Protocol 108 proves that an IPComp-form packet is being declared at that point in the header chain. Its absence on one packet proves none of the reasons for omission. The payload may have been below a threshold, skipped by an adaptive counter, judged incompressible, compressed unsuccessfully, or excluded by session policy. A capture alone cannot recover which local branch was taken.

Nor does the size reduction prove benefit. Fewer bytes may cost more CPU or latency than a fast link saves. A compression ratio does not identify content type, user value or congestion relief. The protocol guarantees lossless reconstruction and non-expansion on the wire, not a universal performance improvement.

Four octets restored dispatch and selected local context

When compression does win, IPv4 Protocol or IPv6 Next Header becomes 108. The inserted four-octet header carries three elements: the original Next Header value, one reserved Flags octet and a 16-bit Compression Parameter Index.

The saved Next Header is essential. After decompression, the receiver removes IPComp, restores the original dispatch value and places the reconstructed payload where the original payload belonged. The result is not a new application protocol. It is the old packet's payload recovered after a conditional transformation.

The CPI is equally easy to overread. Values 0 through 63 identify well-known transforms; a negotiated range and a private-use range provide other namespaces. But the field is not a global name. Each node can choose its inbound CPI independently, and an outbound packet uses the CPI chosen by the node that will decompress it. CPI together with the destination address selects the relevant compression characteristics.

The same numeric CPI can therefore mean different things in another destination context. Even a well-known CPI can become insufficient to distinguish two associations between the same nodes when their lifetimes or adaptive counters differ. RFC 3173 recommends negotiated-range values when association uniqueness matters. A number on the wire is a lookup input, not a complete account of how that state was authorized or maintained.

No default algorithm meant no invisible common law

Before two nodes use IPComp, they establish an IPComp Association containing the CPI, mode, algorithm and required parameters. The policy can apply to every packet between two nodes or only selected sessions. The two directions are separate and may choose different algorithms.

There is no default compression algorithm. There is also no algorithm every IPComp implementation must support. Interoperability comes from an explicit common choice, not an assumption that the word “compression” implies DEFLATE or any other transform.

RFC 3173 replaced the original specification mainly to clarify negotiation in the IKE/IPsec setting. Later IKEv2 kept the boundary: a requester may offer more than one compression algorithm, but a response accepts at most one. An implementation must not compress with an algorithm that was not offered and accepted.

IKEv2 also makes the lifetime legible. The virtual compression association has no independent life outside the ESP or AH Child SA that contains it. When that Child SA disappears, the compression association disappears and receives no separate Delete payload. At the same time, compression negotiation remains separate from negotiation of cryptographic parameters. Sharing a lifetime does not make CPI an encryption key or an integrity proof.

Compression changed what an intermediary could see

Without IPsec, IPComp can reduce a border device's ability to filter or account by inner protocol fields. The original Protocol value has moved into the IPComp header, and transport fields such as ports are inside compressed bytes. A router that does not share the IPComp Association cannot simply inspect them in their original positions.

That is not a claim that IPComp encrypts data. Compression is not confidentiality. It is a parsing and authority problem: a middlebox may no longer possess the state needed to recover the fields on which its policy depends. If an environment requires every packet to be filtered or accounted for, RFC 3173 says the relevant association must be communicated securely to the filtering device.

The operational record should therefore separate six facts: capability was configured, an association was negotiated, a packet was selected for an attempt, the result earned an IPComp header, the receiver found the right association, and decompression restored the original payload. Collapsing those into “compression enabled” hides both valid omissions and real failures.

The lasting achievement of IPComp was not merely putting smaller payloads into IP. It made an optimization answerable to each packet. Common agreement supplied a safe way to understand a compressed result. Running bytes retained the right to say that compression was not worth doing this time.

Sources