RFC 3173

IP Payload Compression Protocol (IPComp)

📅 published September 2001, from ietf

Hey bestie, meet IPComp 🎀✨

Okay so RFC 3173 is the IP Payload Compression Protocol (IPComp) 💖. The authors are A. Shacham (Juniper), B. Monsour (Consultant), R. Pereira (Cisco), and M. Thomas (Consultant). It's a Standards Track doc from September 2001, and it obsoletes RFC 2393 🔥. Main character energy, literally.

Status of This Memo ✨

Okay so this is a standards track protocol for the whole Internet community 🌐, and it's begging for discussion and suggestions for improvements 💅. If you want the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) list. Distribution of this memo is unlimited, so share away 🦋

Copyright (C) The Internet Society (2001). All Rights Reserved. 🫶

Abstract 🍓

The tea is that this protocol gives you lossless compression for Internet Protocol datagrams in an Internet environment. No data gets lost, and everything comes out exactly as it went in 🧚

1. Introduction 💜

IP payload compression is a protocol that shrinks the size of IP datagrams 📦. It boosts the overall communication performance between two communicating hosts or gateways (called "nodes") by compressing datagrams. This works as long as the nodes have enough computing power, either through CPU capacity or a compression coprocessor, and the communication runs over slow or congested links 🐢

IP payload compression is especially useful when encryption is applied to IP datagrams 🔐. Encryption makes the data look random, so compression at lower protocol layers (for example, the PPP Compression Control Protocol [RFC1962]) stops working. It's giving "wrong order." If you need both compression and encryption, compression must be applied before encryption 🙈

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 out of scope for this one 🫶

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 [RFC2119] ✨

2. Compression Process 🌀

The compression processing of IP datagrams has two phases: compressing outbound IP datagrams ("compression") and decompressing inbound datagrams ("decompression") 🔁. The compression processing MUST be lossless, so after a datagram is compressed and then decompressed, it's identical to the original IP datagram 💯

Each IP datagram gets compressed and decompressed all by itself, with no relation to other datagrams ("stateless compression"). This matters because IP datagrams can arrive out of order or never arrive at all 🙃 Each compressed IP datagram wraps up a single IP payload 🎁

Processing of inbound IP datagrams MUST support both compressed and non-compressed IP datagrams, so the non-expansion policy requirements (defined in section 2.2) can be met 🎀

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 [RFC2460], 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 possibly every node along a packet's delivery path has to examine and process, so they MUST be sent in their original form 🛣️

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

2.1. Compressed Payload 📦

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 🧠

In IP version 4 [RFC0791], compression is applied to the payload of the IP datagram. It starts at the first octet after the IP header and runs through the last octet of the datagram. No part of the IP header or the IP header options gets compressed 🙅‍♀️ Note: with an encapsulated IP header (for example, tunnel mode encapsulation in IPsec), the datagram payload is defined to start right after the outer IP header. That means the inner IP header counts as payload and gets compressed 🪆

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 🚫 Compression starts at the first IP Header Option field that doesn't carry information nodes along the delivery path must examine and process (if one exists), and it keeps going through 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 gets inserted right before the compressed payload 🎀 The original IP header gets modified to show that IPComp is in use and to show 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 💾

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. The IPComp header gets removed, and the decompressed payload sits right after the IP header ✨

2.2. Non-Expansion Policy 🙅‍♀️📉

If the total size of a compressed payload plus the IPComp header (as defined in section 3) isn't smaller than the size of the original payload, the IP datagram MUST be sent in its original non-compressed form 🛑 To be clear: if a datagram goes out non-compressed, no IPComp header gets added to it. This policy saves decompression processing cycles and avoids fragmentation when the expanded datagram would be bigger than the MTU 🧠

Small IP datagrams are likely to expand when compressed 🫠 So a numeric threshold should be applied before compression, and datagrams smaller than that threshold go out in their original form without any compression attempt. The numeric threshold is implementation dependent 🔧

A payload that's already been compressed tends not to compress any further 🤷‍♀️ The earlier compression might come from an external process, like compression applied by an upper layer in the communication stack or an off-line compression utility. An adaptive algorithm should be implemented to avoid the performance hit. For example, if compression of i consecutive IP datagrams of an IPCA fails, the next several datagrams (say k) are sent without an attempt at compression. If the next j datagrams also fail to compress, a larger number of datagrams (say k+n) are sent without an attempt at compression. Once a datagram compresses successfully, the normal IPComp process restarts. The 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 data is, similar to the requirements of [V42BIS] 🧪 That test is algorithm dependent. Once the compression algorithm detects that the data isn't compressible, the algorithm SHOULD stop processing the data, and the payload goes out in its original non-compressed form 🙅‍♀️💀

3. Compressed IP Datagram Header Structure 🧚‍♀️

A compressed IP datagram gets 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 🌷

