idnits 2.17.1 draft-shacham-ippcp-rfc2393bis-00.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-20) 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 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 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 an 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 (September 1999) is 8984 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 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (ref. 'SECDOI') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'V42BIS' Summary: 8 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 Network Working Group R. Monsour, Hi/fn 3 R. Pereira, TimeStep 4 M. Thomas, AltaVista Internet 5 September 1999 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- 151 compressed form. To clarify: If an IP datagram is sent non- 152 compressed, no IPComp header is added to the datagram. This policy 153 ensures saving the decompression processing cycles and avoiding 154 incurring IP datagram fragmentation when the expanded datagram is 155 larger than 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 k IP datagrams 170 are sent without attempting compression. If the next j datagrams are 171 also failing to compress, the next k+n datagrams are sent without 172 attempting compression. Once a datagram is compressed successfully, 173 the normal process of IPComp restarts. Such an adaptive algorithm, 174 including all the related thresholds, is implementation dependent. 176 During the processing of the payload, the compression algorithm MAY 177 periodically apply a test to determine the compressibility of the 178 processed data, similar to the requirements of [V42BIS]. The nature 179 of the test is algorithm dependent. Once the compression algorithm 180 detects that the data is non-compressible, the algorithm SHOULD stop 181 processing the data, and the payload is sent in the original non- 182 compressed form. 184 3. Compressed IP Datagram Header Structure 186 A compressed IP datagram is encapsulated by modifying the IP header 187 and inserting an IPComp header immediately preceding the compressed 188 payload. This section defines the IP header modifications both in 189 IPv4 and IPv6, and the structure of the IPComp header. 191 3.1. IPv4 Header Modifications 193 The following IPv4 header fields are set before transmitting the 194 compressed IP datagram: 196 Total Length 198 The length of the entire encapsulated IP datagram, including 199 the IP header, the IPComp header and the compressed payload. 201 Protocol 203 The Protocol field is set to 108, IPComp Datagram, [RFC-1700]. 205 Header Checksum 207 The Internet Header checksum [RFC-0791] of the IP header. 209 All other IPv4 header fields are kept unchanged, including any header 210 options. 212 3.2. IPv6 Header Modifications 214 The following IPv6 header fields are set before transmitting the 215 compressed IP datagram: 217 Payload Length 219 The length of the compressed IP payload. 221 Next Header 223 The Next Header field is set to 108, IPComp Datagram, [RFC- 224 1700]. 226 All other IPv6 header fields are kept unchanged, including any non- 227 compressed header options. 229 The IPComp header is placed in an IPv6 packet using the same rules as 230 the IPv6 Fragment Header. However if an IPv6 packet contains both an 231 IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header 232 MUST precede the IPComp header in the packet. Note: other IPv6 233 headers may be present between the IPv6 Fragment Header and the 234 IPComp header. 236 3.3. IPComp Header Structure 238 The four-octet header has the following structure: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Next Header | Flags | Compression Parameter Index | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Next Header 248 8-bit selector. Stores the IPv4 Protocol field or the IPv6 Next 249 Header field of the original IP header. 251 Flags 253 8-bit field. Reserved for future use. MUST be set to zero. 254 MUST be ignored by the receiving node. 256 Compression Parameter Index (CPI) 258 16-bit index. The CPI is stored in network order. The values 259 0-63 define well-known compression algorithms, which require no 260 additional information, and are used for manual setup. The 261 values themselves are identical to IPCOMP Transform identifiers 262 as defined in [SECDOI]. Consult [SECDOI] for an initial set of 263 defined values and for instructions on how to assign new values. 265 The values 64-255 are reserved for future use. The values 266 256-61439 are negotiated between the two nodes in definition of 267 an IPComp Association, as defined in section 4. Note: When 268 negotiating one of the well-known algorithms, the nodes MAY 269 select a CPI in the pre-defined range 0-63. The values 270 61440-65535 are for private use among mutually consenting 271 parties. Both nodes participating can select a CPI value 272 independently of each other and there is no relationship 273 between the two separately chosen CPIs. The outbound IPComp 274 header MUST use the CPI value chosen by the decompressing node. 275 The CPI in combination with the destination IP address uniquely 276 identifies the compression algorithm characteristics for the 277 datagram. 279 4. IPComp Association (IPCA) Negotiation 281 To utilize the IPComp protocol, two nodes MUST first establish an 282 IPComp Association (IPCA) between them. The IPCA includes all 283 required information for the operation of IPComp, including the 284 Compression Parameter Index (CPI), the mode of operation, the 285 compression algorithm to be used, and any required parameter for the 286 selected compression algorithm. The IPComp mode of operation is 287 either a node-to-node policy where IPComp is applied to every IP 288 packet between the nodes, or an ULP session based policy where only 289 selected ULP sessions between the nodes are using IPComp. For each 290 IPCA, a different compression algorithm may be negotiated in each 291 direction, or only one direction may be compressed. The default is 292 "no IPComp compression". 294 The IPCA is established by dynamic negotiations or by manual 295 configuration. The dynamic negotiations SHOULD use the Internet 296 Security Association and Key Management Protocol [ISAKMP], where 297 IPSec is present. The dynamic negotiations MAY be implemented 298 through a different protocol. 300 4.1. Use of ISAKMP 302 For IPComp in the context of IP Security, ISAKMP provides the 303 necessary mechanisms and guidelines for establishing IPCA. Using 304 ISAKMP, IPComp can be negotiated as stand-alone or in conjunction 305 with other IPSec protocols. 307 An IPComp Association is negotiated by the initiator using a Proposal 308 Payload, which includes one or more Transform Payloads. The Proposal 309 Payload specifies the IP Payload Compression Protocol in the protocol 310 ID field and each Transform Payload contains the specific compression 311 algorithm(s) being offered to the responder. 313 The CPI is sent in the SPI field of the proposal, with the SPI size 314 field set to match. The CPI SHOULD be sent as a 16-bit number, with 315 the SPI size field set to 2. Alternatively, the CPI MAY be sent as a 316 32-bit value, with the SPI size field set to 4. In this case, the 317 16-bit CPI number MUST be placed in the two least significant octets 318 of the SPI field, while the two most significant octets MUST be set 319 to zero, and MUST be ignored by the receiving node. The receiving 320 node MUST be able to process both forms of the CPI proposal. 322 In the Internet IP Security Domain of Interpretation (DOI), IPComp is 323 negotiated as the Protocol ID PROTO_IPCOMP. The compression 324 algorithm is negotiated as one of the defined IPCOMP Transform 325 Identifiers. To suggest a non-default Encapsulation Mode (such as 326 Tunnel Mode), an IPComp proposal MUST include an Encapsulation Mode 327 attribute. If the Encapsulation Mode is unspecified, the default 328 value of Transport Mode is assumed. 330 4.2. Use of Non-ISAKMP Protocol 332 The dynamic negotiations MAY be implemented through a protocol other 333 than ISAKMP. Such a protocol is beyond the scope of this document. 335 4.3. Manual Configuration 337 Nodes may establish IPComp Associations using manual configuration. 338 For this method, a limited number of Compression Parameters Indexes 339 (CPIs) is designated to represent a list of specific compression 340 methods. 342 5. Security Considerations 344 When IPComp is used in the context of IPSec, it is believed not to 345 have an effect on the underlying security functionality provided by 346 the IPSec protocol; i.e., the use of compression is not known to 347 degrade or alter the nature of the underlying security architecture 348 or the encryption technologies used to implement it. 350 When IPComp is used without IPSec, IP payload compression potentially 351 reduces the security of the Internet, similar to the effects of IP 352 encapsulation [RFC-2003]. For example, IPComp may make it difficult 353 for border routers to filter datagrams based on header fields. In 354 particular, the original value of the Protocol field in the IP header 355 is not located in its normal positions within the datagram, and any 356 transport layer header fields within the datagram, such as port 357 numbers, are neither located in their normal positions within the 358 datagram nor presented in their original values after compression. A 359 filtering border router can filter the datagram only if it shares the 360 IPComp Association used for the compression. To allow this sort of 361 compression in environments in which all packets need to be filtered 362 (or at least accounted for), a mechanism must be in place for the 363 receiving node to securely communicate the IPComp Association to the 364 border router. This might, more rarely, also apply to the IPComp 365 Association used for outgoing datagrams. 367 6. References 369 [RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, 370 September 1981. 372 [RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 373 RFC 1700, October 1994. Or see: 374 http://www.iana.org/numbers.html 376 [RFC-2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 377 (IPv6) Specification", RFC 2460, December 1998. 379 [RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", 380 RFC 1962, June 1996. 382 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 383 October 1996. 385 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, March 1997. 388 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 389 "Internet Security Association and Key Management Protocol 390 (ISAKMP)", RFC 2408, November 1998. 392 [SECDOI] Piper, D., "The Internet IP Security Domain of 393 Interpretation for ISAKMP", RFC 2407, November 1998. 395 [V42BIS] CCITT, "Data Compression Procedures for Data Circuit 396 Terminating Equipment (DCE) Using Error Correction 397 Procedures", Recommendation V.42 bis, January 1990. 399 Authors' Addresses 401 Abraham Shacham 402 Cisco Systems 403 170 West Tasman Drive 404 San Jose, California 95134 405 United States of America 407 EMail: shacham@cisco.com 409 Robert Monsour 410 Hi/fn Inc. 411 2105 Hamilton Avenue, Suite 230 412 San Jose, California 95125 413 United States of America 415 EMail: rmonsour@hifn.com 417 Roy Pereira 418 TimeStep Corporation 419 362 Terry Fox Drive 420 Kanata, Ontario K2K 2P5 421 Canada 423 EMail: rpereira@timestep.com 425 Matt Thomas 426 AltaVista Internet Software 427 30 Porter Road 428 Littleton, Massachusetts 01460 429 United States of America 431 EMail: matt.thomas@altavista-software.com 433 Working Group 435 The IP Payload Compression Protocol (IPPCP) working group can be 436 contacted through its chair: 438 Naganand Dorswamy 439 Bay Networks 441 EMail: naganand@baynetworks.com