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
datatracker.ietf.org