These IPv4 header fields get set before the compressed IP datagram is 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, [RFC1700] 🔢
  • Header Checksum: the Internet Header checksum [RFC0791] of the IP header ✅

All other IPv4 header fields stay unchanged, including any header options 🫶

3.2. IPv6 Header Modifications 🌈

These IPv6 header fields get set before the compressed IP datagram is transmitted:

  • Payload Length: the length of the compressed IP payload 📏
  • Next Header: set to 108, IPComp Datagram, [RFC1700] 🔢

All other IPv6 header fields stay unchanged, including any non-compressed header options 🫶

The IPComp header gets 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 👑 Note: other IPv6 headers may be present between the IPv6 Fragment Header and the IPComp header 💖

3.3. IPComp Header Structure ✨

okay so the IPComp header is only four octets, and it's giving tiny but mighty 💅 here's how it's laid out:

   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 🎀 is an 8-bit selector. It stores the IPv4 Protocol field or the IPv6 Next Header field of the original IP header.
  • Flags 🌸 is an 8-bit field that's reserved for future use. It MUST be set to zero, and it MUST be ignored by the receiving node.
  • Compression Parameter Index (CPI) 🦋 is a 16-bit index, stored in network order. Here's the tea on the ranges:
    • 0-63 are the well-known compression algorithms. They don't need any extra info and they're used for manual setup. These values are the same as the IPCOMP Transform identifiers defined in [SECDOI]. Check [SECDOI] for an initial set of defined values and for how to assign new ones.
    • 64-255 are reserved for future use 🔮
    • 256-61439 get negotiated between the two nodes when they set up an IPComp Association, as defined in section 4 🤝
    • 61440-65535 are for private use between parties who both agree to it 🫶

Note: when the nodes negotiate one of the well-known algorithms, they MAY pick a CPI from the pre-defined range 0-63. Both nodes can choose their CPI values independently of each other, and there's no relationship between the two CPIs they pick. 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. this combo is literally the main character 👑

4. IPComp Association (IPCA) Negotiation ✨

okay so before anyone can use IPComp, two nodes MUST first establish an IPComp Association (IPCA) between them. The IPCA holds everything IPComp needs to run: the Compression Parameter Index (CPI), the mode of operation, the compression algorithm, and any parameters that algorithm needs.

The policy for setting up IPComp can be either node-to-node, where IPComp gets applied to every IP packet between the nodes, or session-based, where only certain sessions between the nodes use IPComp. so flexible, I'm obsessed

Two nodes may negotiate IPComp in either direction or both, and they can use a different compression algorithm in each direction. Still, the nodes MUST negotiate a compression algorithm in each direction they set up an IPCA for, because there is no default compression algorithm. 🙅‍♀️ No compression algorithm is mandatory for an IPComp implementation.

The IPCA gets set up either through dynamic negotiations or through manual configuration. The dynamic negotiations SHOULD use the Internet Key Exchange protocol [IKE] where IPsec is present. The dynamic negotiations MAY also be implemented through a different protocol.

4.1. Use of IKE 🔐

For IPComp in the context of IP Security, IKE gives you the mechanisms and guidelines for setting up an IPCA. With IKE, IPComp can be negotiated on its own or alongside other IPsec protocols.

The initiator negotiates an IPComp Association using a Proposal Payload. That Proposal Payload has one or more Transform Payloads inside it. The Proposal Payload names the IP Payload Compression Protocol in its protocol ID field, and each Transform Payload carries the specific compression algorithm(s) being offered to the responder.

The CPI goes in the SPI field of the proposal, and the SPI size field gets set to match. The CPI SHOULD be sent as a 16-bit number, with the SPI size field set to 2. Alternatively, the CPI MAY be sent as a 32-bit value, with the SPI size field set to 4. In that case, the 16-bit CPI number MUST be placed in the two least significant octets of the SPI field, the two most significant octets MUST be set to zero, and those two most significant octets MUST be ignored by the receiving node. The receiving node MUST be able to process both forms of the CPI proposal. two forms, one receiver, zero drama ✨

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

The following attributes apply to IPComp proposals:

  • Encapsulation Mode 🎁 To propose a non-default Encapsulation Mode (like Tunnel Mode), an IPComp proposal MUST include an Encapsulation Mode attribute. If the Encapsulation Mode is unspecified, the default value of Transport Mode is assumed.
  • Lifetime ⏳ An IPComp proposal uses the Life Duration and Life Type attributes to suggest a life duration to the IPCA.

When IPComp gets negotiated as part of a Protection Suite, all the logically related offers have to be consistent. An IPComp proposal SHOULD NOT include attributes that don't apply to IPComp, though. An IPComp proposal MUST NOT be rejected just because it lacks attributes of other protocols in the Protection Suite that aren't relevant to IPComp. If an IPComp proposal does include such attributes, those attributes MUST be ignored when setting the IPCA, and therefore ignored in the operation of IPComp. 🫧

Implementation note:

