diff options
Diffstat (limited to 'doc/rfc/rfc2509.txt')
| -rw-r--r-- | doc/rfc/rfc2509.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc2509.txt b/doc/rfc/rfc2509.txt new file mode 100644 index 0000000..7cb43c7 --- /dev/null +++ b/doc/rfc/rfc2509.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group +Request for Comments: 2509 M. Engan +Category: Standards Track Effnet + S. Casner + Cisco Systems + C. Bormann + Universitaet Bremen TZI + February 1999 + + + IP Header Compression over PPP + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +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 [IPHC] and [CRTP]. + +1. Introduction + + The IP Header Compression (IPHC) defined in [IPHC] may be used for + compression of both IPv4 and IPv6 datagrams or packets encapsulated + with multiple IP headers. IPHC is also capable of compressing both + TCP and UDP transport protocol headers. The IP/UDP/RTP header + compression defined in [CRTP] fits within the framework defined by + IPHC so that it may also be applied to both IPv4 and IPv6 packets. + + 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 + parameters 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). Since there are separate NCPs + for IPv4 and IPv6, this document defines configuration options to be + + + +Engan, et. al. Standards Track [Page 1] + +RFC 2509 IP Header Compression over PPP February 1999 + + + used in both NCPs to negotiate parameters for the compression scheme. + + IPHC 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. + + In general, header compression schemes that use delta encoding of + compressed packets require that the lower layer does not reorder + packets between compressor and decompressor. IPHC uses delta encoding + of compressed packets for TCP and RTP. The IPHC specification [IPHC] + includes methods that allow link layers that may reorder packets to + be used with IPHC. Since PPP does not reorder packets these + mechanisms are disabled by default. When using reordering mechanisms + such as multiclass multilink PPP [MCML], care must be taken so that + packets that share the same compression context are not reordered. + +2. Configuration Option + + This document specifies a new compression protocol value for the IPCP + IP-Compression-Protocol option as specified in [RFC1332]. The new + value and the associated option format are described in section 2.1. + + The option format is structured to allow future extensions to the + IPHC scheme. + + NOTE: 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 explicitly + 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 time. + + NOTE: [RFC1332] is not explicit about whether the option + negotiates the capabilities of the receiver or of the sender. In + keeping with current practice, we assume that the option describes + the capabilities of the decompressor (receiving side) of the peer + that sends the Config-Req. + + + + + + + + + + + +Engan, et. al. Standards Track [Page 2] + +RFC 2509 IP Header Compression over PPP February 1999 + + +2.1. 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. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TCP_SPACE | NON_TCP_SPACE | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | F_MAX_PERIOD | F_MAX_TIME | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAX_HEADER | suboptions... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 2 + + Length + >= 14 + + The length may be increased if the presence of additional + parameters is indicated by additional suboptions. + + IP-Compression-Protocol + 0061 (hex) + + TCP_SPACE + The TCP_SPACE field is two octets and indicates the maximum value + of a context identifier in the space of context identifiers + allocated for TCP. + + Suggested value: 15 + + TCP_SPACE must be at least 0 and at most 255 (The value 0 implies + having one context). + + + + + +Engan, et. al. Standards Track [Page 3] + +RFC 2509 IP Header Compression over PPP February 1999 + + + NON_TCP_SPACE + The NON_TCP_SPACE field is two octets and indicates the maximum + value of a context identifier in the space of context identifiers + allocated for non-TCP. These context identifiers are carried in + COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet + headers. + + Suggested value: 15 + + NON_TCP_SPACE must be at least 0 and at most 65535 (The value 0 + implies having one context). + + 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, i.e. there is no limit to the + number of consecutive COMPRESSED_NON_TCP headers. + + 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. + + suboptions + The suboptions field consists of zero or more suboptions. Each + suboption consists of a type field, a length field and zero or + more parameter octets, as defined by the suboption type. The + value of the length field indicates the length of the suboption in + its entirety, including the lengths of the type and length fields. + + + +Engan, et. al. Standards Track [Page 4] + +RFC 2509 IP Header Compression over PPP February 1999 + + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Parameters... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.2 RTP-Compression Suboption + + The RTP-Compression suboption is included in the NCP + IP-Compression-Protocol option for IPHC if IP/UDP/RTP compression is + to be enabled. + + After successful negotiation of parameters for IP Header Compression + the use of Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, + COMPRESSED_TCP_NODELTA and COMPRESSED_NON_TCP is enabled, regardless + of the prescence of an RTP-Compression suboption. + + Description + + Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP and + CONTEXT_STATE as specified in [CRTP]. + + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 1 + + Length + 2 + +3. Multiple Network Control Protocols + + The IPHC protocol is able to compress both IPv6 and IPv4 datagrams. + Both IPCP and IPV6CP are able to negotiate option parameter values + for IPHC. These values apply to the compression of packets where the + outer header is an IPv4 header and an IPv6 header, respectively. + +3.1. Sharing Context Identifier Space + + For the compression and decompression of IPv4 and IPv6 datagram + headers the context identifier space is shared. While the parameter + values are independently negotiated, sharing the context identifier + spaces becomes more complex when the parameter values differ. Since + + + +Engan, et. al. Standards Track [Page 5] + +RFC 2509 IP Header Compression over PPP February 1999 + + + the compressed packets share context identifier space, the + compression engine must allocate context identifiers out of a common + pool; for compressed packets, the decompressor has to examine the + context state to determine what parameters to use for decompression. + + Context identifier 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 context + identifier for TCP to non-TCP. + +4. Demultiplexing of Datagrams + + The IPHC specification [IPHC] 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 + 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 [IPHC] + Section 5.3. + Value: 0061 (hex) + + COMPRESSED_TCP + The frame contains a datagram with a compressed header with the + format as specified in [IPHC] Section 6a. + Value: 0063 (hex) + + COMPRESSED_TCP_NODELTA + The frame contains a datagram with a compressed header with the + format as specified in [IPHC] Section 6b. + Value: 2063 (hex) + + + + +Engan, et. al. Standards Track [Page 6] + +RFC 2509 IP Header Compression over PPP February 1999 + + + 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 + [IPHC]. + Value: 0065 (hex) + + 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: 0069 (hex) + + 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: 2069 (hex) + + 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: 0067 (hex) + + 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: 2067 (hex) + + 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: 2065 (hex) + +5. References + + [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP + Headers for Low-Speed Serial Links", RFC 2508, February + 1999. + + [IPHC] Degermark, M., Nordgren, B. and S. Pink, "Header + Compression for IP", RFC 2507, February 1999. + + [RFC2023] Haskin, E. and E. Allan, "IP Version 6 over PPP", RFC + 2023, October 1996. + + [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. + + + +Engan, et. al. Standards Track [Page 7] + +RFC 2509 IP Header Compression over PPP February 1999 + + + [RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V. + Jacobson, "RTP: A Transport Protocol for real-time + applications", RFC 1889, January 1996. + + [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [MCML] Bormann, C., "The Multi-Class Extension to Multi-Link + PPP", Work in Progress. + +6. Security Considerations + + Negotiation of the option defined here imposes no additional security + considerations beyond those that otherwise apply to PPP [RFC1661]. + + The use of header compression can, in rare cases, cause the + misdelivery 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 [IPHC]. 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 confidential. + + + + + + + + + + + + + + + + + + + + + + + + +Engan, et. al. Standards Track [Page 8] + +RFC 2509 IP Header Compression over PPP February 1999 + + +7. Authors' Addresses + + Mathias Engan + Effnet + Aurorum 2 + SE-977 75 Lulea, Sweden + + Phone: +46 920 75600 + Mobile: +46 70 833 8932 + Fax: +46 920 75610 + EMail: engan@effnet.com + + + Stephen L. Casner + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + United States + + EMail: casner@cisco.com + + + Carsten Bormann + Universitaet Bremen FB3 TZI + Postfach 330440 + D-28334 Bremen, GERMANY + + Phone: +49.421.218-7024 + Fax: +49.421.218-7000 + EMail: cabo@tzi.org + + + + + + + + + + + + + + + + + + + + + +Engan, et. al. Standards Track [Page 9] + +RFC 2509 IP Header Compression over PPP February 1999 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Engan, et. al. Standards Track [Page 10] + |