RFC 3544

IP Header Compression over PPP 🎀

okay bestie, so this is RFC 3544 🦋 a Standards Track doc from July 2003, written by T. Koren (Cisco Systems), S. Casner (Packet Design), and C. Bormann (Universitaet Bremen TZI). It's published under Network Working Group, and it obsoletes RFC 2509 💅 so anything that said 2509 is now replaced by this one. The whole point is header compression for IP packets that ride over PPP links 🌸

Status of this Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 🫶 Distribution of this memo is unlimited, so share it with everyone 🌈

Copyright Notice 🎀

Copyright (C) The Internet Society (2003). All Rights Reserved. 💜

Abstract ✨

okay so this doc describes an option for negotiating header compression on IP datagrams sent over the Point-to-Point Protocol (RFC 1661) 🫶 It adds extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472) 💅 Header compression can be applied to IPv4 and IPv6 datagrams together with TCP, UDP and RTP transport protocols, as specified in RFC 2507, RFC 2508 and RFC 3545 🔥

1. Introduction ✨

okay so the IP Header Compression (IPHC) defined in [RFC2507] can compress both IPv4 and IPv6 datagrams, or packets that are encapsulated with multiple IP headers 🧚 IPHC can also compress both TCP and UDP transport protocol headers, which is so iconic 😭 The IP/UDP/RTP header compression defined in [RFC2508] and [RFC3545] fits inside the IPHC framework, so it can be applied to both IPv4 and IPv6 packets too 💖

so here's the thing: for compression of IP datagrams over a PPP link, both ends have to agree on a set of configuration parameters 🎀 PPP handles this negotiation for network layer protocols with a family of network control protocols (NCPs) 💅 There are separate NCPs for IPv4 and IPv6, so this document defines configuration options that get used in both NCPs to negotiate the parameters for the compression scheme ✨

This document obsoletes RFC 2509 🦋 It adds two new suboptions to the IP header compression configuration option 🌸 One suboption negotiates the use of Enhanced RTP-Compression (specified in [RFC3545]) 🔥 The other suboption negotiates header compression for only TCP or only non-TCP packets 💜

IPHC relies on the link layer being able to indicate the types of datagrams carried in its frames 🧚 In this document, nine new types for the PPP Data Link Layer Protocol Field are defined, along with what they mean 🫶

in general, header compression schemes that use delta encoding of compressed packets require that the lower layer does not reorder packets between the compressor and decompressor 😭 IPHC uses delta encoding of compressed packets for TCP and RTP 💅 The IPHC specification [RFC2507] includes methods that let link layers which may reorder packets be used with IPHC 🌈 Since PPP does not reorder packets, these mechanisms are disabled by default 🎀 When you use reordering mechanisms such as multiclass multilink PPP [RFC2686], care must be taken so that packets sharing the same compression context are not reordered ⚠️

⚠️ Reordering alert: packets that share the same compression context must not be reordered when multiclass multilink PPP [RFC2686] is in use. care must be taken, bestie 🙈

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 its associated option format are described in section 2.1 ✨

The option format is structured so that future extensions to the IPHC scheme are possible 🧚

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 does state 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 💅

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 the network control protocol for IPv4, IPCP [RFC1332], and the IPv6 NCP, IPV6CP [RFC2472], may be used to negotiate IP Header Compression parameters for their respective 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 🦋 Successful negotiation of parameters enables the use of the Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP and CONTEXT_STATE, as specified in [RFC2507] ✨ The option format is summarized below, and 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 the presence of additional parameters is indicated by additional suboptions 🌸

IP-Compression-Protocol 🦋 0061 (hex)

TCP_SPACE ✨ The TCP_SPACE field is two octets, and it 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 it 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 🦋 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, i.e. there is no limit to the number of consecutive COMPRESSED_NON_TCP headers 💖

F_MAX_TIME 🫶 Maximum time interval between full headers 😭 COMPRESSED_NON_TCP headers may not be sent more than F_MAX_TIME seconds after sending the last FULL_HEADER header 🌈

Suggested value: 5 seconds 🎀

A value of zero implies infinity 💜

MAX_HEADER 🔥 The largest header size in octets that may be compressed 💅

Suggested value: 168 octets ✨

The value of MAX_HEADER should be large enough so 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 consists of a type field, a length field and zero or more parameter octets, as defined by the suboption type 🫶 The value of the length field indicates 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 💅

Including the RTP-Compression suboption enables use of the additional Protocol Identifiers COMPRESSED_RTP and COMPRESSED_UDP, along with additional forms of CONTEXT_STATE, as specified in [RFC2508] 🔥

Description 🌸

