idnits 2.17.1 draft-shacham-ippcp-rfc2393bis-07.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-04-26) 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 2001) is 8351 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 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (ref. 'SECDOI') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'V42BIS' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Shacham, Juniper 2 Network Working Group B. Monsour, Consultant 3 R. Pereira, Cisco 4 M. Thomas, Consultant 5 June 2001 7 IP Payload Compression Protocol (IPComp) 8 10 Status of this Memo 12 This document is an Internet Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inapproporiate to use Internet Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To learn the current status of any Internet Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 33 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 34 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 35 ftp.isi.edu (US West Coast). 37 Abstract 39 This document describes a protocol intended to provide lossless 40 compression for Internet Protocol datagrams in an Internet 41 environment. 43 1. Introduction 45 IP payload compression is a protocol to reduce the size of IP 46 datagrams. This protocol will increase the overall communication 47 performance between a pair of communicating hosts/gateways ("nodes") 48 by compressing the datagrams, provided the nodes have sufficient 49 computation power, through either CPU capacity or a compression 50 coprocessor, and the communication is over slow or congested links. 52 IP payload compression is especially useful when encryption is 53 applied to IP datagrams. Encrypting the IP datagram causes the data 54 to be random in nature, rendering compression at lower protocol 55 layers (e.g., PPP Compression Control Protocol [RFC-1962]) 56 ineffective. If both compression and encryption are required, 57 compression must be applied before encryption. 59 This document defines the IP payload compression protocol (IPComp), 60 the IPComp packet structure, the IPComp Association (IPCA), and 61 several methods to negotiate the IPCA. 63 Other documents shall specify how a specific compression algorithm 64 can be used with the IP payload compression protocol. Such 65 algorithms are beyond the scope of this document. 67 1.1. Specification of Requirements 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC-2119]. 73 2. Compression Process 75 The compression processing of IP datagrams has two phases: 76 compressing of outbound IP datagrams ("compression") and 77 decompressing of inbound datagrams ("decompression"). The 78 compression processing MUST be lossless, ensuring that the IP 79 datagram, after being compressed and decompressed, is identical to 80 the original IP datagram. 82 Each IP datagram is compressed and decompressed by itself without any 83 relation to other datagrams ("stateless compression"), as IP 84 datagrams may arrive out of order or not arrive at all. Each 85 compressed IP datagram encapsulates a single IP payload. 87 Processing of inbound IP datagrams MUST support both compressed and 88 non-compressed IP datagrams, in order to meet the non-expansion 89 policy requirements, as defined in section 2.2. 91 The compression of outbound IP datagrams MUST be done before any IP 92 security processing, such as encryption and authentication, and 93 before any fragmentation of the IP datagram. In addition, in IP 94 version 6 [RFC-2460], the compression of outbound IP datagrams MUST 95 be done before the addition of either a Hop-by-Hop Options header or 96 a Routing Header, since both carry information that must be examined 97 and processed by possibly every node along a packet's delivery path, 98 and therefore MUST be sent in the original form. 100 Similarly, the decompression of inbound IP datagrams MUST be done 101 after the reassembly of the IP datagrams, and after the completion of 102 all IP security processing, such as authentication and decryption. 104 2.1. Compressed Payload 106 The compression is applied to a single array of octets, which are 107 contiguous in the IP datagram. This array of octets always ends at 108 the last octet of the IP packet payload. Note: A contiguous array of 109 octets in the IP datagram may be not contiguous in physical memory. 111 In IP version 4 [RFC-0791], the compression is applied to the payload 112 of the IP datagram, starting at the first octet following the IP 113 header, and continuing through the last octet of the datagram. No 114 portion of the IP header or the IP header options is compressed. 115 Note: In the case of an encapsulated IP header (e.g., tunnel mode 116 encapsulation in IPsec), the datagram payload is defined to start 117 immediately after the outer IP header; accordingly, the inner IP 118 header is considered part of the payload and is compressed. 120 In the IPv6 context, IPComp is viewed as an end-to-end payload, and 121 MUST NOT apply to hop-by-hop, routing, and fragmentation extension 122 headers. The compression is applied starting at the first IP Header 123 Option field that does not carry information that must be examined 124 and processed by nodes along a packet's delivery path, if such an IP 125 Header Option field exists, and continues to the ULP payload of the 126 IP datagram. 128 The size of a compressed payload, generated by the compression 129 algorithm, MUST be in whole octet units. 131 As defined in section 3, an IPComp header is inserted immediately 132 preceding the compressed payload. The original IP header is modified 133 to indicate the usage of the IPComp protocol and the reduced size of 134 the IP datagram. The original content of the Next Header (IPv6) or 135 protocol (IPv4) field is stored in the IPComp header. 137 The decompression is applied to a single contiguous array of octets 138 in the IP datagram. The start of the array of octets immediately 139 follows the IPComp header and ends at the last octet of the IP 140 payload. If the decompression process is successfully completed, the 141 IP header is modified to indicate the size of the decompressed IP 142 datagram, and the original next header as stored in the IPComp 143 header. The IPComp header is removed from the IP datagram and the 144 decompressed payload immediately follows the IP header. 146 2.2. Non-Expansion Policy 148 If the total size of a compressed payload and the IPComp header, as 149 defined in section 3, is not smaller than the size of the original 150 payload, the IP datagram MUST be sent in the original non-compressed 151 form. To clarify: If an IP datagram is sent non-compressed, no 152 IPComp header is added to the datagram. This policy ensures saving 153 the decompression processing cycles and avoiding incurring IP 154 datagram fragmentation when the expanded datagram is larger than the 155 MTU. 157 Small IP datagrams are likely to expand as a result of compression. 158 Therefore, a numeric threshold should be applied before compression, 159 where IP datagrams of size smaller than the threshold are sent in the 160 original form without attempting compression. The numeric threshold 161 is implementation dependent. 163 An IP datagram with payload that has been previously compressed tends 164 not to compress any further. The previously compressed payload may 165 be the result of external processes, such as compression applied by 166 an upper layer in the communication stack, or by an off-line 167 compression utility. An adaptive algorithm should be implemented to 168 avoid the performance hit. For example, if the compression of i 169 consecutive IP datagrams of an IPCA fails, the next several IP 170 datagrams, say k, are sent without attempting compression. If then 171 the next j datagrams also fail to compress, a larger number of 172 datagrams, say k+n, are sent without attempting compression. Once a 173 datagram is compressed successfully, the normal process of IPComp 174 restarts. Such an adaptive algorithm, including all the related 175 thresholds, is implementation dependent. 177 During the processing of the payload, the compression algorithm MAY 178 periodically apply a test to determine the compressibility of the 179 processed data, similar to the requirements of [V42BIS]. The nature 180 of the test is algorithm dependent. Once the compression algorithm 181 detects that the data is non-compressible, the algorithm SHOULD stop 182 processing the data, and the payload is sent in the original non- 183 compressed form. 185 3. Compressed IP Datagram Header Structure 187 A compressed IP datagram is encapsulated by modifying the IP header 188 and inserting an IPComp header immediately preceding the compressed 189 payload. This section defines the IP header modifications both in 190 IPv4 and IPv6, and the structure of the IPComp header. 192 3.1. IPv4 Header Modifications 194 The following IPv4 header fields are set before transmitting the 195 compressed IP datagram: 197 Total Length 199 The length of the entire encapsulated IP datagram, including 200 the IP header, the IPComp header and the compressed payload. 202 Protocol 204 The Protocol field is set to 108, IPComp Datagram, [RFC-1700]. 206 Header Checksum 208 The Internet Header checksum [RFC-0791] of the IP header. 210 All other IPv4 header fields are kept unchanged, including any header 211 options. 213 3.2. IPv6 Header Modifications 215 The following IPv6 header fields are set before transmitting the 216 compressed IP datagram: 218 Payload Length 220 The length of the compressed IP payload. 222 Next Header 224 The Next Header field is set to 108, IPComp Datagram, [RFC- 225 1700]. 227 All other IPv6 header fields are kept unchanged, including any non- 228 compressed header options. 230 The IPComp header is placed in an IPv6 packet using the same rules as 231 the IPv6 Fragment Header. However if an IPv6 packet contains both an 232 IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header 233 MUST precede the IPComp header in the packet. Note: Other IPv6 234 headers may be present between the IPv6 Fragment Header and the 235 IPComp header. 237 3.3. IPComp Header Structure 239 The four-octet header has the following structure: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Next Header | Flags | Compression Parameter Index | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Next Header 249 8-bit selector. Stores the IPv4 Protocol field or the IPv6 Next 250 Header field of the original IP header. 252 Flags 254 8-bit field. Reserved for future use. MUST be set to zero. 255 MUST be ignored by the receiving node. 257 Compression Parameter Index (CPI) 259 16-bit index. The CPI is stored in network order. The values 260 0-63 designate well-known compression algorithms, which require 261 no additional information, and are used for manual setup. The 262 values themselves are identical to IPCOMP Transform identifiers 263 as defined in [SECDOI]. Consult [SECDOI] for an initial set of 264 defined values and for instructions on how to assign new values. 266 The values 64-255 are reserved for future use. The values 267 256-61439 are negotiated between the two nodes in definition of 268 an IPComp Association, as defined in section 4. Note: When 269 negotiating one of the well-known algorithms, the nodes MAY 270 select a CPI in the pre-defined range 0-63. The values 271 61440-65535 are for private use among mutually consenting 272 parties. Both nodes participating can select a CPI value 273 independently of each other and there is no relationship 274 between the two separately chosen CPIs. The outbound IPComp 275 header MUST use the CPI value chosen by the decompressing node. 276 The CPI in combination with the destination IP address uniquely 277 identifies the compression algorithm characteristics for the 278 datagram. 280 4. IPComp Association (IPCA) Negotiation 282 To utilize the IPComp protocol, two nodes MUST first establish an 283 IPComp Association (IPCA) between them. The IPCA includes all 284 required information for the operation of IPComp, including the 285 Compression Parameter Index (CPI), the mode of operation, the 286 compression algorithm to be used, and any required parameter for the 287 selected compression algorithm. 289 The policy for establishing IPComp may be either a node-to-node 290 policy where IPComp is applied to every IP packet between the nodes, 291 or a session-based policy where only selected sessions between the 292 nodes employ IPComp. 294 Two nodes may choose to negotiate IPComp in either or both 295 directions, and they may choose to employ a different compression 296 algorithm in each direction. The nodes MUST, however, negotiate a 297 compression algorithm in each direction for which they establish an 298 IPCA: there is no default compression algorithm. 300 No compression algorithm is mandatory for an IPComp implementation. 302 The IPCA is established by dynamic negotiations or by manual 303 configuration. The dynamic negotiations SHOULD use the Internet 304 Key Exchange protocol [IKE], where IPsec is present. The dynamic 305 negotiations MAY be implemented through a different protocol. 307 4.1. Use of IKE 309 For IPComp in the context of IP Security, IKE provides the necessary 310 mechanisms and guidelines for establishing IPCA. Using IKE, IPComp 311 can be negotiated as stand-alone or in conjunction with other IPsec 312 protocols. 314 An IPComp Association is negotiated by the initiator using a Proposal 315 Payload, which includes one or more Transform Payloads. The Proposal 316 Payload specifies the IP Payload Compression Protocol in the protocol 317 ID field and each Transform Payload contains the specific compression 318 algorithm(s) being offered to the responder. 320 The CPI is sent in the SPI field of the proposal, with the SPI size 321 field set to match. The CPI SHOULD be sent as a 16-bit number, with 322 the SPI size field set to 2. Alternatively, the CPI MAY be sent as a 323 32-bit value, with the SPI size field set to 4. In this case, the 324 16-bit CPI number MUST be placed in the two least significant octets 325 of the SPI field, while the two most significant octets MUST be set 326 to zero, and MUST be ignored by the receiving node. The receiving 327 node MUST be able to process both forms of the CPI proposal. 329 In the Internet IP Security Domain of Interpretation (DOI), IPComp is 330 negotiated as the Protocol ID PROTO_IPCOMP. The compression 331 algorithm is negotiated as one of the defined IPCOMP Transform 332 Identifiers. 334 The following attributes are applicable to IPComp proposals: 336 Encapsulation Mode 338 To propose a non-default Encapsulation Mode (such as Tunnel 339 Mode), an IPComp proposal MUST include an Encapsulation Mode 340 attribute. If the Encapsulation Mode is unspecified, the 341 default value of Transport Mode is assumed. 343 Lifetime 345 An IPComp proposal uses the Life Duration and Life Type 346 attributes to suggest life duration to the IPCA. 348 When IPComp is negotiated as part of a Protection Suite, all the 349 logically related offers must be consistent. However, an IPComp 350 proposal SHOULD NOT include attributes that are not applicable to 351 IPComp. An IPComp proposal MUST NOT be rejected because it does not 352 include attributes of other protocols in the Protection Suite that 353 are not relevant to IPComp. When an IPComp proposal includes such 354 attributes, those attributes MUST be ignored when setting the IPCA, 355 and therefore ignored in the operation of IPComp. 357 Implementation note: 359 A node can avoid the computation necessary for determining the 360 compression algorithm from the CPI if it is using one of the 361 well-known algorithms; this can save time in the decompression 362 process. A node can do this by negotiating a CPI equal in value 363 to the pre-defined Transform identifier of that compression 364 algorithm. Specifically: A node MAY offer a CPI in the 365 pre-defined range by sending a Proposal Payload that MUST contain 366 a single Transform Payload, which is identical to the CPI. When 367 proposing two or more Transform Payloads, a node MAY offer CPIs in 368 the pre-defined range by using multiple IPComp proposals -- each 369 MUST include a single Transform Payload. To clarify: If a 370 Proposal Payload contains two or more Transform Payloads, the CPI 371 MUST be in the negotiated range. A receiving node MUST be able to 372 process each of these proposal forms. 374 Implementation note: 376 IPCAs become non-unique when two or more IPComp sessions are 377 established between two nodes, and the same well-known CPI is 378 used in at least two of the sessions. Non-unique IPCAs pose 379 problems in maintaining attributes specific to each IPCA, either 380 negotiated (e.g., lifetime) or internal (e.g., the counters of 381 the adaptive algorithm for handling previously compressed 382 payload). To ensure the uniqueness of IPCAs between two nodes, 383 when two or more of the IPCAs use the same compression 384 algorithm, the CPIs SHOULD be in the negotiated range. However, 385 when the IPCAs are not required to be unique, for example when 386 no attribute is being utilized for these IPCAs, a well-known CPI 387 MAY be used. To clarify: When only a single session using a 388 particular well-known CPI is established between two nodes, this 389 IPCA is unique. 391 4.2. Use of Non-IKE Protocol 393 The dynamic negotiations MAY be implemented through a protocol other 394 than IKE. Such a protocol is beyond the scope of this document. 396 4.3. Manual Configuration 398 Nodes may establish IPComp Associations using manual configuration. 399 For this method, a limited number of Compression Parameters Indexes 400 (CPIs) is designated to represent a list of specific compression 401 methods. 403 5. Security Considerations 405 When IPComp is used in the context of IPsec, it is believed not to 406 have an effect on the underlying security functionality provided by 407 the IPsec protocol; i.e., the use of compression is not known to 408 degrade or alter the nature of the underlying security architecture 409 or the encryption technologies used to implement it. 411 When IPComp is used without IPsec, IP payload compression potentially 412 reduces the security of the Internet, similar to the effects of IP 413 encapsulation [RFC-2003]. For example, IPComp may make it difficult 414 for border routers to filter datagrams based on header fields. In 415 particular, the original value of the Protocol field in the IP header 416 is not located in its normal positions within the datagram, and any 417 transport layer header fields within the datagram, such as port 418 numbers, are neither located in their normal positions within the 419 datagram nor presented in their original values after compression. A 420 filtering border router can filter the datagram only if it shares the 421 IPComp Association used for the compression. To allow this sort of 422 compression in environments in which all packets need to be filtered 423 (or at least accounted for), a mechanism must be in place for the 424 receiving node to securely communicate the IPComp Association to the 425 border router. This might, more rarely, also apply to the IPComp 426 Association used for outgoing datagrams. 428 6. IANA Considerations 430 This document does not require any IANA actions. The well-known 431 numbers used in this document are defined elsewhere; see [SECDOI]. 433 7. References 435 [RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, 436 September 1981. 438 [RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 439 RFC 1700, October 1994. Or see: 440 http://www.iana.org/numbers.html 442 [RFC-2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 443 (IPv6) Specification", RFC 2460, December 1998. 445 [RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", 446 RFC 1962, June 1996. 448 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 449 October 1996. 451 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, March 1997. 454 [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange 455 (IKE)", RFC 2409, November 1998. 457 [SECDOI] Piper, D., "The Internet IP Security Domain of 458 Interpretation for ISAKMP", RFC 2407, November 1998. 460 [V42BIS] CCITT, "Data Compression Procedures for Data Circuit 461 Terminating Equipment (DCE) Using Error Correction 462 Procedures", Recommendation V.42 bis, January 1990. 464 Authors' Addresses 466 Abraham Shacham 467 Juniper Networks, Inc. 468 1194 North Mathilda Avenue 469 Sunnyvale, California 94089 470 United States of America 472 EMail: shacham@shacham.net 474 Bob Monsour 475 15723 Oak Knoll Drive 476 Los Gatos, California 95030 477 United States of America 479 EMail: bobmonsour@home.com 481 Roy Pereira 482 Cisco Systems, Inc. 483 55 Metcalfe Street 484 Ottawa, Ontario K1P 6L5 485 Canada 487 EMail: royp@cisco.com 489 Matt Thomas 490 3am Software Foundry 491 8053 Park Villa Circle 492 Cupertino, California 95014 493 United States of America 495 EMail: matt@3am-software.com 497 Comments 499 Comments should be addressed to the ippcp@external.cisco.com mailing 500 list and/or the author(s).