idnits 2.17.1 draft-ietf-ippcp-protocol-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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 IP Header Option field exists, and continues to the ULP payload of the IP datagram. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1998) is 9569 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'ISAKMP') == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-ipsec-doi-06 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'SECDOI') -- Possible downref: Non-RFC (?) normative reference: ref. 'V42BIS' Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Shacham, Cisco 2 IP Payload Compression Protocol Working Group R. Monsour, Hi/fn 3 Expires in six months R. Pereira, TimeStep 4 M. Thomas, AltaVista Internet 5 January 1998 7 IP Payload Compression Protocol (IPComp) 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 ``work in progress.'' 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 27 Coast), or ftp.isi.edu (US West Coast). 29 Distribution of this memo is unlimited. 31 Abstract 33 This document describes a protocol intended to provide lossless 34 compression for Internet Protocol datagrams in an Internet 35 environment. 37 1. Introduction 39 IP payload compression is a protocol to reduce the size of IP 40 datagrams. This protocol will increase the overall communication 41 performance between a pair of communicating hosts/gateways ("nodes") 42 by compressing the datagrams, provided the nodes have sufficient 43 computation power, through either CPU capacity or a compression 44 coprocessor, and the communication is over slow or congested links. 46 IP payload compression is especially useful when encryption is 47 applied to IP datagrams. Encrypting the IP datagram causes the data 48 to be random in nature, rendering compression at lower protocol 49 layers (e.g., PPP Compression Control Protocol [RFC-1962]) 50 ineffective. If both compression and encryption are required, 51 compression MUST be applied before encryption. 53 This document defines the IP payload compression protocol (IPComp), 54 the IPComp packet structure, the IPComp Association (IPCA), and 55 several methods to negotiate the IPCA. 57 Other documents shall specify how a specific compression algorithm 58 can be used with the IP payload compression protocol. Such 59 algorithms are beyond the scope of this document. 61 1.1. Specification of Requirements 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 64 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 65 in this document are to be interpreted as described in RFC 2119 66 [RFC-2119]. 68 2. Compression Process 70 The compression processing of IP datagrams has two phases: 71 compressing of outbound IP datagrams ("compression") and 72 decompressing of inbound datagrams ("decompression"). The 73 compression processing MUST be lossless, ensuring that the IP 74 datagram, after being compressed and decompressed, is identical to 75 the original IP datagram. 77 Each IP datagram is compressed and decompressed by itself without any 78 relation to other datagrams ("stateless compression"), as IP 79 datagrams may arrive out of order or not arrive at all. Each 80 compressed IP datagram encapsulates a single IP payload. 82 Processing of inbound IP datagrams MUST support both compressed and 83 non-compressed IP datagrams, in order to meet the non-expansion 84 policy requirements, as defined in section 2.2. 86 The compression of outbound IP datagrams MUST be done before any IP 87 security processing, such as encryption and authentication, and 88 before any fragmentation of the IP datagram. In addition, in IP 89 version 6 [RFC-1883], the compression of outbound IP datagrams MUST 90 be done before the addition of either a Hop-by-Hop Options header or 91 a Routing Header, since both carry information that must be examined 92 and processed by possibly every node along a packet's delivery path, 93 and therefore MUST be sent in the original form. 95 Similarly, the decompression of inbound IP datagrams MUST be done 96 after the reassembly of the IP datagrams, and after the completion 97 of all IP security processing, such as authentication and 98 decryption. 100 2.1. Compressed Payload 102 The compression is applied to a single array of octets, which are 103 contiguous in the IP datagram. This array of octets always ends at 104 the last octet of the IP packet payload. Note: a contiguous array of 105 octets in the IP datagram may be not contiguous in physical memory. 107 In IP version 4 [RFC-0791], the compression is applied to the upper 108 layer protocol (ULP) payload of the IP datagram. No portion of the 109 IP header or the IP header options is compressed. 111 In the IPv6 context, IPComp is viewed as an end-to-end payload, and 112 MUST not apply to hop-by-hop, routing, and fragmentation extension 113 headers. The compression is applied starting at the first IP Header 114 Option field that does not carry information that must be examined 115 and processed by nodes along a packet's delivery path, if such IP 116 Header Option field exists, and continues to the ULP payload of the 117 IP datagram. 119 The size of a compressed payload, generated by the compression 120 algorithm, MUST be in whole octet units. 122 As defined in section 3, an IPComp header is inserted immediately 123 preceding the compressed payload. The original IP header is modified 124 to indicate the usage of the IPComp protocol and the reduced size of 125 the IP datagram. The original content of the Next Header (IPv6) or 126 protocol (IPv4) field is stored in the IPComp header. 128 The decompression is applied to a single contiguous array of octets 129 in the IP datagram. The start of the array of octets immediately 130 follows the IPComp header and ends at the last octet of the IP 131 payload. If the decompression process is successfully completed, the 132 IP header is modified to indicate the size of the decompressed IP 133 datagram, and the original next header as stored in the IPComp 134 header. The IPComp header is removed from the IP datagram and the 135 decompressed payload immediately follows the IP header. 137 2.2. Non-Expansion Policy 139 If the total size of a compressed ULP payload and the IPComp header, 140 as defined in section 3, is not smaller than the size of the original 141 ULP payload, the IP datagram MUST be sent in the original 142 non-compressed form. To clarify: If an IP datagram is sent 143 non-compressed, no IPComp header is added to the datagram. This 144 policy ensures saving the decompression processing cycles and 145 avoiding incurring IP datagram fragmentation when the expanded 146 datagram is larger than MTU. 148 Small IP datagrams are likely to expand as a result of compression. 149 Therefore, a numeric threshold should be applied before compression, 150 where IP datagrams of size smaller than the threshold are sent in 151 the original form without attempting compression. The numeric 152 threshold is implementation dependent. 154 An IP datagram with payload that has been previously compressed 155 tends not to compress any further. The previously compressed payload 156 may be the result of external processes, such as compression applied 157 by an upper layer in the communication stack, or by an off-line 158 compression utility. An adaptive algorithm should be implemented to 159 avoid the performance hit. For example, if the compression of i 160 consecutive IP datagrams of an IPCA fails, the next k IP datagrams 161 are sent without attempting compression. If the next j datagrams 162 are also failing to compress, the next k+n datagrams are sent without 163 attempting compression. Once a datagram is compressed successfully, 164 the normal process of IPComp restarts. Such an adaptive algorithm, 165 including all the related thresholds, is implementation dependent. 167 During the processing of the payload, the compression algorithm 168 MAY periodically apply a test to determine the compressibility of 169 the processed data, similar to the requirements of [V42BIS]. The 170 nature of the test is algorithm dependent. Once the compression 171 algorithm detects that the data is non-compressible, the algorithm 172 SHOULD stop processing the data, and the payload is sent in the 173 original non-compressed form. 175 3. Compressed IP Datagram Header Structure 177 A compressed IP datagram is encapsulated by modifying the IP header 178 and inserting an IPComp header immediately preceding the compressed 179 payload. This section defines the IP header modifications both in 180 IPv4 and IPv6, and the structure of the IPComp header. 182 3.1. IPv4 Header Modifications 184 The following IPv4 header fields are set before transmitting the 185 compressed IP datagram: 187 Total Length 189 The length of the entire encapsulated IP datagram, including 190 the IP header, the IPComp header and the compressed payload. 192 Protocol 194 The Protocol field is set to 108, IPComp Datagram, [RFC-1700]. 196 Header Checksum 198 The Internet Header checksum [RFC-0791] of the IP header. 200 All other IPv4 header fields are kept unchanged, including any header 201 options. 203 3.2. IPv6 Header Modifications 205 The following IPv6 header fields are set before transmitting the 206 compressed IP datagram: 208 Payload Length 210 The length of the compressed IP payload. 212 Next Header 214 The Next Header field is set to 108, IPComp Datagram, 215 [RFC-1700]. 217 All other IPv6 header fields are kept unchanged, including any 218 non-compressed header options. 220 The IPComp header is placed in an IPv6 packet using the same rules as 221 the IPv6 Fragment Header. However if an IPv6 packet contains both an 222 IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header 223 MUST precede the IPComp header in the packet. 225 3.3. IPComp Header Structure 227 The four-octet header has the following structure: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Next Header | Flags | Compression Parameter Index | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Next Header 237 8-bit selector. Stores the IPv4 Protocol field or the IPv6 238 Next Header field of the original IP header. 240 Flags 242 8-bit field. Reserved for future use. MUST be set to zero. 243 MUST be ignored by the receiving node. 245 Compression Parameter Index (CPI) 247 16-bit index. The CPI is stored in network order. The values 248 0-63 define well-known compression algorithms, which require no 249 additional information, and are used for manual setup. The 250 values themselves are identical to IPCOMP Transform identifiers 251 as defined in [SECDOI]. Consult [SECDOI] for an initial set of 252 defined values and for instructions on how to assign new values. 253 The values 64-61439 are negotiated between the two nodes in 254 definition of an IPComp Association, as defined in section 4. 255 Note: When negotiating one of the well-known algorithms, the 256 nodes MAY select a CPI in the pre-defined range 0-63. The 257 values 61440-65535 are for private use among mutually consenting 258 parties. 259 Both nodes participating can select a CPI value independently of 260 each other and there is no relationships between the two 261 separately chosen CPIs. The outbound IPComp header MUST use the 262 CPI value chosen by the decompressing node. The CPI in 263 combination with the destination IP address uniquely identifies 264 the compression algorithm characteristics for the datagram. 266 4. IPComp Association (IPCA) Negotiation 268 To utilize the IPComp protocol, two nodes MUST first establish an 269 IPComp Association (IPCA) between them. The IPCA includes all 270 required information for the operation of IPComp, including the 271 Compression Parameter Index (CPI), the mode of operation, the 272 compression algorithm to be used, and any required parameter for the 273 selected compression algorithm. The IPComp mode of operation is 274 either a node-to-node policy where IPComp is applied to every IP 275 packet between the nodes, or an ULP session based policy where only 276 selected ULP sessions between the nodes are using IPComp. For each 277 IPCA, a different compression algorithm may be negotiated in each 278 direction, or only one direction may be compressed. The default is 279 "no IPComp compression". 281 The IPCA is established by dynamic negotiations or by manual 282 configuration. The dynamic negotiations SHOULD use the Internet 283 Security Association and Key Management Protocol [ISAKMP], where 284 IPSec is present. The dynamic negotiations MAY be implemented 285 through a different protocol. 287 4.1. Use of ISAKMP 289 For IPComp in the context of IP Security, ISAKMP provides the 290 necessary mechanisms to establish IPCA. IPComp Association is 291 negotiated by the initiator using a Proposal Payload, which would 292 include one or more Transform Payloads. The Proposal Payload would 293 specify a compression protocol in the protocol id field and each 294 Transform Payload would contain the specific compression method(s) 295 being offered to the responder. 297 In the Internet IP Security Domain of Interpretation (DOI), IPComp is 298 negotiated as the Protocol ID PROTO_IPCOMP. The compression 299 algorithm is negotiated as one of the defined IPCOMP Transform 300 Identifiers. 302 4.2. Use of Non-ISAKMP Protocol 304 The dynamic negotiations MAY be implemented through a protocol other 305 than ISAKMP. Such protocol is beyond the scope of this document. 307 4.3. Manual Configuration 309 Nodes may establish IPComp Associations using manual configuration. 310 For this method, a limited number of Compression Parameters Indexes 311 (CPIs) is designated to represent a list of specific compression 312 methods. 314 5. Security Considerations 316 When IPComp is used in the context of IPSec, it is believed not to 317 have an effect on the underlying security functionality provided by 318 the IPSec protocol; i.e., the use of compression is not known to 319 degrade or alter the nature of the underlying security architecture 320 or the encryption technologies used to implement it. 322 When IPComp is used without IPSec, IP payload compression potentially 323 reduces the security of the Internet, similar to the effects of IP 324 encapsulation [RFC-2003]. For example, IPComp may make it difficult 325 for border routers to filter datagrams based on header fields. In 326 particular, the original value of the Protocol field in the IP header 327 is not located in its normal positions within the datagram, and any 328 transport layer header fields within the datagram, such as port 329 numbers, are neither located in their normal positions within the 330 datagram nor presented in their original values after compression. A 331 filtering border router can filter the datagram only if it shares the 332 IPComp Association used for the compression. To allow this sort of 333 compression in environments in which all packets need to be filtered 334 (or at least accounted for), a mechanism must be in place for the 335 receiving node to securely communicate the IPComp Association to the 336 border router. This might, more rarely, also apply to the IPComp 337 Association used for outgoing datagrams. 339 6. References 341 [RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, 342 September 1981. 344 [RFC-1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, 345 October 1994. 347 [RFC-1883] Deering, S., Hinden, R., "Internet Protocol, Version 6 348 (IPv6) Specification", RFC 1883, April 1996. 350 [RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", 351 RFC 1962, June 1996. 353 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 354 October 1996. 356 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", RFC 2119, March 1997. 359 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., 360 "Internet Security Association and Key Management 361 Protocol (ISAKMP)", Internet-Draft: 362 draft-ietf-ipsec-isakmp-08.txt, Work in Progress, 363 July 1997. 365 [SECDOI] Piper, D., "The Internet IP Security Domain of 366 Interpretation for ISAKMP", Internet-Draft: 367 draft-ietf-ipsec-ipsec-doi-06.txt, Work in Progress, 368 November 1997. 370 [V42BIS] CCITT, "Data Compression Procedures for Data Circuit 371 Terminating Equipment (DCE) Using Error Correction 372 Procedures", Recommendation V.42 bis, January 1990. 374 Authors' Information 376 Abraham Shacham 377 Cisco Systems 378 101 Cooper Street 379 Santa Cruz, California 95060 380 United States of America 381 Email: shacham@cisco.com 382 Robert Monsour 383 Hi/fn Inc. 384 2105 Hamilton Avenue, Suite 230 385 San Jose, California 95125 386 United States of America 387 Email: rmonsour@hifn.com 389 Roy Pereira 390 TimeStep Corporation 391 362 Terry Fox Drive 392 Kanata, Ontario K2K 2P5 393 Canada 394 Email: rpereira@timestep.com 396 Matt Thomas 397 AltaVista Internet Software 398 30 Porter Road 399 Littleton, Massachusetts 01460 400 United States of America 401 Email: matt.thomas@altavista-software.com 403 Working Group 405 The IP Payload Compression Protocol (IPPCP) working group can be 406 contacted through its chair: 408 Naganand Dorswamy 409 Bay Networks 410 Email: naganand@baynetworks.com