A node can skip the computation it would need to work out the compression algorithm from the CPI if it's using one of the well-known algorithms. That can save time in the decompression process. To do this, the node negotiates a CPI equal in value to the pre-defined Transform identifier of that compression algorithm. Specifically: a node MAY offer a CPI in the pre-defined range by sending a Proposal Payload that MUST contain a single Transform Payload, which is identical to the CPI. When proposing two or more Transform Payloads, a node MAY offer CPIs in the pre-defined range by using multiple IPComp proposals, and each MUST include a single Transform Payload. To clarify: if a Proposal Payload contains two or more Transform Payloads, the CPI MUST be in the negotiated range. A receiving node MUST be able to process each of these proposal forms. 🏎️

Implementation note:

IPCAs become non-unique when two or more IPComp sessions get set up between two nodes and the same well-known CPI is used in at least two of those sessions. Non-unique IPCAs cause problems with keeping track of attributes that are specific to each IPCA. Those attributes can be negotiated (for example, lifetime) or internal (for example, the counters of the adaptive algorithm for handling previously compressed payload). To make sure IPCAs stay unique between two nodes, when two or more of the IPCAs use the same compression algorithm, the CPIs SHOULD be in the negotiated range. However, when the IPCAs don't need to be unique, for example when no attribute is being used for them, a well-known CPI MAY be used. To clarify: when only a single session using a particular well-known CPI is set up between two nodes, that IPCA is unique. 💜

4.2. Use of Non-IKE Protocol 🌈

The dynamic negotiations MAY be implemented through a protocol other than IKE. That protocol is beyond the scope of this document.

4.3. Manual Configuration 🛠️

Nodes can set up IPComp Associations using manual configuration. With 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 part is SERIOUS, bestie, so read it carefully 🙈

When IPComp is used in the context of IPsec, it is believed not to have an effect on the underlying security functionality that IPsec provides. In other words, using compression is not known to degrade or change the nature of the underlying security architecture or the encryption technologies used to implement it. 🔒

When IPComp is used without IPsec, IP payload compression can potentially reduce the security of the Internet, kind of like the effects of IP encapsulation [RFC2003]. For example, IPComp may make it hard 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 in its normal position within the datagram. Any transport layer header fields in the datagram, like port numbers, are not in their normal positions either, and they don't keep their original values after compression. A filtering border router can only filter the datagram 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. IANA Considerations 📋

This document does not require any IANA actions. The well-known numbers used in this document are defined elsewhere; see [SECDOI].

7. Changes made since RFC 2393 🦋

This section sums up the changes in this document from RFC 2393 that an implementer of RFC 2393 should know about. All the changes are meant to clarify how an IPComp Association (IPCA) gets negotiated using IKE [IKE] in the context of IPsec.

  1. Added a clarification that IPComp can be negotiated stand-alone or bundled with other protocols in a Protection Suite.
  2. Defined the CPI in the SPI field of an IKE proposal: a two-octet field is a SHOULD, and a four-octet field is a MAY. Defined the placement of the 16-bit CPI in a four-octet field. Specified that a receiver MUST process both field sizes.
  3. Added wording to define the default Encapsulation Mode as Transport Mode. Required that an IPComp proposal MUST include an Encapsulation Mode attribute when it suggests a non-default encapsulation, such as Tunnel Mode.
  4. Added the Lifetime attribute to the list of supported attributes, along with Transport Mode.
  5. Specified how to handle attributes of transforms in a Protection Suite that don't apply to IPComp. These attributes SHOULD NOT be included in an IPComp proposal, and they MUST be ignored when setting the IPCA and in the operation of IPComp. IPComp implementations MUST never reject an IPCOMP proposal that does not include attributes of other transforms. 🫶
  6. Added implementation notes on the negotiation and usage of CPIs in the predefined (well-known) range. ✨

8. References ✨

Okay bestie, here's the full reading list 📚 Every reference the spec leans on, with all the deets:

  • [RFC0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.
  • [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. Or see: http://www.iana.org/numbers.html
  • [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
  • [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, 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 🎀

Meet the squad who wrote this thing 🫶 Here's how to reach each of them:

Abraham Shacham
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
United States of America

EMail: shacham@shacham.net


Bob Monsour
18 Stout Road
Princeton, New Jersey 08540
United States of America

EMail: bob@bobmonsour.com


Roy Pereira
Cisco Systems, Inc.
55 Metcalfe Street
Ottawa, Ontario K1P 6L5
Canada

EMail: royp@cisco.com


Matt Thomas
3am Software Foundry
8053 Park Villa Circle
Cupertino, California 95014
United States of America

EMail: matt@3am-software.com

Comments 💌

If you've got thoughts, send them to the ippcp@external.cisco.com mailing list and/or the author(s). They want your feedback 🥰

Here's the legal stuff, kept word for word because it's important 💅

Copyright (C) The Internet Society (2001). 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.

Acknowledgement 🙏

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from