RFC 2509

IP Header Compression over PPP

📅 published February 1999, from ietf

RFC 2509: IP Header Compression over PPP 🎀

okay bestie, let's get into RFC 2509 ✨ It's a Standards Track doc, so it's a real proposed standard for the internet community. It was written by M. Engan (Effnet), S. Casner (Cisco Systems), and C. Bormann (Universitaet Bremen TZI), and it's dated February 1999. It sits in the Network Working Group series. The title block doesn't list anything it obsoletes or updates, so there's nothing to report there 💅

Status of This Memo 📋

this doc specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 📝

this doc describes an option for negotiating header compression on IP datagrams sent over the Point-to-Point Protocol [RFC1661]. It adds extensions to the PPP Control Protocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression can be applied to IPv4 and IPv6 datagrams together with TCP, UDP, and RTP transport protocols, as specified in [IPHC] and [CRTP] 🦋

1. Introduction ✨

okay so IPHC, the IP Header Compression defined in [IPHC], can compress both IPv4 and IPv6 datagrams, including packets wrapped in multiple IP headers. It's also capable of compressing both TCP and UDP transport headers. The IP/UDP/RTP header compression from [CRTP] fits inside the IPHC framework, so it can be applied to both IPv4 and IPv6 packets too. it's giving compatibility 💖

To set up compression on IP datagrams sent over a PPP link, both ends of the link have to agree on a set of configuration parameters for it. In PPP, negotiating link parameters for network layer protocols is handled by a family of network control protocols (NCPs). There's a separate NCP for IPv4 and one for IPv6, so this doc defines configuration options that both NCPs use to negotiate the compression parameters 🧚

IPHC depends on the link layer being able to indicate the types of datagrams carried in its frames. This document defines nine new types for the PPP Data Link Layer Protocol Field, along with what each one means 🌸

Generally, header compression schemes that use delta encoding of compressed packets require the lower layer to not reorder packets between the compressor and the decompressor. IPHC uses delta encoding of compressed packets for TCP and RTP. The IPHC specification [IPHC] includes methods that let link layers which may reorder packets be used with IPHC. Since PPP doesn't reorder packets, those mechanisms are disabled by default. When you use reordering mechanisms such as multiclass multilink PPP [MCML], be careful that packets sharing the same compression context don't get reordered ⚠️

2. Configuration Option 🎀

this doc specifies a new compression protocol value for the IPCP IP-Compression-Protocol option, as specified in [RFC1332]. The new value and its option format are described in Section 2.1.

The option format is structured so future extensions to the IPHC scheme can be added 🍓

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 it says that a configuration option's specification must explicitly allow multiple instances. From the current specification of the IPCP IP-Compression-Protocol configuration option [RFC1332, p 6], it follows that the option 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.

2.1. Configuration Option Format 💅

Both IPCP [RFC1332], the network control protocol for IPv4, and IPV6CP [RFC2023], the IPv6 NCP, can be used to negotiate IP Header Compression parameters for their protocols. The format of the configuration option is the same for both IPCP and IPV6CP.

Description 🧠

This NCP configuration option is used to negotiate parameters for IP Header Compression. The option format is summarized below. The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |    IP-Compression-Protocol    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           TCP_SPACE           |         NON_TCP_SPACE         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         F_MAX_PERIOD          |          F_MAX_TIME           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           MAX_HEADER          |          suboptions...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 🔢

  • 2

Length 📏

  • >= 14

The length may be increased if extra parameters are indicated by additional suboptions.

IP-Compression-Protocol 🪄

  • 0061 (hex)

TCP_SPACE 🌈

The TCP_SPACE field is two octets and indicates the maximum value of a context identifier in the space of context identifiers allocated for TCP.

  • Suggested value: 15

TCP_SPACE must be at least 0 and at most 255. (The value 0 implies having one context.)

NON_TCP_SPACE 🌈

The NON_TCP_SPACE field is two octets and indicates the maximum value of a context identifier in the space of context identifiers allocated for non-TCP. These context identifiers are carried in COMPRESSED_NON_TCP, COMPRESSED_UDP, and COMPRESSED_RTP packet headers.

  • Suggested value: 15

NON_TCP_SPACE must be at least 0 and at most 65535. (The value 0 implies having one context.)

