37a43,44 > This document obsoletes RFC 2393. > 52,61c63 < compression MUST be applied before encryption. --- > compression must be applied before encryption. 123c118 < the last octet of the IP packet payload. Note: a contiguous array of --- > the last octet of the IP packet payload. Note: A contiguous array of 126,128c121,128 < In IP version 4 [RFC-0791], the compression is applied to the upper < layer protocol (ULP) payload of the IP datagram. No portion of the < IP header or the IP header options is compressed. --- > In IP version 4 [RFC-0791], 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. 131c131 < MUST not apply to hop-by-hop, routing, and fragmentation extension --- > MUST NOT apply to hop-by-hop, routing, and fragmentation extension 134c134 < and processed by nodes along a packet's delivery path, if such IP --- > and processed by nodes along a packet's delivery path, if such an IP 158,165c158,165 < If the total size of a compressed ULP payload and the IPComp header, < as defined in section 3, is not smaller than the size of the original < ULP 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 MTU. --- > If the total size of a compressed payload and the IPComp header, as > defined in 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. 187,192c183,189 < consecutive IP datagrams of an IPCA fails, the next k IP datagrams < are sent without attempting compression. If the next j datagrams are < also failing to compress, the next k+n datagrams 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. --- > 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. 258c251,253 < MUST precede the IPComp header in the packet. --- > MUST precede the IPComp header in the packet. Note: Other IPv6 > headers may be present between the IPv6 Fragment Header and the > IPComp header. 290,291c278,279 < 0-63 define well-known compression algorithms, which require no < additional information, and are used for manual setup. The --- > 0-63 designate well-known compression algorithms, which require > no additional information, and are used for manual setup. The 302c295 < independently of each other and there is no relationships --- > independently of each other and there is no relationship 316,334c309 < selected compression algorithm. The IPComp mode of operation is < either a node-to-node policy where IPComp is applied to every IP < packet between the nodes, or an ULP session based policy where only < selected ULP sessions between the nodes are using IPComp. For each < IPCA, a different compression algorithm may be negotiated in each < direction, or only one direction may be compressed. The default is < "no IPComp compression". < < The IPCA is established by dynamic negotiations or by manual < configuration. The dynamic negotiations SHOULD use the Internet < Security Association and Key Management Protocol [ISAKMP], where < IPSec is present. The dynamic negotiations MAY be implemented < through a different protocol. < --- > selected compression algorithm. > > The policy for establishing IPComp may be either a node-to-node > policy where IPComp is applied to every IP packet between the nodes, > or a session-based policy where only selected sessions between the > nodes employ IPComp. > > Two nodes may choose to negotiate IPComp in either or both > directions, and they may choose to employ a different compression > algorithm in each direction. The nodes MUST, however, negotiate a > compression algorithm in each direction for which they establish an > IPCA: there is no default compression algorithm. > > No compression algorithm is mandatory for an IPComp implementation. > > The IPCA is established by dynamic negotiations or by manual > configuration. The dynamic negotiations SHOULD use the Internet > Key Exchange protocol [IKE], where IPsec is present. The dynamic > negotiations MAY be implemented through a different protocol. 341a329 < 4.1. Use of ISAKMP < < For IPComp in the context of IP Security, ISAKMP provides the < necessary mechanisms to establish IPCA. IPComp Association is < negotiated by the initiator using a Proposal Payload, which would < include one or more Transform Payloads. The Proposal Payload would < specify a compression protocol in the protocol id field and each < Transform Payload would contain the specific compression method(s) < being offered to the responder. --- > 4.1. Use of IKE > > For IPComp in the context of IP Security, IKE provides the necessary > mechanisms and guidelines for establishing IPCA. Using IKE, IPComp > can be negotiated as stand-alone or in conjunction with other IPsec > protocols. > > An IPComp Association is negotiated by the initiator using a Proposal > Payload, which includes one or more Transform Payloads. The Proposal > Payload specifies the IP Payload Compression Protocol in the protocol > ID field and each Transform Payload contains the specific compression > algorithm(s) being offered to the responder. > > The CPI is sent in the SPI field of the proposal, with the SPI size > field 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 this case, the > 16-bit CPI number MUST be placed in the two least significant octets > of the SPI field, while the two most significant octets MUST be set > to zero, and MUST be ignored by the receiving node. The receiving > node MUST be able to process both forms of the CPI proposal. > 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. > > 353c360,422 < 4.2. Use of Non-ISAKMP Protocol --- > 4.2. Use of Non-IKE Protocol 356c425 < than ISAKMP. Such protocol is beyond the scope of this document. --- > than IKE. Such a protocol is beyond the scope of this document. 367c441 < When IPComp is used in the context of IPSec, it is believed not to --- > When IPComp is used in the context of IPsec, it is believed not to 369c443 < the IPSec protocol; i.e., the use of compression is not known to --- > the IPsec protocol; i.e., the use of compression is not known to 373c447 < When IPComp is used without IPSec, IP payload compression potentially --- > When IPComp is used without IPsec, IP payload compression potentially 389a464,486 > 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 summarizes the changes in this document from 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 Mode, 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. 399c506,512 < 6. References --- > 8. References 420,422c533,534 < [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, < "Internet Security Association and Key Management Protocol < (ISAKMP)", RFC 2408, November 1998. --- > [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange > (IKE)", RFC 2409, November 1998. 490,555c578 < Working Group < < The IP Payload Compression Protocol (IPPCP) working group can be < contacted through its chair: < < Naganand Dorswamy < Bay Networks < < EMail: naganand@baynetworks.com --- > Comments > > Comments should be addressed to the ippcp@external.cisco.com mailing > list and/or the author(s).