datatracker.ietf.org
Sign in
Version 5.6.2.p2, 2014-07-24
Report a bug

IP Header Compression over PPP
RFC 2509

Document type: RFC - Proposed Standard (February 1999; No errata)
Obsoleted by RFC 3544
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 2509 (Proposed Standard)
Responsible AD: (None)
Send notices to: No addresses provided

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

[include full document text]