F_MAX_PERIOD ⏳

This is the maximum interval between full headers. No more than F_MAX_PERIOD COMPRESSED_NON_TCP headers may be sent between FULL_HEADER headers.

  • Suggested value: 256

A value of zero implies infinity, which means there's no limit to the number of consecutive COMPRESSED_NON_TCP headers.

F_MAX_TIME ⏱️

This is the maximum time interval between full headers. COMPRESSED_NON_TCP headers may not be sent more than F_MAX_TIME seconds after the last FULL_HEADER header was sent.

  • Suggested value: 5 seconds

A value of zero implies infinity.

MAX_HEADER 🧩

This is the largest header size in octets that may be compressed.

  • Suggested value: 168 octets

The value of MAX_HEADER should be large enough that at least the outer network layer header can be compressed. To increase compression efficiency, MAX_HEADER should be set to a value large enough to cover common combinations of network and transport layer headers.

suboptions 🫧

The suboptions field consists of zero or more suboptions. Each suboption has a type field, a length field, and zero or more parameter octets, as defined by the suboption type. The value of the length field gives the length of the suboption in its entirety, including the lengths of the type and length fields.

             0                   1                   2
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |     Type      |    Length     |  Parameters...
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2 RTP-Compression Suboption 🦋

The RTP-Compression suboption is included in the NCP IP-Compression-Protocol option for IPHC if IP/UDP/RTP compression is to be enabled.

After successful negotiation of parameters for IP Header Compression, the use of the Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, COMPRESSED_TCP_NODELTA, and COMPRESSED_NON_TCP is enabled, regardless of the presence of an RTP-Compression suboption.

Description 💌

Enables the use of the Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP, and CONTEXT_STATE, as specified in [CRTP].

             0                   1
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |     Type      |    Length     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 🔢

  • 1

Length 📏

  • 2

3. Multiple Network Control Protocols 👑

IPHC can compress both IPv6 and IPv4 datagrams. Both IPCP and IPV6CP can negotiate option parameter values for IPHC. These values apply to compressing packets whose outer header is an IPv4 header or an IPv6 header, respectively.

3.1. Sharing Context Identifier Space 🫶

For compressing and decompressing IPv4 and IPv6 datagram headers, the context identifier space is shared. The parameter values are negotiated independently, but sharing the context identifier spaces gets more complicated when the parameter values differ. Because the compressed packets share context identifier space, the compression engine has to allocate context identifiers out of a common pool. For compressed packets, the decompressor has to look at the context state to decide which parameters to use for decompression 🧠

Context identifier spaces are not shared between TCP and non-TCP/UDP/RTP. Sharing them would require additional mechanisms to make sure no error can occur when switching a context identifier from TCP to non-TCP ⚠️

4. Demultiplexing of Datagrams ✨

okay so the IPHC spec [IPHC] defines four header formats for different kinds of compressed headers: compressed TCP, compressed TCP with no delta encoding, compressed non-TCP with an 8 bit CID, and compressed non-TCP with a 16 bit CID 🧚. The two non-TCP formats can be told apart by their contents, so they can both use the same link-level identifier 💅. Then there's a fifth one, the full header, which is different from a regular header because it carries extra info to set up shared context between the compressor and decompressor 🎀.

The IP/UDP/RTP Header Compression spec [CRTP] adds four more compressed header formats: compressed UDP and compressed RTP (on top of UDP), each with either 8- or 16-bit CIDs 🦋. It also has an explicit error message that goes from the decompressor back to the compressor 😭.

