Network Working Group T. Koren
Request for Comments: 3544 Cisco Systems
Obsoletes: 2509 S. Casner
Category: Standards Track Packet Design
Universitaet Bremen TZI
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 (C) The Internet Society (2003). All Rights Reserved.
This document describes an option for negotiating the use of header
compression on IP datagrams transmitted over the Point-to-Point
Protocol (RFC 1661). It defines extensions to the PPP Control
Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression
may be applied to IPv4 and IPv6 datagrams in combination with TCP,
UDP and RTP transport protocols as specified in RFC 2507, RFC 2508
and RFC 3545.
The IP Header Compression (IPHC) defined in [RFC2507] 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 [RFC2508] and [RFC3545] fits within the
framework defined by IPHC so that it may also be applied to both IPv4
and IPv6 packets.
Koren, et al. Standards Track [Page 1]RFC 3544 IP Header Compression over PPP July 2003
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
used in both NCPs to negotiate parameters for the compression scheme.
This document obsoletes RFC 2509, adding two new suboptions to the IP
header compression configuration option. One suboption negotiates
usage of Enhanced RTP-Compression (specified in [RFC3545]), and the
other suboption negotiates header compression for only TCP or only
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 [RFC2507] 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 [RFC2686],
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
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. [RFC3241] updates RFC 1332 by
explicitly allowing the sending of multiple instances of the IP-
Compression-Protocol configuration option, each with a different
value for IP-Compression-Protocol. Each type of compression
protocol may independently establish its own parameters.
Koren, et al. Standards Track [Page 2]RFC 3544 IP Header Compression over PPP July 2003