Network Working Group A. Shacham Request for Comments: 3173 Juniper Obsoletes: 2393 B. Monsour Category: Standards Track Consultant R. Pereira Cisco M. Thomas Consultant September 2001 IP Payload Compression Protocol (IPComp) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractThis document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. RFC1962]) ineffective. If both compression and encryption are required, 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 the IP payload compression protocol. Such algorithms are beyond the scope of this document. RFC2119]. 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 [RFC2460], 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.
RFC0791], the compression is applied to the payload of the IP datagram, starting at the first octet following the IP header, and continuing through the last octet of the datagram. No portion of the IP header or the IP header options is compressed. Note: In the case of an encapsulated IP header (e.g., tunnel mode encapsulation in IPsec), the datagram payload is defined to start immediately after the outer IP header; accordingly, the inner IP header is considered part of the payload and is compressed. In the IPv6 context, IPComp is viewed as an end-to-end payload, and MUST NOT apply to hop-by-hop, routing, and fragmentation extension headers. The compression is applied starting at the first IP Header Option field that does not carry information that must be examined and processed by nodes along a packet's delivery path, if such an IP Header Option field exists, and continues to the ULP payload of the IP datagram. The size of a compressed payload, generated by the compression algorithm, MUST be in whole octet units. As defined in section 3, an IPComp header is inserted immediately preceding the compressed payload. The original IP header is modified to indicate the usage of the IPComp protocol and 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. The decompression is applied to a single contiguous array of octets in the IP datagram. The start of the array of octets immediately follows the IPComp header and ends at the last octet of the IP payload. If the decompression process is successfully completed, the IP header is modified to indicate the size of the decompressed IP datagram, and the original next header as stored in the IPComp header. The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header. section 3, is not smaller than the size of the original payload, the IP datagram MUST be sent in the original non-compressed form. To clarify: If an IP datagram is sent non-compressed, no
IPComp header is added to the datagram. This policy ensures saving the decompression processing cycles and avoiding incurring IP datagram fragmentation when the expanded datagram is larger than the MTU. Small IP datagrams are likely to expand as a result of compression. Therefore, a numeric threshold should be applied before compression, where IP datagrams of size smaller than the threshold are sent in the original form without attempting compression. The numeric threshold is implementation dependent. An IP datagram with payload that has been previously compressed tends not to compress any further. The previously compressed payload may be the result of external processes, such as compression applied by an upper layer in the communication stack, or by an off-line compression utility. An adaptive algorithm should be implemented to avoid the performance hit. For example, if the compression of i consecutive IP datagrams of an IPCA fails, the next several IP datagrams, say k, are sent without attempting compression. If then the next j datagrams also fail to compress, a larger number of datagrams, say k+n, are sent without attempting compression. Once a datagram is compressed successfully, the normal process of IPComp restarts. Such an adaptive algorithm, including all the related thresholds, is implementation dependent. During the processing of the payload, the compression algorithm MAY periodically apply a test to determine the compressibility of the processed data, similar to the requirements of [V42BIS]. The nature of the 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 the original non- compressed form.
Total Length The length of the entire encapsulated IP datagram, including the IP header, the IPComp header and the compressed payload. Protocol The Protocol field is set to 108, IPComp Datagram, [RFC1700]. Header Checksum The Internet Header checksum [RFC0791] of the IP header. All other IPv4 header fields are kept unchanged, including any header options. RFC1700]. 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. However 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.
SECDOI]. Consult [SECDOI] for an initial set of defined values and for instructions on how to assign new values. The values 64-255 are reserved for future use. The values 256-61439 are negotiated between the two nodes in definition of 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 participating can select a CPI value independently of each other and there is no relationship between the two separately chosen CPIs. The outbound IPComp header MUST use the CPI value chosen by the decompressing node. The CPI in combination with the destination IP address uniquely identifies the compression algorithm characteristics for the datagram.
IKE], where IPsec is present. The dynamic negotiations MAY be implemented through a different protocol.
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. The following attributes are applicable to IPComp proposals: Encapsulation Mode To propose a non-default Encapsulation Mode (such as 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 life duration to the IPCA. When IPComp is negotiated as part of a Protection Suite, all the logically related offers must be consistent. However, an IPComp proposal SHOULD NOT include attributes that are not applicable to IPComp. An IPComp proposal MUST NOT be rejected because it does not include attributes of other protocols in the Protection Suite that are not relevant to IPComp. When an IPComp proposal includes such attributes, those attributes MUST be ignored when setting the IPCA, and therefore ignored in the operation of IPComp. Implementation note: A node can avoid the computation necessary for determining the compression algorithm from the CPI if it is using one of the well-known algorithms; this can save time in the decompression process. A node can do this by negotiating 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 -- 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 are established between two nodes, and the same well-known CPI is used in at least two of the sessions. Non-unique IPCAs pose problems in maintaining attributes specific to each IPCA, either negotiated (e.g., lifetime) or internal (e.g., the counters of the adaptive algorithm for handling previously compressed payload). To ensure the uniqueness of IPCAs 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 are not required to be unique, for example when no attribute is being utilized for these IPCAs, a well-known CPI MAY be used. To clarify: When only a single session using a particular well-known CPI is established between two nodes, this IPCA is unique. RFC2003]. 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, and 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 in which 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. SECDOI]. RFC 2393 of which an implementer of RFC 2393 should be aware. All the changes are meant to clarify the negotiation of an IPComp Association (IPCA) 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: two-octet field is a SHOULD, four-octet 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 to be 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 the handling of attributes of transforms in a Protection Suite that are not applicable to IPComp: These attributes SHOULD NOT be included in an IPComp proposal and MUST be ignored when setting 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.
[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.
Comments Comments should be addressed to the email@example.com mailing list and/or the author(s).
Full Copyright Statement 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.