Enable use of the Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP and CONTEXT_STATE, as specified in [RFC2508] 🦋

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

Type 💖 1

Length 🧚 2

2.3. Enhanced RTP-Compression Suboption ✨

To use the enhanced RTP header compression defined in [RFC3545], a new sub-option 2 is added 🌈 Sub-option 2 is negotiated instead of, not in addition to, sub-option 1 💜

Description 🫶

Enable use of the Protocol Identifiers COMPRESSED_RTP and CONTEXT_STATE, as specified in [RFC2508] 🔥 In addition, enable use of [RFC3545] compliant compression, including the use of the Protocol Identifier COMPRESSED_UDP with additional flags, and use of the C flag with the FULL_HEADER Protocol Identifier to indicate use of HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets 🎀

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

Type 🌸 2

Length 🦋 2

2.4. Negotiating header compression for only TCP or only non-TCP packets 💅

okay so in RFC 2509, it was not possible to negotiate only TCP header compression or only non-TCP header compression 😭 That's because a value of 0 in the TCP_SPACE or the NON_TCP_SPACE fields actually means that 1 context is negotiated 🙈

A new suboption 3 is added to allow specifying that the number of contexts for TCP_SPACE or NON_TCP_SPACE is zero 🫶 This disables use of the corresponding compression 💖

Description ✨

Enable header compression for only TCP or only non-TCP packets 🧚

    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     |   Parameter   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 🌈 3

Length 💜 3

Parameter 🔥

The parameter is 1 byte, with one of the following values:

• 1 = the number of contexts for TCP_SPACE is 0 🎀
• 2 = the number of contexts for NON_TCP_SPACE is 0 💅

This suboption overrides the values that were previously assigned to TCP_SPACE and NON_TCP_SPACE in the IP Header Compression option 🌸

If suboption 3 is included multiple times with parameter 1 and 2, compression is disabled for all packets 🦋

3. Multiple Network Control Protocols 🎀

Okay so IPHC can compress both IPv6 and IPv4 datagrams 💖 IPCP and IPV6CP can both negotiate option parameter values for IPHC too. Those values apply to packets whose outer header is IPv4 and to packets whose outer header is IPv6, 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 get negotiated separately, but sharing the space gets messy once the values differ. Since the compressed packets share one space, the compression engine has to hand out context identifiers from a common pool. For compressed packets, the decompressor has to look at the context state to figure out which parameters to use for decompression. Main character energy, but make it complicated 💅

Context identifier spaces are not shared between TCP and non-TCP/UDP/RTP. Sharing them would need extra mechanisms to make sure no error can happen when a context identifier switches from TCP to non-TCP. Nobody wants that drama 🙈

4. Demultiplexing of Datagrams 🧚

The IPHC specification [RFC2507] defines four header formats for different types of compressed headers: compressed TCP, compressed TCP with no delta encoding, compressed non-TCP with 8 bit CID, and compressed non-TCP with 16 bit CID. The two non-TCP formats can be told apart by their contents, so both can use the same link-level identifier. A fifth header format is the full header. It's different from a regular header because it carries extra information to set up shared context between the compressor and decompressor 🌸

The specification of IP/UDP/RTP Header Compression [RFC2508] defines four more compressed header formats. They're for compressed UDP and compressed RTP (on top of UDP), and each comes with either 8- or 16-bit CIDs. On top of that, there's an explicit error message that goes from the decompressor back to the compressor 😭

The link layer has to be able to indicate these header formats with distinct values. Nine PPP Data Link Layer Protocol Field values are specified below. 👑

• FULL_HEADER The frame contains a full header as specified in [RFC2508] Section 3.3.1. This is the same as the FULL_HEADER specified in [RFC2507] Section 5.3. Value: 0061 (hex)
• COMPRESSED_TCP The frame contains a datagram with a compressed header with the format as specified in [RFC2507] Section 6a. Value: 0063 (hex)
• COMPRESSED_TCP_NODELTA The frame contains a datagram with a compressed header with the format as specified in [RFC2507] Section 6b. Value: 2063 (hex)
• COMPRESSED_NON_TCP The frame contains a datagram with a compressed header with the format as specified in either Section 6c or Section 6d of [RFC2507]. Value: 0065 (hex)
• COMPRESSED_RTP_8 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.2, using 8-bit CIDs. Value: 0069 (hex)
• COMPRESSED_RTP_16 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.2, using 16-bit CIDs. Value: 2069 (hex)
• COMPRESSED_UDP_8 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.3 or as specified in [RFC3545] Section 2.1, using 8-bit CIDs. Value: 0067 (hex)
• COMPRESSED_UDP_16 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.3 or as specified in [RFC3545] Section 2.1, 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 [RFC2508] Section 3.3.5. Value: 2065 (hex)

