HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 23:48:51 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 29 Apr 1997 16:09:00 GMT ETag: "2e9913-5952-33661d1c" Accept-Ranges: bytes Content-Length: 22866 Connection: close Content-Type: text/plain Internet Engineering Task Force IPng, ISSLOW and AVT Working Groups INTERNET-DRAFT Mathias Engan draft-engan-ip-compress-00.txt Lulea University of Technology S. Casner Precept Software C. Bormann Universitaet Bremen April 18, 1997 Expires: 9/97 IP Header Compression over PPP Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to- Point Protocol [RFC1661]. It defines extensions to the PPP Control Protocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in [IPv6HC] and [CRTP]. Engan Expires September 1997 [Page 1] Internet Draft draft-engan-ip-compress-00.txt April 1997 1. Introduction In order to establish compression of IP datagrams sent over a PPP link each end of the link must agree on a set of configuration param- eters for the compression. The process of negotiating link parameters for network layer protocols is handled in PPP by a family of network control protocols (NCPs). The IPv6 Header Compression defined in [IPv6HC] may be used for compression of both IPv4 and IPv6 datagrams or packets encapsulated with multiple IP headers. The IP/UDP/RTP header compression defined in [CRTP] fits within the framework defined by [IPv6HC] so that it may also be applied to both IPv4 and IPv6 packets. Since there are separate NCPs for IPv4 and IPv6, this document defines configuration options to be used in both NCPs to negotiate parameters for the compression scheme. IP header compression relies on the link layer's ability to indicate the types of datagrams carried in the link layer frames. In this document nine new types for the PPP Data Link Layer Protocol Field are defined along with their meaning. Numeric values need to be assigned for these nine new types. 2. Configuration Option In order for PPP to accomodate new header compression protocols it must be possible to negotiate a set of parameters for each enabled header compression protocol. The specification of link and network layer parameter negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not prohibit multiple instances of one configuration option but states that the specification of a configuration option must expli- citly allow multiple instances. From the current specification of the IPCP IP-Compression-Protocol configuration option [RFC1332, p 6] it follows that it can only be used to select a single compression protocol at any given time. There are at least three alternative approaches for the integration of IPv6 and RTP header compression parameter negotiation into IPCP. The sections 2.1, 2.2 and 2.3 below explains three alternatives, in decreasing order of preference. 2.1. Alternative A (preferred) Add words to the IPCP specification to allow multiple instances of the IP-Compression-Protocol configuration option and use the new option described in section 2.4 with a different compression protocol Engan Expires September 1997 [Page 2] Internet Draft draft-engan-ip-compress-00.txt April 1997 value to select the IPv6 and/or RTP header compression protocol and their parameters. Options for negotiation of parameters for other, new header compression protocols would be easy to add. If it is desirable, the negotiation of UDP/RTP and TCP header compression could be separated into individual options. Negotiation of parame- ters for Van Jacobson TCP/IP header compression is not made with the new option. An implementation that supports more than one scheme for header compression should be able to include multiple instances of the IPCP IP-Compression-Protocol option in a configure request. An existing implementation that supports only classic Van Jacobson header compression should be able to safely reject multiple IP-Compression- Protocol options and options specifying other header compression schemes than Van Jacobson header compression. However, there might exist implementations that do not handle the proposed new option and/or multiple IP-Compression-Protocol options correctly which could be detrimental to backwards compatibility. 2.2. Alternative B Add a new configuration option type to IPCP with, apart from allowing multiple instances, the same meaning as the IPCP IP-Compression- Protocol option. Classic Van Jacobson compression could still be negotiated with the old option type thus guaranteeing interoperability with implementa- tions that do not support IPv6 Header Compression or the new IPCP option type. Negotiation of parameters for IPv6 and RTP header compression is made with the new option described in section 2.4. Options for negotiation of parameters for other, new header compres- sion protocols would be easy to add. If it is desirable, the nego- tiation of UDP/RTP and TCP header compression could be separated into individual options. 2.3. Alternative C Use the IPCP IP-Compression-Protocol option as specified in [RFC1332] but use a different compression protocol value to select a new com- pound option to simultaneously negotiate parameters for classic VJ compression as well as for the new header compression protocols defined in [IPv6HC] and [CRTP]. The new option is as described in section 2.4, including the flags for negotiation of VJ compression. The option format would be structured to allow selection of any desired combination of the currently defined compression protocols Engan Expires September 1997 [Page 3] Internet Draft draft-engan-ip-compress-00.txt April 1997 using a set of flag bits. Additional flag bits may be defined in the future to add other compression protocols. Aggregating negotiation of parameters for all future compression protocols into a single option implies that the specification of the option would need to be changed whenever a new header compression scheme is standardised. 2.4. Configuration Option Format Both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2023] may be used to negotiate IP Header Compression parameters for their respective protocols. The format of the configuration option is the same for both IPCP and IPV6CP except for two flags, the S and V flags. Those are used only in IPCP since there are no definition of Van Jacobson style TCP/IP header compres- sion for IPv6. Description This NCP configuration option is used to negotiate parameters for IP Header Compression. The option format is summarized below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IP-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FLAGS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP_SPACE | NON_TCP_SPACE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F_MAX_PERIOD | F_MAX_TIME | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAX_HEADER | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 (or new type for Alternative B) Length 18 The length may be increased if the presence of additional parame- ters is indicated by additional flags. IP-Compression-Protocol Engan Expires September 1997 [Page 4] Internet Draft draft-engan-ip-compress-00.txt April 1997 TO BE ASSIGNED FLAGS The FLAGS field consists of 32 one-bit flags. Only four (six in Alternative C) are currently defined. Undefined flag bits must be set to zero. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|R|N|T|S|V| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [E] EXPECT_REORDERING Use mechanisms that protect from link-layer reordering of datagrams. [R] RTP_COMPRESSION Enable use of Protocol Identifiers FULL_HEADER, COMPRESSED_RTP, COMPRESSED_UDP and CONTEXT_STATE [CRTP]. [N] NON_TCP_COMPRESSION Enable use of Protocol Identifiers FULL_HEADER and COMPRESSED_NON_TCP [IPv6HC]. [T] TCP_COMPRESSION Enable use of Protocol Identifiers FULL_HEADER and COMPRESSED_TCP. [S] COMP_SLOT_ID (used only in Alternative C) When V = 1, indicates that the slot identifier may be compressed [RFC1332]. This bit is not defined in the configuration option for IPv6CP. [V] VJ_COMPRESSION (used only in Alternative C) Enable use of Protocol Identifiers (hex) 002D and 002F for Van Jacobson TCP header compression. This bit duplicates the func- tion of the IP-Compression-Protocol configuration option defined in [RFC1332] to allow the use of VJ compression in com- bination with other compression modes. This bit is not defined in the configuration option for IPv6CP. TCP_SPACE The TCP_SPACE field is two octets and indicates the maximum value of a connection identifier in the space of connection iden- tifiers allocated for TCP. Engan Expires September 1997 [Page 5] Internet Draft draft-engan-ip-compress-00.txt April 1997 Suggested value: 15 TCP_SPACE must be at least 3 and at most 255. NON_TCP_SPACE The NON_TCP_SPACE field is two octets and indicates the maximum value of a connection identifier in the space of connection iden- tifiers allocated for non-TCP. These connection identifiers are carried in COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet headers. Suggested value: 15 NON_TCP_SPACE must be at least 3 and at most 65535. F_MAX_PERIOD Maximum interval between full headers. No more than F_MAX_PERIOD COMPRESSED_NON_TCP headers may be sent between FULL_HEADER headers. Suggested value: 256 A value of zero implies infinity. F_MAX_TIME Maximum time interval between full headers. COMPRESSED_NON_TCP headers may not be sent more than F_MAX_TIME seconds after sending the last FULL_HEADER header. Suggested value: 5 seconds A value of zero implies infinity. MAX_HEADER The largest header size in octets that may be compressed. Suggested value: 168 octets The value of MAX_HEADER should be large enough so that at least the outer network layer header can be compressed. To increase compression efficiency MAX_HEADER should be set to a value large enough to cover common combinations of network and transport layer headers. Engan Expires September 1997 [Page 6] Internet Draft draft-engan-ip-compress-00.txt April 1997 3. Multiple Network Control Protocols The IP Header Compression protocol is able to compress both IPv6 and IPv4 datagrams. Both IPCP and IPV6CP are able to negotiate option parameter values for IP Header Compression. These values apply to the compression of packets where the outer header is an IPv4 header and an IPv6 header, respectively. 3.1. Sharing Connection Identifier Space For the compression and decompression of IPv4 and IPv6 datagram headers the connection identifier space is shared. While the parame- ter values are independently negotiated, sharing the connection iden- tifiers spaces becomes more complex when the parameter values differ. Since the compressed packets share connection identifier space, the compression engine must allocate connection identifiers out of a com- mon pool; for compressed packets, the decompressor has to examine the connection state to determine what parameters to use for decompres- sion. Connection identifier space is not shared between IPv6 Header Compression (TCP) and classic, Van Jacobson TCP/IP header compres- sion. Connection identifiers spaces are not shared between TCP and non-TCP/UDP/RTP. Doing so would require additional mechanisms to ensure that no error can occur when switching from using a connection identifier for TCP to non-TCP. Similarly, additional checks must be made if the connection identifier spaces of IPv6 Header Compression (TCP) is shared with classical, VJ style TCP/IP header compression to ensure that no errors occur when changing what compression algorithm is associated with a connection identifier. 4. Demultiplexing of Datagrams The specification of IPv6 Header Compression [IPv6HC] defines four header formats for different types of compressed headers. They are compressed TCP, compressed TCP with no delta encoding, compressed non-TCP with 8 bit CID and compressed non-TCP with 16 bit CID. The two non-TCP formats may be distinguished by their contents so both may use the same link-level identifier. A fifth header format, the full header is distinct from a regular header in that it carries additional information to establish shared context between the compressor and decompressor. The specification of IP/UDP/RTP Header Compression [CRTP] defines four additional formats of compressed headers. They are for compressed UDP and compressed RTP (on top of UDP), both with either Engan Expires September 1997 [Page 7] Internet Draft draft-engan-ip-compress-00.txt April 1997 8- or 16-bit CIDs. In addition, there is an explicit error message from the decompressor to the compressor. The link layer must be able to indicate these header formats with distinct values. Nine PPP Data Link Layer Protocol Field values are specified below. FULL_HEADER The frame contains a full header as specified in [CRTP] Section 3.3.1. This is the same as the FULL_HEADER specified in [IPv6HC] Section 5.3. Value: TO BE ASSIGNED 1 COMPRESSED_TCP The frame contains a datagram with a compressed header with the format as specified in [IPv6HC] Section 6a. Value: TO BE ASSIGNED 2 COMPRESSED_TCP_NODELTA The frame contains a datagram with a compressed header with the format as specified in [IPv6HC] Section 6b. Value: TO BE ASSIGNED 3 COMPRESSED_NON_TCP The frame contains a datagram with a compressed header with the format as specified in either Section 6c or Section 6d of [IPv6HC]. Value: TO BE ASSIGNED 4 COMPRESSED_RTP_8 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.2, using 8-bit CIDs. Value: TO BE ASSIGNED 5 COMPRESSED_RTP_16 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.2, using 16-bit CIDs. Value: TO BE ASSIGNED 6 COMPRESSED_UDP_8 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.3, using 8-bit CIDs. Value: TO BE ASSIGNED 7 COMPRESSED_UDP_16 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.3, using 16-bit CIDs. Value: TO BE ASSIGNED 8 Engan Expires September 1997 [Page 8] Internet Draft draft-engan-ip-compress-00.txt April 1997 CONTEXT_STATE The frame is a link-level message sent from the decompressor to the compressor as specified in [CRTP] Section 3.3.5. Value: TO BE ASSIGNED 9 4.1. Protocol Identifiers Four 8-bit and five 16-bit protocol identifiers are required for the combined IPv6 and RTP header compression schemes. If protocol iden- tifiers in the range 0x20-0xff are available, allocation of protocol identifiers for IPv6 and RTP header compression from that range is preferred. Proto ID Size Value FULL_HEADER 16 bit TO BE ASSIGNED 1 COMPRESSED_TCP 8 bit TO BE ASSIGNED 2 COMPRESSED_TCP_NODELTA 16 bit TO BE ASSIGNED 3 COMPRESSED_NON_TCP 8 bit TO BE ASSIGNED 4 COMPRESSED_RTP_8 8 bit TO BE ASSIGNED 5 COMPRESSED_RTP_16 16 bit TO BE ASSIGNED 6 COMPRESSED_UDP_8 8 bit TO BE ASSIGNED 7 COMPRESSED_UCP_16 16 bit TO BE ASSIGNED 8 CONTEXT_STATE 16 bit TO BE ASSIGNED 9 If there are no previously unused protocol identifiers in the 0x20- 0xff range the required 8-bit protocol identifiers could probably be allocated from the 0x03-0x1f range. Should it be the case that exist- ing implementations require that characters in the range 0x03-0x1f be escaped, using protocol identifiers from that range for identifica- tion of compressed packets would gain nothing compared to using 16- bit protocol identifiers. 5. References [CRTP] Casner, S., Jacobson, V., "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", Internet-Draft (work in pro- gress), April 8, 1997, expires September 1997. [IPv6HC] Degermark, M., Nordgren, B., Pink, S., "Header Compression for IPv6", Internet-Draft (work in progress), November 26, 1996, expires May 1997. [RFC2023] Haskin, E., Allan, E., "IP Version 6 over PPP", RFC 2023, October 1996. Engan Expires September 1997 [Page 9] Internet Draft draft-engan-ip-compress-00.txt April 1997 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low- Speed Serial Links", RFC 1144, February 1990. [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., "RTP: A Transport Protocol for real-time applica- tions," RFC 1889, January 1996. [RFC1661] Simpson, W., ed., "The Point-To-Point Protocol (PPP)", RFC 1661, July 1994. 6. Security Considerations The use of header compression can, in rare cases, cause the mis- delivery of packets. If necessary, confidentiality of packet contents should be assured by encryption. Encryption applied at the IP layer (e.g., using IPSEC mechanisms) precludes header compression of the encrypted headers, though compression of the outer IP header and authentication/security headers is still possible as described in [IPv6HC]. For RTP packets, full header compression is possible if the RTP payload is encrypted by itself without encrypting the UDP or RTP headers, as described in [RFC1889]. This method is appropriate when the UDP and RTP header information need not be kept confiden- tial. Negotiation of the option defined here imposes no additional security considerations beyond those that otherwise apply to PPP [RFC1661]. Engan Expires September 1997 [Page 10] Internet Draft draft-engan-ip-compress-00.txt April 1997 7. Authors' Addresses Mathias Engan CDT/Dept of Computer Communication Lulea University of Technology S-971 87 Lulea, Sweden Phone: +46 920 72288 Mobile: +46 70 522 8109 Fax: +46 920 72801 EMail: engan@cdt.luth.se Stephen L. Casner Precept Software, Inc. 1072 Arastradero Road Palo Alto, CA 94304 United States EMail: casner@precept.com Carsten Bormann Universitaet Bremen FB3 TZI Postfach 330440 D-28334 Bremen, GERMANY cabo@tzi.uni-bremen.de Phone +49.421.218-7024 Fax +49.421.218-7000 Engan Expires September 1997 [Page 11]