RFC 2509 (rfc2509) - Page 2 of 10

IP Header Compression over PPP

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 [RFC 1332].  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 [RFC 1661], [RFC 1331], [RFC 1332] 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 [RFC 1332, p 6]
      it follows that it can only be used to select a single compression
      protocol at any time.

      NOTE: [RFC 1332] 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