The link layer has to be able to tell these header formats apart using distinct values, and nine PPP Data Link Layer Protocol Field values are specified below 🌸. Here they are:

  • FULL_HEADER 💖: The frame has a full header as specified in [CRTP] Section 3.3.1. This is the same as the FULL_HEADER from [IPHC] Section 5.3.
    • Value: 0061 (hex)
  • COMPRESSED_TCP 🌈: The frame has a datagram with a compressed header in the format specified in [IPHC] Section 6a.
    • Value: 0063 (hex)
  • COMPRESSED_TCP_NODELTA 🍓: The frame has a datagram with a compressed header in the format specified in [IPHC] Section 6b.
    • Value: 2063 (hex)
  • COMPRESSED_NON_TCP ⭐: The frame has a datagram with a compressed header in the format specified in either Section 6c or Section 6d of [IPHC].
    • Value: 0065 (hex)
  • COMPRESSED_RTP_8 🦋: The frame has a datagram with a compressed header in the format specified in [CRTP] Section 3.3.2, using 8-bit CIDs.
    • Value: 0069 (hex)
  • COMPRESSED_RTP_16 🫶: The frame has a datagram with a compressed header in the format specified in [CRTP] Section 3.3.2, using 16-bit CIDs.
    • Value: 2069 (hex)
  • COMPRESSED_UDP_8 🌷: The frame has a datagram with a compressed header in the format specified in [CRTP] Section 3.3.3, using 8-bit CIDs.
    • Value: 0067 (hex)
  • COMPRESSED_UDP_16 💜: The frame has a datagram with a compressed header in the format specified in [CRTP] Section 3.3.3, using 16-bit CIDs.
    • Value: 2067 (hex)
  • CONTEXT_STATE 👑: The frame is a link-level message sent from the decompressor to the compressor, as specified in [CRTP] Section 3.3.5.
    • Value: 2065 (hex)

5. References 📚

Here's the full reference list, copied exactly so nothing gets lost in translation 🤓:

[CRTP]     Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
           Headers for Low-Speed Serial Links", RFC 2508, February
           1999.

[IPHC]     Degermark, M., Nordgren, B. and S. Pink, "Header
           Compression for IP", RFC 2507, February 1999.

[RFC2023]  Haskin, E. and E. Allan, "IP Version 6 over PPP", RFC
           2023, October 1996.

[RFC1144]  Jacobson, V., "Compressing TCP/IP Headers for Low- Speed
           Serial Links", RFC 1144, February 1990.

[RFC1332]  McGregor, G., "The PPP Internet Protocol Control Protocol
           (IPCP)", RFC 1332, May 1992.

[RFC1889]  Schulzrinne, H., Casner, S., Frederick, R. and V.
           Jacobson, "RTP: A Transport Protocol for real-time
           applications", RFC 1889, January 1996.

[RFC1661]  Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD
           51, RFC 1661, July 1994.

[MCML]     Bormann, C., "The Multi-Class Extension to Multi-Link
           PPP", Work in Progress.

6. Security Considerations 🔒

Okay, real talk, this part matters 🙈. Negotiating the option defined here doesn't add any security considerations beyond the ones that already apply to PPP [RFC1661] 🔐.

The use of header compression can, in rare cases, cause packets to be misdelivered 😬. If that's a concern, confidentiality of packet contents should be assured by encryption 💀.

Encryption applied at the IP layer (for example, using IPSEC mechanisms) rules out header compression of the encrypted headers 🚫. Compressing the outer IP header and the authentication/security headers is still possible, as described in [IPHC] ✅. For RTP packets, full header compression is possible if the RTP payload is encrypted by itself, without encrypting the UDP or RTP headers, as described in [RFC1889] 🎀. This approach is appropriate when the UDP and RTP header information doesn't need to stay confidential 🫧.

7. Authors' Addresses 🫶

Here are the authors' contact details, copied exactly:

Mathias Engan
Effnet
Aurorum 2
SE-977 75 Lulea, Sweden

Phone: +46 920 75600
Mobile: +46 70 833 8932
Fax: +46 920 75610
EMail: engan@effnet.com


Stephen L. Casner
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
United States

EMail: casner@cisco.com


Carsten Bormann
Universitaet Bremen FB3 TZI
Postfach 330440
D-28334 Bremen, GERMANY

Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org

Copyright (C) The Internet Society (1999). All Rights Reserved 🌈.

You're allowed to copy this document and share it with others, and you can make derivative works that comment on or explain it, or help with implementing it. You can prepare, copy, publish and distribute those, in whole or in part, with no restrictions of any kind 🦋. The one catch is that the above copyright notice and this paragraph have to stay on all copies and derivative works 🎀. However, this document itself can't be modified in any way, like by removing the copyright notice or the references to the Internet Society or other Internet organizations 🙅. The exceptions are when it's needed for developing Internet standards, in which case the Internet Standards process copyright procedures must be followed, or when it's needed to translate it into languages other than English 🌍.

The limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns ♾️.

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS, OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💅.

📦 where this page comes from