IP Header Compression over PPP
RFC 3544

Document Type RFC - Proposed Standard (July 2003; No errata)
Obsoletes RFC 2509
Was draft-koren-pppext-rfc2509bis (individual in int area)
Authors Stephen Casner  , Thima Koren  , Carsten Bormann 
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 3544 (Proposed Standard)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Allison Mankin
IESG note IPHC over PPP is quite useful for tunnels and for 3GPP2 folks  - this bis adds support for ECRTP (see draft-ietf-avt-ecrtp) and some fixes that were waiting for a rev for quite a while.  Also reviewed by Thomas Narten.
Send notices to <engan@sm.luth.se>
Network Working Group                                           T. Koren
Request for Comments: 3544                                 Cisco Systems
Obsoletes: 2509                                                S. Casner
Category: Standards Track                                  Packet Design
                                                              C. Bormann
                                                 Universitaet Bremen TZI
                                                               July 2003

                     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 (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.

1.  Introduction

   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
   non-TCP packets.

   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
   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.  [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

   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
Show full document text