5. Changes from RFC 2509 🦋

Two new suboptions are specified. See Sections 2.3 and 2.4. ✨

6. References 📚

6.1. Normative References 💜

• [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.
• [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
• [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for IP", RFC 2507, February 1999.
• [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
• [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
• [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B. and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003.

6.2. Informative References 🌈

• [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
• [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
• [RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
• [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.

7. IANA Considerations 🍓

This document doesn't need any extra allocations from the existing namespaces in the IANA Point-to-Point Protocol Field Assignments registry. However, there are three namespaces that were defined by RFC 1332, RFC 2472, and RFC 2509 but never got created in the registry. Those three namespaces, described below, have now been added to the PPP registry. This document specifies two additional allocations in the third one 🎀

Section 3.2 of RFC 1332 specifies an IP-Compression-Protocol Configuration Option for the PPP IP Control Protocol and defines one value for the IP-Compression-Protocol type field in that option. An IANA registry has been created to allocate more values for that type field. As RFC 1332 says, the values for the IP-Compression-Protocol type field are always the same as the (primary) PPP DLL Protocol Number assigned to packets of that particular compression protocol. Extra IP-Compression-Protocol type values are assigned through the IETF consensus procedure as specified in [RFC2434].

Section 4.2 of RFC 2472 specifies an IPv6-Compression-Protocol Configuration Option for the PPP IPv6 Control Protocol and defines one value for the IPv6-Compression-Protocol type field in that option. An IANA registry has been created to allocate more values for that type field. The IPv6-Compression-Protocol Configuration Option has the same structure as the IP-Compression-Protocol Configuration Option defined in RFC 1332, but the set of values defined for the type field can be different. As RFC 2472 says, the values for the IPv6-Compression-Protocol type field are always the same as the (primary) PPP DLL Protocol Number assigned to packets of that particular compression protocol. Extra IPv6-Compression-Protocol type values are assigned through the IETF consensus procedure as specified in [RFC2434].

Section 2.1 of RFC 2509 specifies an additional type value to be registered for both the IP-Compression-Protocol Configuration Option and the IPv6-Compression-Protocol Configuration Option, to indicate use of the "IP Header Compression" protocol. That type value is specified again in Section 2.1 of this document, which obsoletes RFC 2509. Along with the additional type value, the format for the variable-length option is specified. The format includes a suboption field that can contain one or more suboptions. Each suboption begins with a suboption type value. An IANA registry has been created for the suboption type values, and it's titled "IP Header Compression Configuration Option Suboption Types". 💖

Section 2.2 of RFC 2509 (and this document) defines one suboption type. Sections 2.3 and 2.4 of this document define two additional suboption types. The number of additional suboptions that will need defining is expected to be small. So anyone who wants to define new suboptions is required to produce a revision of this document, to be vetted through the normal Internet Standards process, as specified in [RFC2434] 🧐

RFC 2509 also defines nine PPP Data Link Layer Protocol Field values, which are already listed in the IANA registry of Point-to-Point Protocol Field Assignments. Section 4 of this document repeats the specification of those values without change ✨

8. Security Considerations 🔥

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. Compression of the outer IP header and of authentication/security headers is still possible, as described in [RFC2507]. 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 [RFC3550]. This method is appropriate when the UDP and RTP header information doesn't need to stay confidential 🙈

9. Intellectual Property Rights Notice 🌸

The IETF takes no position on the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication, and any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for implementors or users of this specification to use such proprietary rights, can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

10. Acknowledgements 💜

Mathias Engan was the primary author of RFC 2509, which this document revises 🫶

11. Authors' Addresses 🧚

Tmima Koren
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
United States

EMail: tmima@cisco.com


Stephen L. Casner
Packet Design
3400 Hillview Avenue, Building 3
Palo Alto, CA 94304
United States

EMail: casner@packetdesign.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

12. Full Copyright Statement ✨

Okay bestie, time for the legal stuff 📜 Copyright (C) The Internet Society (2003). All Rights Reserved. 💖

People are allowed to copy this document and share it with others, and to make derivative works that comment on it, explain it, or help people implement it. They can publish and distribute those in whole or in part with no restrictions, as long as the copyright notice and this paragraph are included on every copy and derivative work. 🎀

Here's the catch: the document itself may not be modified in any way. You can't remove 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 (then the copyright procedures in the Internet Standards process must be followed), or when it's translated into a language other than English 🌈

The limited permissions above are perpetual. The Internet Society and its successors or assignees will not revoke them 🦋

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 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

---

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. The people keeping these RFCs organized get a big thank-you from us 🌸