RFC 2393

IP Payload Compression Protocol (IPComp)

📅 published December 1998, from ietf

IP Payload Compression Protocol (IPComp) 🎀

Stream: Network Working Group 🧚 RFC number: 2393 Category: Standards Track 👑 Date: December 1998 🌸 Authors:

  • A. Shacham (Cisco)
  • R. Monsour (Hi/fn)
  • R. Pereira (TimeStep)
  • M. Thomas (AltaVista Internet)

Obsoletes / Updates: The title block doesn't list any RFCs being obsoleted or updated 🫶

Status of This Memo ✨

Okay so this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 🔍 Distribution of this memo is unlimited, so share it with everyone 🦋

Copyright (C) The Internet Society (1998). All Rights Reserved. 💅

Abstract 🌸

This document describes a protocol meant to give lossless compression for Internet Protocol datagrams across the Internet. It's giving "make it smaller but keep every bit" energy 🫶

1. Introduction ✨

So IP payload compression is a protocol that shrinks IP datagrams 🦋 Its whole thing is boosting performance between a pair of communicating hosts/gateways (aka "nodes") by compressing the datagrams. But that only works if the nodes have enough computing power, either through CPU capacity or a compression coprocessor, AND the communication is over slow or congested links 🐢 Lowkey the perfect glow-up for bad connections 🥹

IP payload compression is especially useful when encryption is applied to IP datagrams 🔐 Encrypting a datagram makes the data look random, so compression at lower protocol layers (for example, the PPP Compression Control Protocol [RFC-1962]) stops working 💀 If you need both compression and encryption, compression MUST be applied before encryption. Non-negotiable, bestie 💜

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 IP payload compression. Those algorithms are beyond the scope of this document, so don't look for them here 🙈

1.1. Specification of Requirements 📝

Okay, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC-2119] 🧠

2. Compression Process 🔥

The compression processing of IP datagrams has two phases. First up is compressing outbound IP datagrams ("compression"), and then decompressing inbound datagrams ("decompression") 🌀 The compression processing MUST be lossless. That means the IP datagram, after being compressed and then decompressed, has to be identical to the original IP datagram. Iconic, no notes 👑

Each IP datagram gets compressed and decompressed by itself, with zero relation to other datagrams. That's the "stateless compression" part 🦋 It's needed because datagrams can 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. This is so they can 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, like encryption and authentication, and before any fragmentation of the IP datagram 🔐 Also, in IP version 6 [RFC-2460], the compression of outbound IP datagrams MUST be done before adding either a Hop-by-Hop Options header or a Routing Header. Both of those carry information that every node along a packet's delivery path might need to examine and process, so they MUST be sent in the original form 🗺️ Not me being extra, but this matters 🙃

Similarly, the decompression of inbound IP datagrams MUST be done after the reassembly of the IP datagrams, and after all IP security processing (like authentication and decryption) is complete 🔓

2.1. Compressed Payload 🎀

The compression is applied to a single array of octets that are contiguous in the IP datagram. This array always ends at the last octet of the IP packet payload 🧩 Note: a contiguous array of octets in the IP datagram may not be contiguous in physical memory. Plot twist 🌀

In IP version 4 [RFC-0791], the compression is applied to the upper layer protocol (ULP) payload of the IP datagram. No portion of the IP header or the IP header options gets compressed, so they stay exactly as they are 💖

In the IPv6 context, IPComp is treated as an end-to-end payload, and it MUST not apply to hop-by-hop, routing, and fragmentation extension headers. The compression starts at the first IP Header Option field that does not carry information which nodes along a packet's delivery path have to examine and process. That's only if such a field exists 👀 From there, it continues all the way to the ULP payload of the IP datagram ✨

The size of a compressed payload, as generated by the compression algorithm, MUST be in whole octet units 📏

As defined in section 3, an IPComp header is inserted right before the compressed payload 🎀 The original IP header gets modified to show that IPComp is being used, along with the reduced size of the IP datagram 🦋 The original content of the Next Header (IPv6) or protocol (IPv4) field is stored in the IPComp header, so nothing gets lost 🫶

The decompression is applied to a single contiguous array of octets in the IP datagram. That array starts right after the IPComp header and ends at the last octet of the IP payload 🔄 If decompression finishes successfully, the IP header gets modified to show the size of the decompressed IP datagram, plus the original next header that was stored in the IPComp header 🌸 Then the IPComp header is removed, and the decompressed payload sits right after the IP header 🧚

