Date: Fri, 17 Sep 1999 07:12:43 -0700 (PDT) From: Abraham Shacham To: ippcp@external.cisco.com, ipsec@lists.tislabs.com Subject: rfc2393bis Following the threads on ipsec and ippcp mailing lists since the publication of RFC2393 in December 1998, and the hallway discussion in Oslo with some of the ippcp mailing-list members, draft-shacham-ippcp-rfc2393bis-00.txt -- (ippcp wg exists no more, therefore no draft-ietf naming) -- intends to update RFC2393 with the following clarifications: 1. Payload definition in IPv4 A more detailed definition of the payload to be compressed in IPv4, including in IP encapsulation such as tunnel mode, while walking away from the term 'upper layer protocol' or 'ULP'. 2. IPv6 header order Clarifications of IPv6 header order. 3. Negotiations in the context of IPSec 3.1 Stating that IPCOMP can be negotiated stand-alone or bundled with other protocols. 3.2 CPI in SPI field of a proposal; two-octet field as SHOULD, and a MAY for 4-octet field; the location of the 16-bit CPI in a 4-octet field; plus, a MUST for the receiver to process both field sizes. 3.3 Definition of encapsulation mode in the context of DOI, including answering RFC2407 'host-dependent' default assumption when the encapsulation attribute isn't defined: Encapsulation Mode [...] If unspecified, the default value shall be assumed to be unspecified (host-dependent). 3.4 Pointing to the 'guidelines' of ISAKMP negotiations, without specifying details that aren't IPComp-specific, and without duplicating the content of other RFCs. 4. Language Some (minor) language-related changes. For the convenience of the reader, attached is the diff between RFC2393 and the draft. After the trimming of all style (draft vs. rfc) and paging related modifications, that diff is pretty short. Each section of the diff is marked with the related change(s) from the above list. For example, 126,128c129,136 === #1 === states that the diff section is related to change #1, i.e. payload definition in IPv4. As in the past, I do encourage RFC2393 related discussions to take place on the ippcp mailing-list, reachable at ippcp@external.cisco.com. Acknowledgment: Tim Jenkins contributed suggestions for this draft, thanks! Regards, avram 126,128c129,136 === #1 === < 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. 134c142 === #4 === < 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,160c166,168 === #1 === < 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- --- > 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- 258c260,262 === #2 === < 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. 302c306 === #4 === < independently of each other and there is no relationships --- > independently of each other and there is no relationship 333,334c337,345 === #3, #4 === < 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. --- > necessary mechanisms and guidelines for establishing IPCA. Using > ISAKMP, 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. 351c369,372 === #3 === < Identifiers. --- > Identifiers. To suggest 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. 356c377 === #4 === < than ISAKMP. Such protocol is beyond the scope of this document. --- > than ISAKMP. Such a protocol is beyond the scope of this document. === eom ===