IP Header Compression over PPP
RFC 2509
Document | Type |
RFC - Proposed Standard
(February 1999; No errata)
Obsoleted by RFC 3544
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2509 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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.Show full document text