2.2. Non-Expansion Policy 🚫

If the total size of a compressed ULP payload plus the IPComp header (as defined in section 3) is not smaller than the size of the original ULP payload, the IP datagram MUST be sent in the original non-compressed form 🙅‍♀️ To clarify: if a datagram is sent non-compressed, no IPComp header gets added at all 💅 This policy saves decompression processing cycles, and it also avoids IP datagram fragmentation that would happen when the expanded datagram is larger than the MTU 🧠

Small IP datagrams are likely to expand when compressed 📈 So a numeric threshold should be applied before compression. Any datagram smaller than the threshold gets sent in its original form, with no compression attempt 🌱 The numeric threshold is implementation dependent 🛠️

An IP datagram whose payload has already been compressed tends not to compress any further 😩 That previously compressed payload might come from external processes, like compression applied by an upper layer in the communication stack, or from an off-line compression utility 🎞️ An adaptive algorithm should be implemented to avoid the performance hit. For example, if compression fails for i consecutive IP datagrams of an IPCA, the next k IP datagrams are sent without attempting compression. If the next j datagrams also fail to compress, the next k+n datagrams are sent without attempting compression. Once a datagram compresses successfully, the normal IPComp process restarts ✨ That adaptive algorithm, including all the related thresholds, is implementation dependent 🎀

During processing of the payload, the compression algorithm MAY periodically apply a test to check how compressible the processed data is, similar to the requirements of [V42BIS] 🔍 The nature of that test is algorithm dependent 🧪 Once the compression algorithm detects that the data is non-compressible, the algorithm SHOULD stop processing the data, and the payload is sent in its original non-compressed form 🙃 Honestly, know when to quit 💀

3. Compressed IP Datagram Header Structure 🦋

A compressed IP datagram is encapsulated by modifying the IP header and inserting an IPComp header right before the compressed payload 🎁 This section defines the IP header modifications for both IPv4 and IPv6, plus the structure of the IPComp header 💜

3.1. IPv4 Header Modifications 🌈

The following IPv4 header fields are set before the compressed IP datagram gets transmitted:

  • Total Length: The length of the entire encapsulated IP datagram, including the IP header, the IPComp header, and the compressed payload 📦
  • Protocol: Set to 108, IPComp Datagram, [RFC-1700] 🔢
  • Header Checksum: The Internet Header checksum [RFC-0791] of the IP header 🧮

All other IPv4 header fields are kept unchanged, including any header options 🫶

3.2. IPv6 Header Modifications 🌸

The following IPv6 header fields are set before the compressed IP datagram gets transmitted:

  • Payload Length: The length of the compressed IP payload 📏
  • Next Header: Set to 108, IPComp Datagram, [RFC-1700] 🔢

All other IPv6 header fields are kept unchanged, including any non-compressed header options 🙌

The IPComp header is placed in an IPv6 packet using the same rules as the IPv6 Fragment Header. But if an IPv6 packet contains both an IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header MUST precede the IPComp header in the packet. Order matters, babe 🧩

3.3. IPComp Header Structure 🎀

The four-octet header has the following structure 👇

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |     Flags     | Compression Parameter Index |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Next Header: An 8-bit selector. It stores the IPv4 Protocol field or the IPv6 Next Header field of the original IP header 🗂️
  • Flags: An 8-bit field, reserved for future use. It MUST be set to zero, and it MUST be ignored by the receiving node 🚩
  • Compression Parameter Index (CPI): A 16-bit index, stored in network order 🔑 The values 0-63 define well-known compression algorithms. These need no additional information and are used for manual setup. The values themselves are identical to the IPCOMP Transform identifiers defined in [SECDOI]. Consult [SECDOI] for an initial set of defined values and for instructions on how to assign new ones 📚 The values 64-255 are reserved for future use 🔒 The values 256-61439 are negotiated between the two nodes when defining an IPComp Association, as defined in section 4 🤝 Note: when negotiating one of the well-known algorithms, the nodes MAY select a CPI in the pre-defined range 0-63 🎯 The values 61440-65535 are for private use among mutually consenting parties 🫂 Both nodes can select a CPI value independently of each other, and there's no relationship between the two separately chosen CPIs 🙃 The outbound IPComp header MUST use the CPI value chosen by the decompressing node 👑 The CPI, combined with the destination IP address, uniquely identifies the compression algorithm characteristics for the datagram 💜

4. IPComp Association (IPCA) Negotiation ✨

Okay bestie, before IPComp can do anything, two nodes MUST first establish an IPComp Association (IPCA) between them 🫶. The IPCA is the whole care package: it holds all the required info for IPComp to work, including the Compression Parameter Index (CPI) 🎀, the mode of operation, the compression algorithm to be used, and any required parameter for the selected compression algorithm. The mode is either a node-to-node policy, where IPComp is applied to every IP packet between the nodes, or an ULP session based policy, where only selected ULP sessions between the nodes are using IPComp 💅. For each IPCA, a different compression algorithm may be negotiated in each direction, or only one direction may be compressed. The default is "no IPComp compression" 🙈.

The IPCA gets set up either through dynamic negotiations or manual configuration. The dynamic negotiations SHOULD use the Internet Security Association and Key Management Protocol [ISAKMP], where IPSec is present 🔐. The dynamic negotiations MAY be implemented through a different protocol ✨.

4.1. Use of ISAKMP

For IPComp in the context of IP Security, ISAKMP gives you the mechanisms you need to establish IPCA 🧚. The IPComp Association is negotiated by the initiator using a Proposal Payload, which would include one or more Transform Payloads. The Proposal Payload would specify a compression protocol in the protocol id field, and each Transform Payload would contain the specific compression method(s) being offered to the responder 💜.

In the Internet IP Security Domain of Interpretation (DOI), IPComp is negotiated as the Protocol ID PROTO_IPCOMP. The compression algorithm is negotiated as one of the defined IPCOMP Transform Identifiers 🌸.

4.2. Use of Non-ISAKMP Protocol

The dynamic negotiations MAY be implemented through a protocol other than ISAKMP. Such protocol is beyond the scope of this document 🦋.

4.3. Manual Configuration

Nodes may establish IPComp Associations using manual configuration 🛠️. For this method, a limited number of Compression Parameters Indexes (CPIs) is designated to represent a list of specific compression methods 🍓.

5. Security Considerations 🚨

Okay this section is SERIOUS but also iconic, so let's go 💀. When IPComp is used in the context of IPSec, it is believed not to have an effect on the underlying security functionality provided by the IPSec protocol. That means, i.e., the use of compression is not known to degrade or alter the nature of the underlying security architecture or the encryption technologies used to implement it 🔒✨.

When IPComp is used without IPSec, IP payload compression potentially reduces the security of the Internet 😭, kind of like the effects of IP encapsulation [RFC-2003]. For example, IPComp may make it difficult for border routers to filter datagrams based on header fields 🚧. In particular, the original value of the Protocol field in the IP header is not located in its normal positions within the datagram 🙃. Any transport layer header fields within the datagram, such as port numbers, are neither located in their normal positions within the datagram nor presented in their original values after compression 💔.

A filtering border router can filter the datagram only if it shares the IPComp Association used for the compression 🧐. To allow this sort of compression in environments where all packets need to be filtered (or at least accounted for), a mechanism must be in place for the receiving node to securely communicate the IPComp Association to the border router 🛡️. This might, more rarely, also apply to the IPComp Association used for outgoing datagrams 👀.

6. References 📚

  • [RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.
  • [RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. Or see: http://www.iana.org/numbers.html
  • [RFC-2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
  • [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
  • [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
  • [SECDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
  • [V42BIS] CCITT, "Data Compression Procedures for Data Circuit Terminating Equipment (DCE) Using Error Correction Procedures", Recommendation V.42 bis, January 1990.

Authors' Addresses 💌

Abraham Shacham
Cisco Systems
170 West Tasman Drive
San Jose, California 95134
United States of America

EMail: shacham@cisco.com


Robert Monsour
Hi/fn Inc.
2105 Hamilton Avenue, Suite 230
San Jose, California 95125
United States of America

EMail: rmonsour@hifn.com


Roy Pereira
TimeStep Corporation
362 Terry Fox Drive
Kanata, Ontario K2K 2P5
Canada

EMail: rpereira@timestep.com


Matt Thomas
AltaVista Internet Software
30 Porter Road
Littleton, Massachusetts 01460
United States of America

EMail: matt.thomas@altavista-software.com

Working Group 👯

The IP Payload Compression Protocol (IPPCP) working group can be contacted through its chair 📬:

Naganand Dorswamy
Bay Networks

EMail: naganand@baynetworks.com

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💖

📦 where this page comes from