RFC 6846
RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) 💖
Okay bestie, meet RFC 6846 🎀 It's an IETF Standards Track document from January 2013, so it's official Internet protocol business, and it has ISSN 2070-1721. It was written by G. Pelletier (InterDigital Communications), K. Sandlund (Ericsson), L-E. Jonsson (Ericsson), and M. West (Siemens/Roke Manor). ✨
The big news is that this one obsoletes RFC 4996, so if you're still reading that one, it's time to switch. 🦋
Abstract 🌸
Okay so this doc specifies a RObust Header Compression (ROHC) profile for squishing down TCP/IP packets 📦 The profile is called ROHC-TCP, and it gives you efficient, robust compression of TCP headers. That includes the frequently used TCP options, like selective acknowledgments (SACKs) and Timestamps 💅
ROHC-TCP works really well over links with significant error rates and long round-trip times. And honestly? Lots of bandwidth-limited links where header compression is essential have exactly those vibes, so it's a whole mood 😭
This spec obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies some of the other compression methods being used 🧚
Status of This Memo 🌈
This is an Internet Standards Track document. 🔥
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📚
For the latest status, any errata, and where to send feedback, head to http://www.rfc-editor.org/info/rfc6846. 💜
Copyright Notice 🍓
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Read those carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️
Table of Contents 🦋
1. Introduction ....................................................5
2. Terminology .....................................................5
3. Background ......................................................7
3.1. Existing TCP/IP Header Compression Schemes .................7
3.2. Classification of TCP/IP Header Fields .....................8
4. Overview of the TCP/IP Profile (Informative) ...................10
4.1. General Concepts ..........................................10
4.2. Compressor and Decompressor Interactions ..................10
4.2.1. Compressor Operation ...............................10
4.2.2. Decompressor Feedback ..............................11
4.3. Packet Formats and Encoding Methods .......................11
4.3.1. Compressing TCP Options ............................11
4.3.2. Compressing Extension Headers ......................11
4.4. Expected Compression Ratios with ROHC-TCP .................12
5. Compressor and Decompressor Logic (Normative) ..................13
5.1. Context Initialization ....................................13
5.2. Compressor Operation ......................................13
5.2.1. Compression Logic ..................................13
5.2.1.1. Optimistic Approach .......................14
5.2.1.2. Periodic Context Refreshes ................14
5.2.2. Feedback Logic .....................................14
5.2.2.1. Optional Acknowledgments (ACKs) ...........14
5.2.2.2. Negative Acknowledgments (NACKs) ..........15
5.2.3. Context Replication ................................15
5.3. Decompressor Operation ....................................16
5.3.1. Decompressor States and Logic ......................16
5.3.1.1. Reconstruction and Verification ...........16
5.3.1.2. Detecting Context Damage ..................17
5.3.1.3. No Context (NC) State .....................18
5.3.1.4. Static Context (SC) State .................18
5.3.1.5. Full Context (FC) State ...................19
5.3.2. Feedback Logic .....................................19
5.3.3. Context Replication ................................20
6. Encodings in ROHC-TCP (Normative) ..............................20
6.1. Control Fields in ROHC-TCP ................................20
6.1.1. Master Sequence Number (MSN) .......................20
6.1.2. IP-ID Behavior .....................................21
6.1.3. Explicit Congestion Notification (ECN) .............22
6.2. Compressed Header Chains ..................................22
6.3. Compressing TCP Options with List Compression .............24
6.3.1. List Compression ...................................25
6.3.2. Table-Based Item Compression .......................26
6.3.3. Encoding of Compressed Lists .......................26
6.3.4. Item Table Mappings ................................28
6.3.5. Compressed Lists in Dynamic Chain ..................30
6.3.6. Irregular Chain Items for TCP Options ..............30
6.3.7. Replication of TCP Options .........................30
6.4. Profile-Specific Encoding Methods .........................31
6.4.1. inferred_ip_v4_header_checksum .....................31
6.4.2. inferred_mine_header_checksum ......................31
6.4.3. inferred_ip_v4_length ..............................32
6.4.4. inferred_ip_v6_length ..............................32
6.4.5. inferred_offset ....................................33
6.4.6. baseheader_extension_headers .......................33
6.4.7. baseheader_outer_headers ...........................34
6.4.8. Scaled Encoding of Fields ..........................34
6.4.8.1. Scaled TCP Sequence Number Encoding .......35
6.4.8.2. Scaled Acknowledgment Number Encoding .....35
6.5. Encoding Methods with External Parameters .................36
7. Packet Types (Normative) .......................................38
7.1. Initialization and Refresh (IR) Packets ...................38
7.2. Context Replication (IR-CR) Packets .......................40
7.3. Compressed (CO) Packets ...................................42
8. Header Formats (Normative) .....................................43
8.1. Design Rationale for Compressed Base Headers ..............44
8.2. Formal Definition of Header Formats .......................47
8.3. Feedback Formats and Options ..............................88
8.3.1. Feedback Formats ...................................88
8.3.2. Feedback Options ...................................89
8.3.2.1. The REJECT Option .........................89
8.3.2.2. The MSN-NOT-VALID Option ..................90
8.3.2.3. The MSN Option ............................90
8.3.2.4. The CONTEXT_MEMORY Feedback Option ........91
8.3.2.5. Unknown Option Types ......................91
9. Changes from RFC 4996 ..........................................91
9.1. Functional Changes ........................................91
9.2. Non-functional Changes ....................................92
10. Security Considerations .......................................92
11. IANA Considerations ...........................................93
12. Acknowledgments ...............................................93
13. References ....................................................93
13.1. Normative References .....................................93
13.2. Informative References ...................................941. Introduction ✨
Okay so there are a bunch of reasons to do header compression on low- or medium-speed links for TCP/IP traffic 🐢 These have already been covered in [RFC2507]. Robustness is a whole other priority for a TCP [RFC0793] compression scheme, and [RFC4163] explains why it matters so much 💅 The existing TCP/IP header compression schemes ([RFC1144], [RFC2507]) are kinda limited when it comes to the TCP options field, and they can't compress the headers of handshaking packets (SYNs and FINs) 🙈
So it's really desirable for a header compression scheme to handle loss on the link between the compression and decompression points, and loss that happens before the compression point 🫶 It also needs to figure out how to compress short-lived TCP transfers and TCP options efficiently, like selective acknowledgments (SACK) ([RFC2018], [RFC2883]) and Timestamps ([RFC1323]) 🔥 Some TCP options are used less often, so they don't have to be compressed by the protocol. They can just be passed through transparently, without hurting the overall compression efficiency of the rest of the TCP header 🌸
The Robust Header Compression (ROHC) Working Group built a header compression framework that can host different profiles, for different protocol sets or different compression strategies 🧚 This document defines a TCP/IP compression profile for that ROHC framework [RFC5795], and it's compliant with the requirements listed in [RFC4163] 👑
Specifically, it describes a header compression scheme for TCP/IP header compression (ROHC-TCP) that's robust against packet loss. It also has enhanced capabilities, especially for compressing header fields, including TCP options 💜 The profile identifier for TCP/IP compression is 0x0006 ⭐
2. Terminology ✨
okay bestie, let's get into the vocab 🎀 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read the way [RFC2119] describes, no cap 💅
this doc also borrows some terms from [RFC5795]. on top of that, it uses or defines these terms:
Base context
The base context is a context that has been validated by both the compressor and the decompressor. A base context can be used as the reference when building a new context using replication. 🦋
Base Context Identifier (Base CID)
The Base CID is the CID that identifies the base context, from which information needed for context replication can be extracted. 🧚
Base header
The Base header is a compressed representation of the innermost IP and TCP headers of the uncompressed packet. 💜
Chaining of items
A chain groups fields based on similar characteristics. ROHC-TCP defines chain items for static, dynamic, replicable, or irregular fields. Chaining is done by appending an item for each header, e.g., to the chain in their order of appearance in the uncompressed packet. Chaining is useful to construct compressed headers from an arbitrary number of any of the protocol headers for which ROHC-TCP defines a compressed format. It's giving organized chaos 🌈
Context Replication (CR)
Context replication is the mechanism that establishes and initializes a new context based on another existing valid context (a base context). This mechanism is introduced to reduce the overhead of the context establishment procedure, and is especially useful for compression of multiple short-lived TCP connections that may be occurring simultaneously or near-simultaneously. This is literally the main character move 👑
ROHC-TCP packet types
ROHC-TCP uses three different packet types: the Initialization and Refresh (IR) packet type, the Context Replication (IR-CR) packet type, and the Compressed packet (CO) type. Three packet types, three vibes 🍓
Short-lived TCP transfer
Short-lived TCP transfers refer to TCP connections transmitting only small amounts of packets for each single connection. 🌸
3. Background 🎀
okay so this section gives you the backstory on TCP/IP header compression 💖 the basics of general header compression are in [RFC5795]. the next subsections cover two existing TCP/IP header compression schemes and their limitations, then how TCP/IP header fields are classified, and finally some traits of short-lived TCP transfers. ngl it's a lot but it's so worth it 🫶
A behavior analysis of TCP/IP header fields is found in [RFC4413].
3.1. Existing TCP/IP Header Compression Schemes ✨
Compressed TCP (CTCP) and IP Header Compression (IPHC) are two different schemes that may be used to compress TCP/IP headers. Both schemes transmit only the differences from the previous header in order to reduce the size of the TCP/IP header. 💅
The CTCP [RFC1144] compressor detects transport-level retransmissions and sends a header that updates the context completely when they occur. While CTCP works well over reliable links, it is vulnerable when used over less reliable links as even a single packet loss results in loss of synchronization between the compressor and the decompressor. This in turn leads to the TCP receiver discarding all remaining packets in the current window because of a checksum error. This effectively prevents the TCP fast retransmit algorithm [RFC5681] from being triggered. In such a case, the compressor must wait until TCP times out and retransmits a packet to resynchronize. 😭 the MUST here is literally the worst part
To reduce the errors due to the inconsistent contexts between compressor and decompressor when compressing TCP, IPHC [RFC2507] improves somewhat on CTCP by augmenting the repair mechanism of CTCP with a local repair mechanism called TWICE and with a link-layer mechanism based on negative acknowledgments to request a header that updates the context. 🦋
The TWICE algorithm assumes that only the Sequence Number field of TCP segments is changing with the deltas between consecutive packets being constant in most cases. This assumption is, however, not always true, especially when TCP Timestamps and SACK options are used. 🙈
The full header request mechanism requires a feedback channel that may be unavailable in some circumstances. This channel is used to explicitly request that the next packet be sent with an uncompressed header to allow resynchronization without waiting for a TCP timeout. 🧚
In addition, this mechanism does not perform well on links with long round-trip times. 🥲
Both CTCP and IPHC are also limited in their handling of the TCP options field. For IPHC, any change in the options field (caused by Timestamps or SACK, for example) renders the entire field uncompressible, while for CTCP, such a change in the options field effectively disables TCP/IP header compression altogether. 💀
Finally, existing TCP/IP compression schemes do not compress the headers of handshaking packets (SYNs and FINs). Compressing these packets may greatly improve the overall header compression ratio for the cases where many short-lived TCP connections share the same channel. 🌈
3.2. Classification of TCP/IP Header Fields ✨
Header compression is possible due to the fact that there is much redundancy between header field values within packets, especially between consecutive packets. To utilize these properties for TCP/IP header compression, it is important to understand the change patterns of the various header fields. 🎀
All fields of the TCP/IP packet header have been classified in detail in [RFC4413]. The main conclusion is that most of the header fields can easily be compressed away since they seldom or never change. The following fields do, however, require more sophisticated mechanisms:
- IPv4 Identification (16 bits) - IP-ID
- TCP Sequence Number (32 bits) - SN
- TCP Acknowledgment Number (32 bits)
- TCP Reserved ( 4 bits)
- TCP ECN flags ( 2 bits) - ECN
- TCP Window (16 bits)
- TCP Options
o Maximum Segment Size (32 bits) - MSS
o Window Scale (24 bits) - WSCALE
o SACK Permitted (16 bits)
o TCP SACK (80, 144, 208, or 272 bits) - SACK
o TCP Timestamp (80 bits) - TSThe assignment of IP-ID values can be done in various ways, usually one of sequential, sequential jump, or random, as described in Section 4.1.3 of [RFC4413]. Some IPv4 stacks do use a sequential assignment when generating IP-ID values but do not transmit the contents of this field in network byte order; instead, it is sent with the two octets reversed. In this case, the compressor can compress the IP-ID field after swapping the bytes. Consequently, the decompressor also swaps the bytes of the IP-ID after decompression to regenerate the original IP-ID. With respect to TCP compression, the analysis in [RFC4413] reveals that there is no obvious candidate among the TCP fields suitable to infer the IP-ID. 🔥
The change pattern of several TCP fields (Sequence Number, Acknowledgment Number, Window, etc.) is very hard to predict. Of particular importance to a TCP/IP header compression scheme is the understanding of the sequence and acknowledgment numbers [RFC4413]. 🙈
Specifically, the TCP Sequence Number can be anywhere within a range defined by the TCP Window at any point on the path (i.e., wherever a compressor might be deployed). Missing packets or retransmissions can cause the TCP Sequence Number to fluctuate within the limits of this window. The TCP Window also bounds the jumps in acknowledgment number. 🧚
Another important behavior of the TCP/IP header is the dependency between the sequence number and the acknowledgment number. TCP connections can be either near-symmetrical or show a strong asymmetrical bias with respect to the data traffic. In the latter case, the TCP connections mainly have one-way traffic (Web browsing and file downloading, for example). This means that on the forward path (from server to client), only the sequence number is changing while the acknowledgment number remains constant for most packets; on the backward path (from client to server), only the acknowledgment number is changing and the sequence number remains constant for most packets. A compression scheme for TCP should thus have packet formats suitable for either cases, i.e., packet formats that can carry either only sequence number bits, only acknowledgment number bits, or both. 💖
In addition, TCP flows can be short-lived transfers. Short-lived TCP transfers will degrade the performance of header compression schemes that establish a new context by initially sending full headers. Multiple simultaneous or near simultaneous TCP connections may exhibit much similarity in header field values and context values among each other, which would make it possible to reuse information between flows when initializing a new context. A mechanism to this end, context replication [RFC4164], makes the context establishment step faster and more efficient, by replicating part of an existing context to a new flow. The conclusion from [RFC4413] is that part of the IP sub-context, some TCP fields, and some context values can be replicated since they seldom change or change with only a small jump. ✨
ROHC-TCP also compresses the following headers: IPv6 Destination Options header [RFC2460], IPv6 Routing header [RFC2460], IPv6 Hop-by-Hop Options header [RFC2460], Authentication Header (AH) [RFC4302], Generic Routing Encapsulation (GRE) [RFC2784][RFC2890], and the Minimal Encapsulation (MINE) header [RFC2004]. 🌸
Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any special treatment in this document, for reasons similar to those described in [RFC3095]. 🦋
4. Overview of the TCP/IP Profile (Informative) 🧚
4.1. General Concepts 💅
ROHC-TCP uses the ROHC protocol as described in [RFC5795]. ROHC-TCP supports context replication as defined in [RFC4164]. Context replication can be particularly useful for short-lived TCP flows [RFC4413]. 👑
4.2. Compressor and Decompressor Interactions 🫶
4.2.1. Compressor Operation 🌈
Header compression with ROHC can be conceptually characterized as the interaction of a compressor with a decompressor state machine. The compressor's task is to minimally send the information needed to successfully decompress a packet, based on a certain confidence regarding the state of the decompressor context. 💖
For ROHC-TCP compression, the compressor normally starts compression with the initial assumption that the decompressor has no useful information to process the new flow, and sends Initialization and Refresh (IR) packets. Alternatively, the compressor may also support Context Replication (CR) and use IR-CR packets [RFC4164], which attempts to reuse context information related to another flow. 🎀
The compressor can then adjust the compression level based on its confidence that the decompressor has the necessary information to successfully process the Compressed (CO) packets that it selects. In other words, the task of the compressor is to ensure that the decompressor operates in the state that allows decompression of the most efficient CO packet(s), and to allow the decompressor to move to that state as soon as possible otherwise. 🦋
4.2.2. Decompressor Feedback ✨
okay bestie, ROHC-TCP works fine with or without feedback going from the decompressor back to the compressor 🦋. BUT here's the tea 🫖: if a ROHC feedback channel exists AND the decompressor uses it at least once for a specific ROHC-TCP context, ROHC-TCP assumes that channel will keep getting used for the ENTIRE compression operation for that context. no cap 💅 If the feedback channel disappears, compression should be restarted 💀.
Getting either positive acknowledgments (ACKs) or negative acknowledgments (NACKs) is what establishes the feedback channel from the decompressor for the context the feedback was received for 🎀. Once a context has an established feedback channel, the compressor should use that feedback to estimate the current state of the decompressor. This is so good for compression efficiency because it hands the compressor the info it needs to reach the confidence level it wants 💖.
The ROHC-TCP feedback mechanism is kinda limited by how many least significant bit (LSB) encoded master sequence number (MSN) (see Section 6.1.1) bits get used in the FEEDBACK-2 format (see Section 8.3) 🙈. It is not suitable for a decompressor to use feedback at all where the MSN bits in the feedback could wrap around within one round-trip time. Instead, unidirectional operation -- where the compressor periodically sends larger context-updating packets -- is more appropriate 🌸.
4.3. Packet Formats and Encoding Methods 🧚
The packet formats and encoding methods used for ROHC-TCP are defined using the formal notation [RFC4997]. The formal notation is used to provide an unambiguous representation of the packet formats and a clear definition of the encoding methods 📐.
4.3.1. Compressing TCP Options 💜
The TCP options in ROHC-TCP are compressed using a list compression encoding. This lets option content get established so TCP options can be added to the context without having to send all TCP options uncompressed, which is honestly iconic 👑.
4.3.2. Compressing Extension Headers 🌈
ROHC-TCP compresses the extension headers as listed in Section 3.2. These headers are treated exactly like other headers, so they get a static chain, a dynamic chain, an irregular chain, and a chain for context replication (Section 6.2) 🧚.
This means that headers appearing in or disappearing from the flow being compressed will lead to changes to the static chain. However, the change pattern of extension headers is not deemed to impair compression efficiency with respect to this design strategy. not me being impressed 😭✨.
4.4. Expected Compression Ratios with ROHC-TCP 📊
Here's a table of typical compression ratios you can expect when using ROHC-TCP and IPHC [RFC2507] 🍓.
The figures in the table assume that the compression context has already been properly initialized. For the TS option, the Timestamp is assumed to change with small values. All TCP options include a suitable number of No Operation (NOP) options [RFC0793] for padding and/or alignment. Finally, in the examples for IPv4, a sequential IP-ID behavior is assumed 🌸.
Total Header Size (octets)
ROHC-TCP IPHC
Unc. DATA ACK DATA ACK
IPv4+TCP+TS 52 8 8 18 18
IPv4+TCP+TS 52 7 6 16 16 (1)
IPv6+TCP+TS 72 8 7 18 18
IPv6+TCP+no opt 60 6 5 6 6
IPv6+TCP+SACK 80 - 15 - 80 (2)
IPv6+TCP+SACK 80 - 9 - 26 (3)
(1) The payload size of the data stream is constant.
(2) The SACK option appears in the header, but was not present
in the previous packet. Two SACK blocks are assumed.
(3) The SACK option appears in the header, and was also present
in the previous packet (with different SACK blocks).
Two SACK blocks are assumed.The table below shows the typical initial compression ratios for ROHC-TCP and IPHC. The data stream in the example is assumed to be IPv4+TCP, with a sequential behavior for the IP-ID. The following options are assumed present in the SYN packet: TS, MSS, and WSCALE, with an appropriate number of NOP options 🎀.
Total Header Size (octets)
Unc. ROHC-TCP IPHC
1st packet (SYN) 60 49 60
2nd packet 52 12 52The figures in the table assume that the compressor has received an acknowledgment from the decompressor before compressing the second packet, which can be expected when feedback is used in ROHC-TCP.
This is because in the most common case, the TCP ACKs are expected to take the same return path, and because TCP does not send more packets until the TCP SYN packet has been acknowledged. the TCP vibes are just so consistent 🫶.
5. Compressor and Decompressor Logic (Normative) 🎀
5.1. Context Initialization 🌸
The static context of ROHC-TCP flows can be initialized in either of two ways:
- By using an IR packet as in Section 7.1, where the profile number is
0x06and the static chain ends with the static part of a TCP header. - By replicating an existing context using the mechanism defined by [RFC4164]. This is done with the IR-CR packet defined in Section 7.2, where the profile number is
0x06.
5.2. Compressor Operation 🦋
5.2.1. Compression Logic 🧠
The task of the compressor is to determine what data must be sent when compressing a TCP/IP packet, so that the decompressor can successfully reconstruct the original packet based on its current state. The selection of the type of compressed header to send thus depends on a number of factors, including:
- The change behavior of header fields in the flow, e.g., conveying the necessary information within the restrictions of the set of available packet formats.
- The compressor's level of confidence regarding decompressor state, e.g., by selecting header formats updating the same type of information for a number of consecutive packets or from the reception of decompressor feedback (ACKs and/or NACKs).
- Additional robustness required for the flow, e.g., periodic refreshes of static and dynamic information using IR and IR-DYN packets when decompressor feedback is not expected.
The impact of these factors on the compressor's packet type selection is described in more detail in the following subsections.
In this section, a "higher compression state" means that less data will be sent in compressed packets, i.e., smaller compressed headers are used, while a lower compression state means that a larger amount of data will be sent using larger compressed headers. so it's basically a dial 🎚️✨.
5.2.1.1. Optimistic Approach 🌈
The optimistic approach is the principle by which a compressor sends the same type of information for a number of packets (consecutively or not) until it is fairly confident that the decompressor has received the information. The optimistic approach is useful to ensure robustness when ROHC-TCP is used to compress packets over lossy links 🛡️.
Therefore, if field X in the uncompressed packet changes value, the compressor MUST use a packet type that contains an encoding for field X until it has gained confidence that the decompressor has received at least one packet containing the new value for X. The compressor SHOULD choose a compressed format with the smallest header that can convey the changes needed to fulfill the optimistic approach condition used. ur cute little headers, bestie 🧚💖.
5.2.1.2. Periodic Context Refreshes 🔄
When the optimistic approach is used, there will always be a possibility of decompression failures since the decompressor may not have received sufficient information for correct decompression. this is the sad part, not gonna lie 🥺.
Therefore, until the decompressor has established a feedback channel, the compressor SHOULD periodically move to a lower compression state and send IR and/or IR-DYN packets. These refreshes can be based on timeouts, on the number of compressed packets sent for the flow, or any other strategy specific to the implementation. Once the feedback channel is established, the decompressor MAY stop performing periodic refreshes ✨.
5.2.2. Feedback Logic 💌
The semantics of feedback messages, acknowledgments (ACKs) and negative acknowledgments (NACKs or STATIC-NACKs), are defined in Section 5.2.4.1 of [RFC5795].
5.2.2.1. Optional Acknowledgments (ACKs) 🫧
The compressor MAY use acknowledgment feedback (ACKs) to move to a higher compression state.
Upon reception of an ACK for a context-updating packet, the compressor obtains confidence that the decompressor has received the acknowledged packet and that it has observed changes in the packet flow up to the acknowledged packet. the compressor is getting its confidence arc 💅.
This functionality is optional, so a compressor MUST NOT expect to get such ACKs, even if a feedback channel is available and has been established for that flow. so don't count on it, bestie 🙈.
5.2.2.2. Negative Acknowledgments (NACKs) 🚨
The compressor uses feedback from the decompressor to move to a lower compression state (NACKs).
On reception of a NACK feedback, the compressor SHOULD:
- assume that only the static part of the decompressor is valid, and
- re-send all dynamic information (via an IR or IR-DYN packet) the next time it compresses a packet for the indicated flow
unless it has confidence that information sent after the packet being acknowledged already provides a suitable response to the NACK feedback. In addition, the compressor MAY use a CO packet carrying a 7-bit Cyclic Redundancy Check (CRC) if it can determine with enough confidence what information provides a suitable response to the NACK feedback. a tiny CRC, but make it count 🧮.
On reception of a STATIC-NACK feedback, the compressor SHOULD:
- assume that the decompressor has no valid context, and
- re-send all static and all dynamic information (via an IR packet) the next time it compresses a packet for the indicated flow
unless it has confidence that information sent after the packet that is being acknowledged already provides a suitable response to the STATIC-NACK feedback. full reset energy, but make it iconic 😭👑.
5.2.3. Context Replication 👯
A compressor MAY support context replication by implementing the additional compression and feedback logic defined in [RFC4164]. copying contexts like it's a group project 💜.
5.3. Decompressor Operation 🎀
5.3.1. Decompressor States and Logic ✨
okay so the decompressor has three states: No Context (NC), Static Context (SC), and Full Context (FC) 🎀. it starts out in the lowest one, NC. once it decompresses something successfully, it jumps straight up to FC 🚀. once it's in FC it basically stays there, and it only drops back down if decompression keeps failing 💅
here's the state machine. the subsections after the figure explain the transitions and the decompression logic in detail 🦋
Success
+-->------>------>------>------>------>--+
| |
No Static | No Dynamic Success | Success
+-->--+ | +-->--+ +--->----->---+ +-->--+
| | | | | | | | |
| v | | v | v | v
+-----------------+ +---------------------+ +-------------------+
| No Context (NC) | | Static Context (SC) | | Full Context (FC) |
+-----------------+ +---------------------+ +-------------------+
^ | ^ |
| Static Context | | Context Damage Assumed |
| Damage Assumed | | |
+-----<------<------<-----+ +-----<------<------<-----+5.3.1.1. Reconstruction and Verification 🔍
when the decompressor gets an IR or IR-DYN packet, it MUST validate the integrity of the header using CRC-8 validation [RFC5795] 🔐. if that validation fails, the packet MUST NOT be delivered to upper layers 🙅♀️
when it gets an IR-CR packet, the decompressor MUST perform the actions specified in [RFC4164] 💫
for every other packet type (for example, CO packets), the decompressor MUST validate the outcome of the decompression attempt using CRC verification [RFC5795]. if verification fails, a decompressor implementation MAY try corrective or repair measures on the packet, and whatever result comes out of that attempt MUST be validated using CRC verification too. otherwise, the packet MUST NOT be delivered to upper layers 💅
when the CRC-8 validation or the CRC verification of the header succeeds, the decompressor SHOULD update its context with the information in the current header 🌈. then it hands the rebuilt packet to the system's network layer 🎁. if the check fails, the decompressor context MUST NOT be updated ❌
if the received packet is older than the current reference packet (for example, based on the master sequence number (MSN) in the compressed packet), the decompressor MAY hold off on updating the context with the info from that packet, even if its header passed verification ⏳
5.3.1.2. Detecting Context Damage 🕵️♀️
every header format carries a CRC and is context updating 💜. a packet whose CRC succeeds updates the reference values of all header fields, either explicitly (from information about a field carried in the compressed header) or implicitly (fields that get inferred from other fields) ✨
the decompressor may assume that some or all of the context is invalid after one or more failures to validate or verify a header using the CRC 😬. the decompressor can't know the exact reason for a CRC failure or which field caused it, so the validity of the context doesn't point to one specific context entry being good or bad 🤷♀️
what validity actually means is detecting that there's a problem with the context 🔎. the decompressor first assumes that the information most likely behind the failure is the part that changes with every packet, which is context damage to the dynamic part of the context 🌸. if failures keep happening and repairs don't work, it then assumes the whole context needs fixing, including the static part, which is static context damage 💥
Context Damage Detection
- The assumption of context damage means that the decompressor will not attempt decompression of a
COheader that carries a 3-bit CRC, and will only attempt decompression ofIR,IR-DYN, orIR-CRheaders orCOheaders protected by a CRC-7.
Static Context Damage Detection
- The assumption of static context damage means that the decompressor refrains from attempting decompression of any type of header other than the
IRheader.
how these assumptions get made (in other words, how context damage gets detected) is up to the implementation 🧠. it can be based on the residual error rate, where a low error rate makes the decompressor assume damage more often than it would on a high-rate link 📡
the decompressor puts these assumptions into practice by choosing which compressed header types it may attempt to decompress 🎯. so validity of the context really comes down to whether the decompressor attempts, or doesn't attempt, decompression of specific packet types 💖
5.3.1.3. No Context (NC) State 🌱
at the very start, while in the No Context (NC) state, the decompressor hasn't successfully decompressed any packet yet 🐣
Allowing decompression:
- In the NC state, only packets carrying enough information on the static fields (
IRandIR-CRpackets) can be decompressed. otherwise, the packet MUST NOT be decompressed and MUST NOT be delivered to upper layers 🚫
Feedback logic:
- In the NC state, the decompressor should send a
STATIC-NACKif a packet of a type other thanIRis received, or if decompression of anIRpacket has failed, subject to the feedback rate limitation described in Section 5.3.2 📨
once a packet has been validated and decompressed correctly, the decompressor MUST transit to the FC state 🥳
5.3.1.4. Static Context (SC) State 🌷
in the Static Context (SC) state, only the static part of the decompressor context is valid 🧊
if static context damage gets detected, the decompressor moves back down to the NC state from SC 📉
Allowing decompression:
- In the SC state, packets carrying enough information on the dynamic fields covered by an 8-bit CRC (for example,
IRandIR-DYN), orCOpackets covered by a 7-bit CRC, can be decompressed. otherwise, the packet MUST NOT be decompressed and MUST NOT be delivered to upper layers 🙈
Feedback logic:
- In the SC state, the decompressor should send a
STATIC-NACKif CRC validation of anIR/IR-DYN/IR-CRfails and static context damage is assumed. if any other packet type is received, the decompressor should send aNACK. both of the above cases are subject to the feedback rate limitation described in Section 5.3.2 💌
once a packet has been validated and decompressed correctly, the decompressor MUST transit to the FC state 🌟
5.3.1.5. Full Context (FC) State 👑
in the Full Context (FC) state, both the static and the dynamic parts of the decompressor context are valid 💯. if context damage gets detected, the decompressor moves back down to the SC state from FC 🫠
Allowing decompression:
- In the FC state, decompression can be attempted no matter what type of packet is received 🎉
Feedback logic:
- In the FC state, the decompressor should send a
NACKif the decompression of any packet type fails and context damage is assumed, subject to the feedback rate limitation described in Section 5.3.2 📬
5.3.2. Feedback Logic 💬
the decompressor MAY send positive feedback (ACKs) to set up the feedback channel for a particular flow 🛤️. either positive feedback (ACKs) or negative feedback (NACKs) establishes this channel ✨
once the feedback channel is set up, the decompressor is REQUIRED to keep sending NACKs or STATIC-NACKs for as long as the context is associated with the same profile, in this case profile 0x0006, following the logic defined for each state in Section 5.3.1 🔁
the decompressor MAY send ACKs after successfully decompressing any packet type 🥰. in particular, when a packet carrying a significant context update is decompressed correctly, the decompressor MAY send an ACK 🌞
the decompressor should limit how often it sends feedback, for both ACKs and STATIC-NACK/NACKs, and should avoid sending unnecessary duplicates of the same type of feedback message tied to the same event 🧘♀️
5.3.3. Context Replication 🪞
ROHC-TCP supports context replication, so the decompressor MUST implement the additional decompressor and feedback logic defined in [RFC4164] 🤝
6. Encodings in ROHC-TCP (Normative) 🧩
6.1. Control Fields in ROHC-TCP 🎛️
in ROHC-TCP, a bunch of control fields get used by the decompressor to figure out the format of the packets it receives from the compressor 📦
a control field is a field sent from the compressor to the decompressor that is NOT part of the uncompressed header 🙃. control field values can be set up in the context of both the compressor and the decompressor. once they've been established at the decompressor, the values of these fields should be kept until another packet updates them 💾
6.1.1. Master Sequence Number (MSN) 🔢
there's no field in the TCP header that can act as the master sequence number for TCP compression, as explained in [RFC4413], Section 5.6 😭
so ROHC-TCP introduces a control field called the Master Sequence Number (MSN) field 🙌. the MSN field gets created at the compressor, rather than borrowing one of the fields already in the uncompressed header 💅. the compressor increments the MSN by one for every packet it sends 📈
the MSN field does two jobs 💜:
- Differentiating between packets when sending feedback data.
- Inferring the value of incrementing fields such as the IP-ID.
the MSN field is in every packet the compressor sends 🎀. the MSN is LSB encoded within the CO packets, and the 16-bit MSN is sent in full in IR/IR-DYN packets 🧠. the decompressor always sends the MSN as part of the feedback information, and the compressor can later use the MSN to work out which packet the decompressor is acknowledging 🔍
when the MSN gets initialized, it SHOULD be initialized to a random value 🎲. the compressor should only initialize a new MSN for the initial IR or IR-CR packet sent for a CID that corresponds to a context not already associated with this profile. in other words, if the compressor reuses the same CID to compress many TCP flows one after another, the MSN doesn't get reinitialized and instead keeps incrementing monotonically 🔁✨
for context replication, the compressor does NOT use the MSN of the base context when sending the IR-CR packet, unless the replication process overwrites the base context (in other words, Base CID == CID) 🪄. instead, the compressor uses the value of the MSN if it already exists in the ROHC-TCP context being associated with the new flow (CID); otherwise, the MSN gets initialized to a new value 🌈
6.1.2. IP-ID Behavior ✨
okay so the IP-ID field in the IPv4 header can totally move in different patterns 🦋 Conceptually, the compressor watches how the IP-ID value changes and picks the encoding methods and packet formats that match the pattern best 💅
ROHC-TCP has different compression techniques for the IP-ID, so it can handle whatever behavior it sees: sequential in network byte order (NBO), sequential byte-swapped, random (RND), or constant to a value of zero. That's giving flexibility 🌈
The compressor keeps an eye on the IP-ID across a bunch of packets to figure out which of those options is the closest match. Then it can pick packet formats and encoding methods based on that behavior 🧠
If there's more than one level of IP headers (tunneling, bestie 🙈), ROHC-TCP can only give a sequential behavior (NBO or byte-swapped) to the IP-ID of the innermost IP header. Why? Because only that one can possibly have a close enough correlation with the MSN (see also Section 6.1.1) to be compressed as a sequentially changing field 🎀 So a compressor MUST NOT assign either the sequential (NBO) or the sequential byte-swapped behavior to tunneling headers. Not me making the rules, but we follow them 💀
The control field for the IP-ID behavior decides which set of packet formats gets used. These control fields also determine the contents of the irregular chain item (see Section 6.2) for each IP header 🍓
6.1.3. Explicit Congestion Notification (ECN) 🦋
When ECN [RFC3168] is used on a flow, the ECN bits could change quite often 😭 So ROHC-TCP keeps a control field in the context to show whether ECN is being used. This control field gets sent in the dynamic chain of the TCP header, and its value can be updated using specific compressed headers carrying a 7-bit CRC ✨
When this control field says ECN is in use, the items of all IP and TCP headers in the irregular chain include bits for ECN. To keep things octet-aligned, all of the TCP reserved bits are sent and, for outer IP headers, the entire Type of Service/Traffic Class (TOS/TC) field goes in the irregular chain. When there's only one IP header in the packet (no IP tunneling), this lets the compressor handle changes in the ECN bits by adding a single octet to the compressed header. Iconic efficiency 👑
The reason all the ECN bits of every IP header go into the compressed packet when the control field is set is that the profile needs to compress flows containing IP tunnels efficiently using the "full-functionality option" of Section 9.1 of [RFC3168]. For these flows, a change in the ECN bits of an inner IP header gets propagated to the outer IP headers. When the "limited-functionality" option is used, the compressor will therefore sometimes send one octet more than necessary per tunnel header, but this was considered a reasonable trade-off when designing this profile 🫶
6.2. Compressed Header Chains 🧚
Some packet types use one or more chains containing sub-header information. The function of a chain is to group fields based on similar characteristics, like static, dynamic, or irregular fields. Chaining is done by appending an item for each header to the chain in their order of appearance in the uncompressed packet, starting from the fields in the outermost header 🌸
Chains are defined for all headers compressed by ROHC-TCP, as listed below. The names of the encoding methods used to encode each of these protocol headers are listed too 💖
- TCP [RFC0793], encoding method:
"tcp" - IPv4 [RFC0791], encoding method:
"ipv4" - IPv6 [RFC2460], encoding method:
"ipv6" - AH [RFC4302], encoding method:
"ah" - GRE [RFC2784][RFC2890], encoding method:
"gre" - MINE [RFC2004], encoding method:
"mine" - IPv6 Destination Options header [RFC2460], encoding method:
"ip_dest_opt" - IPv6 Hop-by-Hop Options header [RFC2460], encoding method:
"ip_hop_opt" - IPv6 Routing header [RFC2460], encoding method:
"ip_rout_opt"
Static chain:
The static chain has one item for each header in the chain of protocol headers to be compressed, starting from the outermost IP header and ending with a TCP header. In the formal description of the packet formats, the static chain item for each header is a format whose name is suffixed by "_static". The static chain is only used in IR packets 🌷
Dynamic chain:
The dynamic chain has one item for each header in the chain of protocol headers to be compressed, starting from the outermost IP header and ending with a TCP header. The dynamic chain item for the TCP header also contains a compressed list of TCP options (see Section 6.3). In the formal description of the packet formats, the dynamic chain item for each header type is a format whose name is suffixed by "_dynamic". The dynamic chain is used in both IR and IR-DYN packets 💜
Replicate chain:
The replicate chain has one item for each header in the chain of protocol headers to be compressed, starting from the outermost IP header and ending with a TCP header. The replicate chain item for the TCP header also contains a compressed list of TCP options (see Section 6.3). In the formal description of the packet formats, the replicate chain item for each header type is a format whose name is suffixed by "_replicate". Header fields that are not present in the replicate chain are replicated from the base context. The replicate chain is only used in the IR-CR packet 🦋
Irregular chain:
The structure of the irregular chain is analogous to the structure of the static chain. For each compressed packet, the irregular chain gets appended at the specified location in the general format of the compressed packets, as defined in Section 7.3. This chain also includes the irregular chain items for TCP options as defined in Section 6.3.6, which go directly after the irregular chain item of the TCP header, in the same order as the options appear in the uncompressed packet. In the formal description of the packet formats, the irregular chain item for each header type is a format whose name is suffixed by "_irregular". The irregular chain is used only in CO packets 🍓
The format of the irregular chain for the innermost IP header differs from the format of outer IP headers, since this header is part of the compressed base header 🙈
6.3. Compressing TCP Options with List Compression 🎀
This section describes in detail how list compression is applied to the TCP options. In the definition of the packet formats for ROHC-TCP, the most frequent TCP options have one encoding method each, as listed in the table below 💅
+-----------------+------------------------+
| Option name | Encoding method name |
+-----------------+------------------------+
| NOP | tcp_opt_nop |
| EOL | tcp_opt_eol |
| MSS | tcp_opt_mss |
| WINDOW SCALE | tcp_opt_wscale |
| TIMESTAMP | tcp_opt_ts |
| SACK-PERMITTED | tcp_opt_sack_permitted |
| SACK | tcp_opt_sack |
| Generic options | tcp_opt_generic |
+-----------------+------------------------+Each of these encoding methods has an uncompressed format, a format suffixed by "_list_item", and a format suffixed by "_irregular". In some cases, a single encoding method may have multiple "_list_item" or "_irregular" formats, in which case the bindings inside these formats determine which format is used. This is described further in the following sections 🌈
6.3.1. List Compression ⭐
The TCP options in the uncompressed packet can be represented as an ordered list, whose order and presence are usually constant between packets. The generic structure of such a list is as follows 🧚
+--------+--------+--...--+--------+
list: | item 1 | item 2 | | item n |
+--------+--------+--...--+--------+To compress this list, ROHC-TCP uses a list compression scheme, which compresses each of these items individually and combines them into a compressed list ✨
The basic principles of list-based compression are the following 💖
- When a context is being initialized, a complete representation of the compressed list of options is transmitted. All options that have any content are present in the compressed list of items sent by the compressor.
Then, once the context has been initialized:
- When the structure AND the content of the list are unchanged, no information about the list is sent in compressed headers.
- When the structure of the list is constant, and when only the content defined within the irregular format for one or more options is changed, no information about the list needs to be sent in compressed base headers. The irregular content is sent as part of the irregular chain, as described in Section 6.3.6.
- When the structure of the list changes, a compressed list is sent in the compressed base header, including a representation of its structure and order. Content defined within the irregular format of an option can still be sent as part of the irregular chain (as described in Section 6.3.6), provided that the item content is not part of the compressed list 🫶
6.3.2. Table-Based Item Compression 🦋
Table-based item compression compresses individual items sent in compressed lists. The compressor assigns a unique identifier, "Index", to each item, "Item", of a list 🌸
Compressor Logic:
The compressor conceptually maintains an item table containing all items, indexed using "Index". The (Index, Item) pair is sent together in compressed lists until the compressor gains enough confidence that the decompressor has observed the mapping between items and their respective index. Confidence is obtained from the reception of an acknowledgment from the decompressor, or by sending (Index, Item) pairs using the optimistic approach. Once confidence is obtained, the index alone is sent in compressed lists to indicate the presence of the item corresponding to this index 💜
The compressor may reassign an existing index to a new item, by re-establishing the mapping using the procedure described above 🍓
Decompressor Logic:
The decompressor conceptually maintains an item table that contains all (Index, Item) pairs received. The item table is updated whenever an (Index, Item) pair is received and decompression is successfully verified using the CRC. The decompressor retrieves the item from the table whenever an index without an accompanying item is received 🎀
If an index without an accompanying item is received and the decompressor does not have any context for this index, the header MUST be discarded and a NACK SHOULD be sent. 🚨
6.3.3. Encoding of Compressed Lists ✨
Okay bestie, so every item in a compressed list gets its own little info bundle 💅 Each one has:
- an index into the table of items
- a presence bit saying whether a compressed version of the item is in the list
- an item (only if the presence bit is set)
Decompression of an item is gonna fail if the presence bit isn't set and the decompressor has no entry in the context for that item 😭
A compressed list of TCP options uses this encoding 🎀
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Reserved |PS | m |
+---+---+---+---+---+---+---+---+
| XI_1, ..., XI_m | m octets, or m * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and m is odd
+---+---+---+---+---+---+---+---+
| |
/ item_1, ..., item_n / variable
| |
+---+---+---+---+---+---+---+---+Reserved: this MUST be set to zero. If it isn't, the decompressor MUST discard the packet 🙈
PS tells you how big the XI fields are:
- PS = 0 means 4-bit XI fields
- PS = 1 means 8-bit XI fields
m is the number of XI items in the compressed list 🦋
XI_1, ..., XI_m are the m XI items. Each XI stands for one TCP option in the uncompressed packet, and they show up in the same order as the options do in the uncompressed packet 🧚
The format of an XI item looks like this:
+---+---+---+---+
PS = 0: | X | Index |
+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
PS = 1: | X | Reserved | Index |
+---+---+---+---+---+---+---+---+X says whether the item is actually in the list:
- X = 1 means the item for that Index is sent in the item_1, ..., item_n list
- X = 0 means the item for that Index is not sent, and is instead included in the irregular chain
Reserved (again, slay the consistency): this MUST be set to zero. Otherwise, the decompressor MUST discard the packet 🔥
Index is an index into the item table. See Section 6.3.4 🌸
When 4-bit XI items are used, the XI items get packed into octets like this:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| XI_k | XI_k + 1 |
+---+---+---+---+---+---+---+---+Padding: a 4-bit padding field shows up when PS = 0 and the number of XIs is odd. The Padding field MUST be set to zero. If it isn't, the decompressor MUST discard the packet 💀
Item 1, ..., item n: each item matches up with an XI that has X = 1 in XI 1, ..., XI m. The format of the entries in the item list is described in the table in Section 6.3. The compressed format(s) with the "_list_item" suffix in the encoding methods define the item inside the compressed item list ✨
6.3.4. Item Table Mappings
Okay so the item table for TCP options list compression is capped at 16 different items. That's because it's really unlikely that any packet flow has a ton of unique options 👑
The mapping between TCP option types and table indexes looks like this:
+-----------------+---------------+
| Option name | Table index |
+-----------------+---------------+
| NOP | 0 |
| EOL | 1 |
| MSS | 2 |
| WINDOW SCALE | 3 |
| TIMESTAMP | 4 |
| SACK-PERMITTED | 5 |
| SACK | 6 |
| Generic options | 7-15 |
+-----------------+---------------+Some TCP options show up way more than others, so a chunk of the item table is reserved for them, as you can see above. Both the compressor and the decompressor MUST use these item-to-index mappings when they (de)compress TCP options with list compression 🫶
It's expected that option types with a reserved index will only show up once in a list. But if an option type shows up twice in the same options list and the two have different content, the compressor should compress the second one by mapping it to a generic compressed option. If the two have the exact same content, the compressor can still use the same table index for both 🌈
The NOP option
NOP can appear more than once in a list. But its value is always the same, so no context info has to be sent for it. That means multiple NOP options can all map to the same index 🍓 Since NOP has no content when it's compressed as a "_list_item", it'll never be in the item list. For consistency though, the compressor should still set up an entry in the list by setting the presence bit, same as it does for the other option types.
List compression always keeps the original order of each item in the decompressed list. That's true whether or not the item is in the compressed "_list_item", and whether or not several items of the same type map to the same index (like NOP does) ✨
The EOL option
The compressed format for EOL can be bigger than one octet, and it's defined so that it includes the option padding. Why? EOL is supposed to end the parsing of the options, but it can also be followed by padding octets that are all zero 🙈
The Generic option
The Generic option can be used to compress any TCP option type that doesn't have a reserved index in the item table 🦋
6.3.5. Compressed Lists in Dynamic Chain
A compressed list for TCP options that's part of the dynamic chain (for example, in IR or IR-DYN packets) must have all its list items present. In other words, all X-bits in the XI list MUST be set 💜
6.3.6. Irregular Chain Items for TCP Options
The "_list_item" holds the option inside the compressed item list. The "_irregular" format is for the option fields that are expected to change with every packet. When an item of the specified type is in the current context, these irregular fields show up in every compressed packet, as part of the irregular chain 🌸 Lots of TCP option types aren't expected to change for the whole flow, so a lot of the "_irregular" formats end up empty.
The irregular chain for TCP options is structured the same way as the TCP options in the uncompressed packet. If a compressed list is present in the compressed packet, the irregular chain for TCP options must not contain irregular items for the list items that were sent inside the compressed list (the ones with the X-bit set in their XI). Items that are in the uncompressed list but not in the compressed list must have their irregular items present in the irregular chain 🧚
6.3.7. Replication of TCP Options
The entire table of TCP options items is always replicated when you use the IR-CR packet. In the IR-CR packet, the options list for the new flow is also sent as a compressed list 👑
6.4. Profile-Specific Encoding Methods
This section defines encoding methods that are specific to this profile. These methods get used in the formal definition of the packet formats in Section 8 🎀
6.4.1. inferred_ip_v4_header_checksum
This encoding method compresses the Header Checksum field of the IPv4 header. The checksum is defined in [RFC0791] like this:
Header Checksum is 16 bits. It's a checksum on the header only. Some header fields change (time to live, for example), so this gets recomputed and verified every time the internet header is processed 🫶
The checksum algorithm: the checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. When computing the checksum, the checksum field's value is treated as zero 💅
Okay, the vibe here: the checksum protects individual hops from processing a corrupted header. But when almost all of the IP header info is compressed away, and decompression is verified by a CRC computed over the original header for every compressed packet, this extra checksum is kinda pointless. So it can be recomputed on the decompressor side instead 🧠✨
The "inferred_ip_v4_header_checksum" encoding method squishes the IPv4 header checksum down to zero bits. With this method, the decompressor infers the value of this field using the computation above 🦋
This encoding method implicitly assumes that the compressor will not process a corrupted header. Otherwise, it can't guarantee that the checksum recomputed by the decompressor will be bitwise identical to its original value before compression 😭
6.4.2. inferred_mine_header_checksum
This encoding method compresses the minimal encapsulation header checksum. The checksum is defined in [RFC2004] like this:
The Header Checksum is the 16-bit one's complement of the one's complement sum of all 16-bit words in the minimal forwarding header. When computing the checksum, the checksum field's value is treated as zero. The IP header and IP payload (the stuff after the minimal forwarding header) are not included in this checksum computation 🍓
The "inferred_mine_header_checksum" encoding method compresses the minimal encapsulation header checksum down to zero bits. That means no bits get sent in compressed headers for this field. With this method, the decompressor infers the value of this field using the computation above 🌈
The motivations and assumptions for inferring this checksum are similar to the ones explained above in Section 6.4.1 🙈
6.4.3. inferred_ip_v4_length
This encoding method compresses the Total Length field of the IPv4 header. The Total Length field is defined in [RFC0791] like this:
Total Length is 16 bits. It's the length of the datagram, measured in octets, including the internet header and data. This field lets a datagram be up to 65,535 octets long 💖
The "inferred_ip_v4_length" encoding method compresses the IPv4 Total Length field down to zero bits. With this method, the decompressor infers the value of this field by counting, in octets, the length of the entire packet after decompression 🧚
6.4.4. inferred_ip_v6_length 🧚
okay so this one is about the Payload Length field in the IPv6 header 💅 RFC 2460 defines it like this:
Payload Length: 16-bit unsigned integer
Length of the IPv6 payload, i.e., the rest of the packet
following this IPv6 header, in octets. (Note that any
extension headers present are considered part of the payload,
i.e., included in the length count.)The inferred_ip_v6_length encoding method squishes the Payload Length field all the way down to zero bits 🤯 The decompressor just counts the octets of the whole packet after decompression and works out the value itself. Ngl that's so clever.
6.4.5. inferred_offset ✨
This encoding method compresses the data offset field of the TCP header 🌸
The inferred_offset encoding method is used on the Data Offset field of the TCP header. That field is defined in [RFC0793] like this:
Data Offset: 4 bits
The number of 32-bit words in the TCP header. This indicates
where the data begins. The TCP header (even one including
options) is an integral number of 32 bits long.The inferred_offset method shrinks the Data Offset field to zero bits. The decompressor figures it out by first decompressing the TCP options list, and then setting:
data offset = (options length / 4) + 5The equation above uses integer arithmetic, so no rounding drama 🍓
6.4.6. baseheader_extension_headers 🦋
In CO packets (see Section 7.3), the innermost IP header and the TCP header get squished together into a compressed base header 🫶 Sometimes the IP header has a bunch of extension headers sitting between it and the TCP header.
To stay formally correct, the base header still needs some way to represent those extension headers, and that's what this encoding method is for. It skips over all the extension headers and doesn't encode any of their fields. Any fields that changed in them get handled in the irregular chain instead.
6.4.7. baseheader_outer_headers 🌈
This one, along with baseheader_extension_headers above, is needed so the specification stays formally correct. It's used in CO packets (see Section 7.3) to describe tunneling IP headers and their extension headers, meaning every header that shows up before the innermost IP header 🧁
It skips over all the fields in these headers and doesn't do any encoding. Changed fields in outer headers are handled by the irregular chain.
6.4.8. Scaled Encoding of Fields 👑
Some header fields have a change pattern where they go up by a constant value, or by multiples of the same value 📈
Two examples are the TCP Sequence Number and the TCP Acknowledgment Number. For these, ROHC-TCP lets you downscale the field value before LSB encoding, so the compressor gets to send fewer bits. Iconic efficiency 💅
To use scaled encoding, the field has to fulfill this equation:
unscaled_value = scaling_factor * scaled_value + residueTo use scaled encoding, the compressor must be confident that the decompressor has established values for the "residue" and the "scaling_factor". That way it can decompress the field when only an LSB-encoded "scaled_value" shows up in the compressed packet 🔐
Once the compressor is confident that the scaling_factor and residue are established in the decompressor, it may send compressed packets using the scaled representation of the field. But there's a hard rule here: the compressor MUST NOT use scaled encoding with the value of the scaling_factor set to zero. ⚠️
If the compressor notices that the residue has changed, or it uses a different value for the scaling factor, it MUST NOT use scaled encoding until it is confident that the decompressor has received the new value(s) of these fields. No skipping this step, bestie 🙈
When the unscaled value of the field wraps around, the residue is likely to change even if the scaling_factor stays the same. In that case, the compressor must act the same way it would for any other change in the residue 🔄
The following subsections describe how scaled encoding is applied to specific fields in ROHC-TCP, and how the scaling_factor and residue values get established for each one 💖
6.4.8.1. Scaled TCP Sequence Number Encoding 🌸
For some TCP flows, like data transfers, the payload size stays constant for periods of time. For those flows, the TCP Sequence Number is bound to increase by multiples of the payload size between packets, which makes this field a great target for scaled encoding ✨ The payload size gets used as the scaling factor (the value for scaling_factor), so the scaling factor never needs to be sent explicitly. The decompressor infers it from the length of the payload in the compressed packet.
Establishing scaling_factor: The scaling factor is established by sending unscaled TCP Sequence Number bits, so the decompressor can infer the scaling_factor from the payload size.
Establishing residue: The residue is established the same way as the scaling_factor, which means by sending unscaled TCP Sequence Number bits.
For the full details on how the TCP Sequence Number uses scaled encoding, check the packet format definitions in Section 8.2 📖
6.4.8.2. Scaled Acknowledgment Number Encoding 🦋
Just like the TCP Sequence Number, the expected increase in the TCP Acknowledgment Number is often constant, so it's also a good fit for scaled encoding 🎀
For the TCP Acknowledgment Number, though, the scaling factor depends on the size of packets flowing in the opposite direction. That info might not be available to the compressor/decompressor pair, so ROHC-TCP explicitly transmits a scaling factor to compress the TCP Acknowledgment Number instead 🫣
Establishing scaling_factor: The scaling factor is established by explicitly transmitting its value (called ack_stride in the formal notation in Section 8.2) to the decompressor, using one of the packet types that can carry this information.
Establishing residue: The scaling residue is established by sending unscaled TCP Acknowledgment Number bits, so the decompressor can infer its value from the unscaled value and the scaling factor (ack_stride).
For the full details on how the TCP Acknowledgment Number uses scaled encoding, check the packet format definitions in Section 8.2 🧚
The compressor MAY use the scaled acknowledgment number encoding. What value it uses as the scaling factor is up to the compressor implementation 💜 If there's a co-located decompressor processing packets of the same TCP flow in the opposite direction, the compressor can use the scaling factor for the sequence number of that flow to pick a suitable scaling factor for the TCP Acknowledgment number on this flow. Clever, right? 😭
6.5. Encoding Methods with External Parameters 🎀
A bunch of encoding methods in Section 8.2 have one or more arguments whose values come from outside the scope of the ROHC-FN specification of the header formats. This section lists those encoding methods along with a definition of each of their parameters 🌈
ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn):is_innermost: This Boolean flag is set to true when processing the innermost IP header. Otherwise, it is set to false.ttl_irregular_chain_flag: This parameter must be set to the value that was used for the correspondingttl_irregular_chain_flagparameter of theco_baseheaderencoding method (as defined below) when extracting the irregular chain for a compressed header. Otherwise, it is set to zero and ignored for other types of chains.ip_inner_ecn: This parameter is bound by the encoding method, so it should be undefined when calling this encoding method. This value is then used to bind the corresponding parameter in thetcpencoding method, since its value is needed when processing the irregular chain for TCP. See the definition of theip_inner_ecnparameter for thetcpencoding method below ✨
ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn, ip_id_behavior_value):- See the definition of arguments for
ipv6above. ip_id_behavior_value: Set to a 2-bit integer value, using one of the constants whose name begins with the prefixIP_ID_BEHAVIOR_, as defined in Section 8.2 🔥
- See the definition of arguments for
tcp_opt_eol(nbits):nbits: This parameter is set to the length of the padding data located after the EOL option type octet, running to the end of the TCP options in the uncompressed header 🍓
tcp_opt_sack(ack_value):ack_value: Set to the value of the Acknowledgment Number field of the TCP header.
tcp(payload_size, ack_stride_value, ip_inner_ecn):payload_size: Set to the length (in octets) of the payload following the TCP header.ack_stride_value: This parameter is the scaling factor used when scaling the TCP Acknowledgment Number. Its value is set by the compressor implementation. See Section 6.4.8.2 for recommendations on how to set this value.ip_inner_ecn: This parameter binds with the value given to the correspondingip_inner_ecnparameter by theipv4or theipv6encoding method when processing the innermost IP header of this packet. See also the definition of theip_inner_ecnparameter for theipv6andipv4encoding methods above 🧁
co_baseheader(payload_size, ack_stride_value, ttl_irregular_chain_flag, ip_id_behavior_value):payload_size: Set to the length (in octets) of the payload following the TCP header.ack_stride_value: This parameter is the scaling factor used when scaling the TCP Acknowledgment Number. Its value is set by the compressor implementation. See Section 6.4.8.2 for recommendations on how to set this value.ttl_irregular_chain_flag: This parameter is set to one if the TTL/Hop Limit of an outer header has changed compared to its reference in the context. Otherwise, it is set to zero. The value used for this parameter is also used for thettl_irregular_chain_flagargument for theipv4andipv6encoding methods when processing the irregular chain, as defined above for theipv6andipv4encoding methods 💅ip_id_behavior_value: Set to a 2-bit integer value, using one of the constants whose name begins with the prefixIP_ID_BEHAVIOR_, as defined in Section 8.2 🌸
7. Packet Types (Normative) 🎀
okay so ROHC-TCP has three packet types 💅: the Initialization and Refresh (IR) type, the Context Replication (IR-CR) type, and the Compressed (CO) type. bestie, the IR-CR and CO types are the ones that get extra fancy 🦋
the packet formats are split up like this: two for IR, one for IR-CR, and then two sets of eight base header formats for CO, plus one extra format that both sets share. ✨ it's giving organized
and the profile identifier for ROHC-TCP is 0x0006 🌸
7.1. Initialization and Refresh (IR) Packets
ROHC-TCP borrows the basic structure of the ROHC IR and IR-DYN packets from [RFC5795] (Sections 5.2.2.1 and 5.2.2.2, respectively). so we're not reinventing the wheel here, we're just dressing it up 💖
Packet type: IR 🧚
This packet type communicates the static part and the dynamic part of the context.
For the ROHC-TCP IR packet, the x bit MUST be set to one. 🫶 This is the format, which lines up with the "Header" and "Payload" fields from Section 5.2.1 of [RFC5795]:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 1 | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x06 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Static chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -- CRC: 8-bit CRC, computed according to Section 5.3.1.1 of [RFC5795]. The CRC covers the entire IR header, thus excluding payload, padding, and feedback, if any. 🔥
- Static chain: See Section 6.2.
- Dynamic chain: See Section 6.2.
- Payload: The payload of the corresponding original packet, if any. The payload consists of all data after the last octet of the TCP header to the end of the uncompressed packet. The presence of a payload is inferred from the packet length. 🍓
Packet type: IR-DYN 💜
This packet type communicates the dynamic part of the context. ✨
The ROHC-TCP IR-DYN packet has the following format, which lines up with the "Header" and "Payload" fields from Section 5.2.1 of [RFC5795]:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x06 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -- CRC: 8-bit CRC, computed according to Section 5.3.1.1 of [RFC5795]. The CRC covers the entire IR-DYN header, thus excluding payload, padding, and feedback, if any. 🌈
- Dynamic chain: See Section 6.2.
- Payload: The payload of the corresponding original packet, if any. The payload consists of all data after the last octet of the TCP header to end of the uncompressed packet. The presence of a payload is inferred from the packet length. 🦋
7.2. Context Replication (IR-CR) Packets
context replication needs its own IR packet format that uniquely identifies the IR-CR packet for the ROHC-TCP profile. this section defines the profile-specific part of the IR-CR packet from [RFC4164]. 👑
Packet type: IR-CR 🧚
This packet type communicates a reference to a base context, along with the static and dynamic parts of the replicated context that differ from the base context. 🌸
The ROHC-TCP IR-CR packet follows the general format of the ROHC IR-CR packet, as defined in [RFC4164], Section 3.5.2. ✨ Since the IR packet type is extensible (see [RFC5795]), the ROHC-TCP profile supports context replication through the profile-specific part of the IR packet. This works by using the bit (x) that's left in the IR header for "Profile specific information". For ROHC-TCP, that bit is a flag saying whether the packet is an IR packet or an IR-CR packet. For the ROHC-TCP IR-CR packet, the x bit MUST be set to zero. 💅
The ROHC-TCP IR-CR has the following format, which lines up with the "Header" and "Payload" fields from Section 5.2.1 of [RFC5795]:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 0 | IR-CR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x06 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| B | CRC7 | 1 octet
+---+---+---+---+---+---+---+---+
: Reserved | Base CID : 1 octet, for small CID, if B=1
+---+---+---+---+---+---+---+---+
: :
/ Base CID / 1-2 octets, for large CIDs,
: : if B=1
+---+---+---+---+---+---+---+---+
| |
/ Replicate chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -- B: B = 1 indicates that the Base CID field is present. 🎀
- CRC: This CRC covers the entire IR-CR header, thus excluding payload, padding, and feedback, if any. This 8-bit CRC is calculated according to Section 5.3.1.1 of [RFC5795]. 🔥
- CRC7: The CRC over the original, uncompressed, header. Calculated according to Section 3.5.1.1 of [RFC4164]. 💖
- Reserved: MUST be set to zero; otherwise, the decompressor MUST discard the packet. 🙈
- Base CID: CID of base context. Encoded according to [RFC4164], Section 3.5.3. 🧚
- Replicate chain: See Section 6.2. 🍓
- Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length. ✨
7.3. Compressed (CO) Packets
the ROHC-TCP CO packets communicate irregularities in the packet header. every CO packet carries a CRC and can update the context. 😭 (that CRC is doing a lot of work, honestly)
the general format for a compressed TCP header looks like this, lining up with the "Header" and "Payload" fields from Section 5.2.1 of [RFC5795]:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and CID 1-15
+---+---+---+---+---+---+---+---+
| First octet of base header | (with type indication)
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1-2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ Remainder of base header / variable number of octets
+---+---+---+---+---+---+---+---+
: Irregular chain :
/ (including irregular chain / variable
: items for TCP options) :
--- --- --- --- --- --- --- ---
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -- Base header: The complete set of base headers is defined in Section 8. 💜
- Irregular chain: See Sections 6.2 and 6.3.6. 🌸
- Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length. 🦋
8. Header Formats (Normative) 👑
this section describes the set of compressed TCP/IP packet formats. the normative description of the packet formats uses the formal notation for ROHC profiles defined in [RFC4997]. that formal description has everything needed to compress and decompress a header relative to the context, so it's the main event ✨
in particular, the notation gives a list of all the fields that show up in the uncompressed and compressed TCP/IP headers. it also defines how to map each uncompressed packet to its compressed equivalent, and back again. literally the whole glow-up pipeline 💅🌈
8.1. Design Rationale for Compressed Base Headers ✨
okay so bestie, the compressed header formats come in two separate sets 🎀. One set is for packets where the innermost IP header has a sequential IP-ID (either network byte order or byte swapped), and the other is for packets without a sequential IP-ID (random, zero, or no IP-ID at all) 💅.
These two sets are called the "sequential" and the "random" set of header formats, respectively 🦋.
There's also one compressed format that's shared by both sets, so it works no matter what kind of IP-ID behavior you've got 🌈. It can send the rarely changing fields, and it can also send the frequently changing fields in variable lengths. It can even change control fields like IP-ID behavior and ECN behavior, which is lowkey iconic 👑.
All compressed base headers carry a 3-bit CRC, unless they update control fields like "ip_id_behavior" or "ecn_used" that change how the headers after them get interpreted. Those headers carry a 7-bit CRC instead 🔥.
When we talk about LSB-encoded fields below, "p" is the "offset_param" and "k" is the "num_lsbs_param" from [RFC4997] 🧚.
The encoding methods in the compressed base headers are built on these design criteria 💖:
- MSN: Since the MSN is a number the compressor generates, it only needs to be big enough for robust operation and to handle a small amount of reordering [RFC4163]. So each compressed base header has an MSN field that's LSB-encoded with k=4 and p=4, which handles a reordering depth of up to 4 packets 🍓. More guidance on robustness when reordering is possible is in [RFC4224].
- TCP Sequence Number: ROHC-TCP is built for bulk data transfers, where the sequence number is expected to go up by about 1460 octets (which fits in 11 bits) 🚀. To handle retransmissions (a negative delta to the sequence number), the LSB interpretation interval has to cover negative offsets about as large as the positive ones, which means one more bit is needed 🙈. For ROHC-TCP to be robust to losses, two more bits get added to the LSB encoding of the sequence number. So the base headers should contain at least 14 bits of LSB-encoded sequence number when it's present 😭. Following that logic, the LSB offset value is set to be as large as the positive offset, so p = 2^(k-1)-1.
- TCP Acknowledgment Number: This is similar to the TCP Sequence Number, but often only every other data packet gets acknowledged. That means the expected delta is twice as large as for sequence numbers 🌸. So at least 15 bits of acknowledgment number should be used in compressed base headers. The acknowledgment number is expected to keep constantly increasing, and the only exception is packet reordering (either on the ROHC channel [RFC3759] or before the compression point). So the negative offset for LSB encoding is set to 1/4 of the total interval, meaning p = 2^(k-2)-1 💜.
- TCP Window: The TCP Window field is expected to go up in increments about the same size as the TCP Sequence Number, so the design criterion is to send at least 14 bits when it's used ✨.
- IP-ID: For the "sequential" set of packet formats, all the compressed base headers have LSB-encoded IP-ID offset bits. The offset is the difference between the value of the MSN field and the value of the IP-ID field 🦋. At least 3 bits of IP-ID should always be present, but using 4 to 7 bits is preferable. When k=3 then p=1, and if k>3 then p=3, since the offset is expected to increase most of the time 🎀.
Each set of header formats has eight different compressed base headers 🫶. There are that many because the TCP Sequence Number, TCP Acknowledgment Number, and TCP Window change frequently in a non-linear pattern, and honestly that's the whole reason it's giving so many formats 💅.
The design of these header formats comes from the field behavior analysis in [RFC4413] 📚.
All of the compressed base headers send LSB-encoded MSN bits, the TCP Push flag, and a CRC. On top of that, every base header in the sequential packet format set also contains LSB-encoded IP-ID bits 🌈.
The following header formats exist in both the sequential and random packet format sets:
- Format 1: This one carries changes to the TCP Sequence Number and is expected to be used on the downstream of a data transfer 🚀.
- Format 2: This one carries the TCP Sequence Number in scaled form. It's expected to be useful on the downstream of a data transfer where the payload size is constant for multiple packets 🍓.
- Format 3: This one carries changes in the TCP Acknowledgment Number and is expected to be useful for the acknowledgment direction of a data transfer 💜.
- Format 4: This one is similar to format 3, but carries a scaled TCP Acknowledgment Number 🌸.
- Format 5: This one carries both the TCP Sequence Number and the TCP Acknowledgment Number, and is expected to be useful for flows that send data in both directions 🔥.
- Format 6: This one is similar to format 5, but carries the TCP Sequence Number in scaled form, when the payload size is static for certain intervals in a data flow 🧚.
- Format 7: This one carries changes to both the TCP Acknowledgment Number and the TCP Window, and is expected to be useful for the acknowledgment flows of data connections 🦋.
- Format 8: This one conveys changes to some of the more seldom changing fields in the TCP flow, like ECN behavior, RST/SYN/FIN flags, the TTL/Hop Limit, and the TCP options list 🙈. It carries a 7-bit CRC, since it can change the structure of the contents of the irregular chain for subsequent packets. Note that this can be seen as a reduced form of the common packet format 👑.
- Common header format: This can be used for all kinds of IP-ID behavior, and it's useful when some of the more rarely changing fields in the IP or TCP header change ✨. Since it can update control fields that decide how the decompressor interprets packets, it carries a 7-bit CRC to reduce the chance of context corruption 🛡️. It can basically convey changes to any of the dynamic fields in the IP and TCP headers, and it uses a big set of flags to show which fields are present in the header format 💖.
8.2. Formal Definition of Header Formats
Now for the formal bit 🤓. The grammar below is the actual definition, so be careful with it bestie 💅.
// NOTE: The irregular, static, and dynamic chains (see Section 6.2)
// are defined across multiple encoding methods and are embodied
// in the correspondingly named formats within those encoding
// methods. In particular, note that the static and dynamic
// chains ordinarily go together. The uncompressed fields are
// defined across these two formats combined, rather than in one
// or the other of them. The irregular chain items are likewise
// combined with a baseheader format.
////////////////////////////////////////////
// Constants
////////////////////////////////////////////
IP_ID_BEHAVIOR_SEQUENTIAL = 0;
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1;
IP_ID_BEHAVIOR_RANDOM = 2;
IP_ID_BEHAVIOR_ZERO = 3;
////////////////////////////////////////////
// Global control fields
////////////////////////////////////////////
CONTROL {
ecn_used [ 1 ];
msn [ 16 ];
// ip_id fields are for innermost IP header only
ip_id_offset [ 16 ];
ip_id_behavior_innermost [ 2 ];
// ACK-related
ack_stride [ 32 ];
ack_number_scaled [ 32 ];
ack_number_residue [ 32 ];
seq_number_scaled [ 32 ];
seq_number_residue [ 32 ];
}
///////////////////////////////////////////////
// Encoding methods not specified in FN syntax
///////////////////////////////////////////////
list_tcp_options "defined in Section 6.3.3";
inferred_ip_v4_header_checksum "defined in Section 6.4.1";
inferred_mine_header_checksum "defined in Section 6.4.2";
inferred_ip_v4_length "defined in Section 6.4.3";
inferred_ip_v6_length "defined in Section 6.4.4";
inferred_offset "defined in Section 6.4.5";
baseheader_extension_headers "defined in Section 6.4.6";
baseheader_outer_headers "defined in Section 6.4.7";
////////////////////////////////////////////
// General encoding methods
////////////////////////////////////////////
static_or_irreg(flag, width)
{
UNCOMPRESSED {
field [ width ];
}
COMPRESSED irreg_enc {
field =:= irregular(width) [ width ];
ENFORCE(flag == 1);
}
COMPRESSED static_enc {
field =:= static [ 0 ];
ENFORCE(flag == 0);
}
}
zero_or_irreg(flag, width)
{
UNCOMPRESSED {
field [ width ];
}
COMPRESSED non_zero {
field =:= irregular(width) [ width ];
ENFORCE(flag == 0);
}
COMPRESSED zero {
field =:= uncompressed_value(width, 0) [ 0 ];
ENFORCE(flag == 1);
}
}
variable_length_32_enc(flag)
{
UNCOMPRESSED {
field [ 32 ];
}
COMPRESSED not_present {
field =:= static [ 0 ];
ENFORCE(flag == 0);
}
COMPRESSED lsb_8_bit {
field =:= lsb(8, 63) [ 8 ];
ENFORCE(flag == 1);
}
COMPRESSED lsb_16_bit {
field =:= lsb(16, 16383) [ 16 ];
ENFORCE(flag == 2);
}
COMPRESSED irreg_32_bit {
field =:= irregular(32) [ 32 ];
ENFORCE(flag == 3);
}
}
optional32(flag)
{
UNCOMPRESSED {
item [ 0, 32 ];
}
COMPRESSED present {
item =:= irregular(32) [ 32 ];
ENFORCE(flag == 1);
}
COMPRESSED not_present {
item =:= compressed_value(0, 0) [ 0 ];
ENFORCE(flag == 0);
}
}
lsb_7_or_31
{
UNCOMPRESSED {
item [ 32 ];
}
COMPRESSED lsb_7 {
discriminator =:= '0' [ 1 ];
item =:= lsb(7, 8) [ 7 ];
}
COMPRESSED lsb_31 {
discriminator =:= '1' [ 1 ];
item =:= lsb(31, 256) [ 31 ];
}
}
opt_lsb_7_or_31(flag)
{
UNCOMPRESSED {
item [ 0, 32 ];
}
COMPRESSED present {
item =:= lsb_7_or_31 [ 8, 32 ];
ENFORCE(flag == 1);
}
COMPRESSED not_present {
item =:= compressed_value(0, 0) [ 0 ];
ENFORCE(flag == 0);
}
}
crc3(data_value, data_length)
{
UNCOMPRESSED {
}
COMPRESSED {
crc_value =:=
crc(3, 0x06, 0x07, data_value, data_length) [ 3 ];
}
}
crc7(data_value, data_length)
{
UNCOMPRESSED {
}
COMPRESSED {
crc_value =:=
crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ];
}
}
one_bit_choice
{
UNCOMPRESSED {
field [ 1 ];
}
COMPRESSED zero {
field [ 1 ];
ENFORCE(field.UVALUE == 0);
}
COMPRESSED nonzero {
field [ 1 ];
ENFORCE(field.UVALUE == 1);
}
}
// Encoding method for updating a scaled field and its associated
// control fields. Should be used both when the value is scaled
// or unscaled in a compressed format.
// Does not have an uncompressed side.
field_scaling(stride_value, scaled_value, unscaled_value, residue_value)okay so the field_scaling bit wraps up right here 💅✨
{
UNCOMPRESSED {
// Nothing
}
COMPRESSED no_scaling {
ENFORCE(stride_value == 0);
ENFORCE(residue_value == unscaled_value);
ENFORCE(scaled_value == 0);
}
COMPRESSED scaling_used {
ENFORCE(stride_value != 0);
ENFORCE(residue_value == (unscaled_value % stride_value));
ENFORCE(unscaled_value ==
scaled_value * stride_value + residue_value);
}
}next up: the IPv6 destination options header 🎀 it's giving very structured energy
////////////////////////////////////////////
// IPv6 Destination options header
////////////////////////////////////////////
ip_dest_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED dest_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
COMPRESSED dest_opt_dynamic {
value =:=
irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED dest_opt_0_replicate {
discriminator =:= '00000000' [ 8 ];
}
COMPRESSED dest_opt_1_replicate {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED dest_opt_irregular {
}
}and now the Hop-by-Hop options header, which is literally the same vibe but make it its own thing 🦋
////////////////////////////////////////////
// IPv6 Hop-by-Hop options header
////////////////////////////////////////////
ip_hop_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED hop_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
COMPRESSED hop_opt_dynamic {
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED hop_opt_0_replicate {
discriminator =:= '00000000' [ 8 ];
}
COMPRESSED hop_opt_1_replicate {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED hop_opt_irregular {
}
}routing header time 🌈 there's a little copy-paste moment in here so keep your eyes open, bestie 👀
////////////////////////////////////////////
// IPv6 Routing header
////////////////////////////////////////////
ip_rout_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED rout_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED rout_opt_dynamic {
}
COMPRESSED rout_opt_0_replicate {
discriminator =:= '00000000' [ 8 ];
}
COMPRESSED rout_opt_0_replicate {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED rout_opt_irregular {
}
}GRE time 🍓 this one has a whole lot going on, so grab a snack
////////////////////////////////////////////
// GRE Header
////////////////////////////////////////////
optional_checksum(flag_value)
{
UNCOMPRESSED {
value [ 0, 16 ];
reserved1 [ 0, 16 ];
}
COMPRESSED cs_present {
value =:= irregular(16) [ 16 ];
reserved1 =:= uncompressed_value(16, 0) [ 0 ];
ENFORCE(flag_value == 1);
}
COMPRESSED not_present {
value =:= compressed_value(0, 0) [ 0 ];
reserved1 =:= compressed_value(0, 0) [ 0 ];
ENFORCE(flag_value == 0);
}
}
gre_proto
{
UNCOMPRESSED {
protocol [ 16 ];
}
COMPRESSED ether_v4 {
discriminator =:= compressed_value(1, 0) [ 1 ];
protocol =:= uncompressed_value(16, 0x0800) [ 0 ];
}
COMPRESSED ether_v6 {
discriminator =:= compressed_value(1, 1) [ 1 ];
protocol =:= uncompressed_value(16, 0x86DD) [ 0 ];
}
}
gre
{
UNCOMPRESSED {
c_flag [ 1 ];
r_flag =:= uncompressed_value(1, 0) [ 1 ];
k_flag [ 1 ];
s_flag [ 1 ];
reserved0 =:= uncompressed_value(9, 0) [ 9 ];
version =:= uncompressed_value(3, 0) [ 3 ];
protocol [ 16 ];
checksum_and_res [ 0, 32 ];
key [ 0, 32 ];
sequence_number [ 0, 32 ];
}
DEFAULT {
c_flag =:= static;
k_flag =:= static;
s_flag =:= static;
protocol =:= static;
key =:= static;
sequence_number =:= static;
}
COMPRESSED gre_static {
ENFORCE((c_flag.UVALUE == 1 && checksum_and_res.ULENGTH == 32)
|| checksum_and_res.ULENGTH == 0);
ENFORCE((s_flag.UVALUE == 1 && sequence_number.ULENGTH == 32)
|| sequence_number.ULENGTH == 0);
protocol =:= gre_proto [ 1 ];
c_flag =:= irregular(1) [ 1 ];
k_flag =:= irregular(1) [ 1 ];
s_flag =:= irregular(1) [ 1 ];
padding =:= compressed_value(4, 0) [ 4 ];
key =:= optional32(k_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_dynamic {
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_0_replicate {
discriminator =:= '00000000' [ 8 ];
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:=
optional32(s_flag.UVALUE) [ 0, 8, 32 ];
}
COMPRESSED gre_1_replicate {
discriminator =:= '10000' [ 5 ];
c_flag =:= irregular(1) [ 1 ];
k_flag =:= irregular(1) [ 1 ];
s_flag =:= irregular(1) [ 1 ];
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
key =:= optional32(k_flag.UVALUE) [ 0, 32 ];
sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_irregular {
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:=
opt_lsb_7_or_31(s_flag.UVALUE) [ 0, 8, 32 ];
}
}MINE header next 💜 the reserved bits get a little shoutout in the comments, so cute
/////////////////////////////////////////////
// MINE header
/////////////////////////////////////////////
mine
{
UNCOMPRESSED {
next_header [ 8 ];
s_bit [ 1 ];
res_bits [ 7 ];
checksum [ 16 ];
orig_dest [ 32 ];
orig_src [ 0, 32 ];
}
DEFAULT {
next_header =:= static;
s_bit =:= static;
res_bits =:= static;
checksum =:= inferred_mine_header_checksum;
orig_dest =:= static;
orig_src =:= static;
}
COMPRESSED mine_static {
next_header =:= irregular(8) [ 8 ];
s_bit =:= irregular(1) [ 1 ];
// Reserved bits are included to achieve byte-alignment
res_bits =:= irregular(7) [ 7 ];
orig_dest =:= irregular(32) [ 32 ];
orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ];
}
COMPRESSED mine_dynamic {
}
COMPRESSED mine_0_replicate {
discriminator =:= '00000000' [ 8 ];
}
COMPRESSED mine_1_replicate {
discriminator =:= '10000000' [ 8 ];
s_bit =:= irregular(1) [ 1 ];
res_bits =:= irregular(7) [ 7 ];
orig_dest =:= irregular(32) [ 32 ];
orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ];
}
COMPRESSED mine_irregular {
}
}Authentication Header time 🔐 this is where the ICV lengths get a bit mathy, bestie
/////////////////////////////////////////////
// Authentication Header (AH)
/////////////////////////////////////////////
ah
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
res_bits [ 16 ];
spi [ 32 ];
sequence_number [ 32 ];
icv [ length.UVALUE*32-32 ];
}
DEFAULT {
next_header =:= static;
length =:= static;
res_bits =:= static;
spi =:= static;
sequence_number =:= static;
}
COMPRESSED ah_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
spi =:= irregular(32) [ 32 ];
}
COMPRESSED ah_dynamic {
res_bits =:= irregular(16) [ 16 ];
sequence_number =:= irregular(32) [ 32 ];
icv =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
COMPRESSED ah_0_replicate {
discriminator =:= '00000000' [ 8 ];
sequence_number =:= irregular(32) [ 32 ];
icv =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
COMPRESSED ah_1_replicate {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
res_bits =:= irregular(16) [ 16 ];
spi =:= irregular(32) [ 32 ];
sequence_number =:= irregular(32) [ 32 ];
icv =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
COMPRESSED ah_irregular {
sequence_number =:= lsb_7_or_31 [ 8, 32 ];
icv =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
}last stop for this part: the IPv6 header and its flow label 🌸✨
/////////////////////////////////////////////
// IPv6 Header
/////////////////////////////////////////////
fl_enc
{
UNCOMPRESSED {
flow_label [ 20 ];
}
COMPRESSED fl_zero {
discriminator =:= '0' [ 1 ];
flow_label =:= uncompressed_value(20, 0) [ 0 ];
reserved =:= '0000' [ 4 ];
}
COMPRESSED fl_non_zero {
discriminator =:= '1' [ 1 ];
flow_label =:= irregular(20) [ 20 ];
}
}
// The is_innermost flag is true if this is the innermost IP header
// If extracting the irregular chain for a compressed packet:
// - ttl_irregular_chain_flag must have the same value as it had when
// processing co_baseheader.
// - ip_inner_ecn is bound in this encoding method and the value that
// it gets bound to should be passed to the tcp encoding method
// For other formats than the irregular chain, these two are ignored
ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn){ UNCOMPRESSED { version =:= uncompressed_value(4, 6) [ 4 ]; dscp [ 6 ]; ip_ecn_flags [ 2 ]; flow_label [ 20 ]; payload_length [ 16 ]; next_header [ 8 ]; ttl_hopl [ 8 ]; src_addr [ 128 ]; dst_addr [ 128 ]; }
DEFAULT { dscp =:= static; ip_ecn_flags =:= static; flow_label =:= static; payload_length =:= inferred_ip_v6_length; next_header =:= static; ttl_hopl =:= static; src_addr =:= static; dst_addr =:= static; }
COMPRESSED ipv6_static { version_flag =:= '1' [ 1 ]; reserved =:= '00' [ 2 ]; flow_label =:= fl_enc [ 5, 21 ]; next_header =:= irregular(8) [ 8 ]; src_addr =:= irregular(128) [ 128 ]; dst_addr =:= irregular(128) [ 128 ]; }
COMPRESSED ipv6_dynamic { dscp =:= irregular(6) [ 6 ]; ip_ecn_flags =:= irregular(2) [ 2 ]; ttl_hopl =:= irregular(8) [ 8 ]; }
COMPRESSED ipv6_replicate { dscp =:= irregular(6) [ 6 ]; ip_ecn_flags =:= irregular(2) [ 2 ]; reserved =:= '000' [ 3 ]; flow_label =:= fl_enc [ 5, 21 ]; }
COMPRESSED ipv6_outer_without_ttl_irregular { dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; ENFORCE(ttl_irregular_chain_flag == 0); ENFORCE(is_innermost == false); }
COMPRESSED ipv6_outer_with_ttl_irregular {
dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; ttl_hopl =:= irregular(8) [ 8 ]; ENFORCE(ttl_irregular_chain_flag == 1); ENFORCE(is_innermost == false); }
COMPRESSED ipv6_innermost_irregular { ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE); ENFORCE(is_innermost == true); } }
///////////////////////////////////////////// // IPv4 Header /////////////////////////////////////////////
ip_id_enc_dyn(behavior) { UNCOMPRESSED { ip_id [ 16 ]; }
COMPRESSED ip_id_seq { ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); ip_id =:= irregular(16) [ 16 ]; }
COMPRESSED ip_id_random { ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM); ip_id =:= irregular(16) [ 16 ]; }
COMPRESSED ip_id_zero { ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); ip_id =:= uncompressed_value(16, 0) [ 0 ]; } }
ip_id_enc_irreg(behavior) { UNCOMPRESSED { ip_id [ 16 ]; }
COMPRESSED ip_id_seq {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); }
COMPRESSED ip_id_seq_swapped { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); }
COMPRESSED ip_id_rand { ip_id =:= irregular(16) [ 16 ]; ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM); }
COMPRESSED ip_id_zero { ip_id =:= uncompressed_value(16, 0) [ 0 ]; ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); } }
// The is_innermost flag is true if this is the innermost IP header // If extracting the irregular chain for a compressed packet: // - ttl_irregular_chain_flag must have the same value as it had when // processing co_baseheader. // - ip_inner_ecn is bound in this encoding method and the value that // it gets bound to should be passed to the tcp encoding method // For other formats than the irregular chain, these two are ignored ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn, ip_id_behavior_value) { UNCOMPRESSED { version =:= uncompressed_value(4, 4) [ 4 ]; hdr_length =:= uncompressed_value(4, 5) [ 4 ]; dscp [ 6 ]; ip_ecn_flags [ 2 ]; length =:= inferred_ip_v4_length [ 16 ]; ip_id [ 16 ]; rf =:= uncompressed_value(1, 0) [ 1 ]; df [ 1 ]; mf =:= uncompressed_value(1, 0) [ 1 ]; frag_offset =:= uncompressed_value(13, 0) [ 13 ]; ttl_hopl [ 8 ]; protocol [ 8 ]; checksum =:= inferred_ip_v4_header_checksum [ 16 ]; src_addr [ 32 ]; dst_addr [ 32 ]; }
CONTROL { ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); ENFORCE(innermost_ip.UVALUE == is_innermost); ip_id_behavior_outer [ 2 ]; innermost_ip [ 1 ]; }
DEFAULT { dscp =:= static; ip_ecn_flags =:= static; df =:= static; ttl_hopl =:= static; protocol =:= static; src_addr =:= static; dst_addr =:= static; ip_id_behavior_outer =:= static; }
COMPRESSED ipv4_static { version_flag =:= '0' [ 1 ]; reserved =:= '0000000' [ 7 ]; protocol =:= irregular(8) [ 8 ]; src_addr =:= irregular(32) [ 32 ]; dst_addr =:= irregular(32) [ 32 ]; }
COMPRESSED ipv4_innermost_dynamic { ENFORCE(is_innermost == 1); ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); reserved =:= '00000' [ 5 ]; df =:= irregular(1) [ 1 ]; ip_id_behavior_innermost =:= irregular(2) [ 2 ]; dscp =:= irregular(6) [ 6 ]; ip_ecn_flags =:= irregular(2) [ 2 ]; ttl_hopl =:= irregular(8) [ 8 ]; ip_id =:= ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; }
COMPRESSED ipv4_outer_dynamic { ENFORCE(is_innermost == 0); ENFORCE(ip_id_behavior_outer.UVALUE == ip_id_behavior_value); reserved =:= '00000' [ 5 ]; df =:= irregular(1) [ 1 ]; ip_id_behavior_outer =:= irregular(2) [ 2 ]; dscp =:= irregular(6) [ 6 ]; ip_ecn_flags =:= irregular(2) [ 2 ]; ttl_hopl =:= irregular(8) [ 8 ]; ip_id =:= ip_id_enc_dyn(ip_id_behavior_outer.UVALUE) [ 0, 16 ];
}
COMPRESSED ipv4_innermost_replicate { ENFORCE(is_innermost == 1); ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); reserved =:= '0000' [ 4 ]; ip_id_behavior_innermost =:= irregular(2) [ 2 ]; ttl_flag =:= irregular(1) [ 1 ]; df =:= irregular(1) [ 1 ]; dscp =:= irregular(6) [ 6 ]; ip_ecn_flags =:= irregular(2) [ 2 ]; ip_id =:= ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; ttl_hopl =:= static_or_irreg(ttl_flag.UVALUE, 8) [ 0, 8 ]; }
COMPRESSED ipv4_outer_replicate { ENFORCE(is_innermost == 0); ENFORCE(ip_id_behavior_outer.UVALUE == ip_id_behavior_value); reserved =:= '0000' [ 4 ]; ip_id_behavior_outer =:= irregular(2) [ 2 ] ttl_flag =:= irregular(1) [ 1 ]; df =:= irregular(1) [ 1 ]; dscp =:= irregular(6) [ 6 ]; ip_ecn_flags =:= irregular(2) [ 2 ]; ip_id =:= ip_id_enc_dyn(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; ttl_hopl =:= static_or_irreg(ttl_flag.UVALUE, 8) [ 0, 8 ]; }
COMPRESSED ipv4_outer_without_ttl_irregular { ENFORCE(is_innermost == 0); ip_id =:= ip_id_enc_irreg(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; ENFORCE(ttl_irregular_chain_flag == 0); }
COMPRESSED ipv4_outer_with_ttl_irregular { ENFORCE(is_innermost == 0); ip_id =:= ip_id_enc_irreg(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ]; ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ]; ttl_hopl =:= irregular(8) [ 8 ]; ENFORCE(ttl_irregular_chain_flag == 1); }
COMPRESSED ipv4_innermost_irregular { ENFORCE(is_innermost == 1); ip_id =:= ip_id_enc_irreg(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE); } }
///////////////////////////////////////////// // TCP Options /////////////////////////////////////////////
// nbits is bound to the remaining length (in bits) of TCP // options, including the EOL type byte. tcp_opt_eol(nbits) { UNCOMPRESSED { type =:= uncompressed_value(8, 0) [ 8 ]; padding =:= uncompressed_value(nbits-8, 0) [ nbits-8 ]; }
CONTROL { pad_len [ 8 ]; }
COMPRESSED eol_list_item { pad_len =:= compressed_value(8, nbits-8) [ 8 ]; }
COMPRESSED eol_irregular { pad_len =:= static; ENFORCE(nbits-8 == pad_len.UVALUE); } }
tcp_opt_nop { UNCOMPRESSED { type =:= uncompressed_value(8, 1) [ 8 ]; }
COMPRESSED nop_list_item { } COMPRESSED nop_irregular { } }
tcp_opt_mss { UNCOMPRESSED { type =:= uncompressed_value(8, 2) [ 8 ]; length =:= uncompressed_value(8, 4) [ 8 ]; mss [ 16 ]; }
COMPRESSED mss_list_item { mss =:= irregular(16) [ 16 ]; }
COMPRESSED mss_irregular { mss =:= static; } }
tcp_opt_wscale { UNCOMPRESSED { type =:= uncompressed_value(8, 3) [ 8 ]; length =:= uncompressed_value(8, 3) [ 8 ]; wscale [ 8 ]; }
COMPRESSED wscale_list_item { wscale =:= irregular(8) [ 8 ]; }
COMPRESSED wscale_irregular { wscale =:= static; } }
ts_lsb { UNCOMPRESSED { tsval [ 32 ]; }
COMPRESSED tsval_7 { discriminator =:= '0' [ 1 ]; tsval =:= lsb(7, -1) [ 7 ]; } COMPRESSED tsval_14 { discriminator =:= '10' [ 2 ]; tsval =:= lsb(14, -1) [ 14 ]; }
COMPRESSED tsval_21 { discriminator =:= '110' [ 3 ]; tsval =:= lsb(21, 0x00040000) [ 21 ]; }
COMPRESSED tsval_29 { discriminator =:= '111' [ 3 ]; tsval =:= lsb(29, 0x04000000) [ 29 ]; } }
tcp_opt_ts { UNCOMPRESSED { type =:= uncompressed_value(8, 8) [ 8 ]; length =:= uncompressed_value(8, 10) [ 8 ]; tsval [ 32 ]; tsecho [ 32 ]; } COMPRESSED tsopt_list_item { tsval =:= irregular(32) [ 32 ]; tsecho =:= irregular(32) [ 32 ]; }
COMPRESSED tsopt_irregular { tsval =:= ts_lsb [ 8, 16, 24, 32 ]; tsecho =:= ts_lsb [ 8, 16, 24, 32 ]; } } sack_pure_lsb(base) { UNCOMPRESSED { sack_field [ 32 ]; }
CONTROL { ENFORCE(sack_field.CVALUE == (sack_field.UVALUE - base)); }
COMPRESSED lsb_15 { ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x7fff); discriminator =:= '0' [ 1 ]; sack_field [ 15 ];
}
COMPRESSED lsb_22 { ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x3fffff); discriminator =:= '10' [ 2 ]; sack_field [ 22 ]; }
COMPRESSED lsb_29 { ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x1fffffff); discriminator =:= '110' [ 3 ]; sack_field [ 29 ]; }
COMPRESSED full_offset { discriminator =:= '11111111' [ 8 ]; sack_field [ 32 ]; } }
sack_block(reference)
{ UNCOMPRESSED { block_start [ 32 ]; block_end [ 32 ]; }
COMPRESSED { block_start =:= sack_pure_lsb(reference) [ 16, 24, 32, 40 ]; block_end =:= sack_pure_lsb(block_start.UVALUE) [ 16, 24, 32, 40 ]; } }
// The value of the parameter is set to the ack_number value // of the TCP header tcp_opt_sack(ack_value) {
UNCOMPRESSED { type =:= uncompressed_value(8, 5) [ 8 ]; length [ 8 ]; block_1 [ 64 ]; block_2 [ 0, 64 ]; block_3 [ 0, 64 ]; block_4 [ 0, 64 ]; } DEFAULT { length =:= static; block_2 =:= uncompressed_value(0, 0); block_3 =:= uncompressed_value(0, 0); block_4 =:= uncompressed_value(0, 0); }
COMPRESSED sack1_list_item { discriminator =:= '00000001'; block_1 =:= sack_block(ack_value); ENFORCE(length.UVALUE == 10); }
COMPRESSED sack2_list_item { discriminator =:= '00000010'; block_1 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF); ENFORCE(length.UVALUE == 18); }
COMPRESSED sack3_list_item { discriminator =:= '00000011'; block_1 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF); block_3 =:= sack_block(block_2.UVALUE && 0xFFFFFFFF); ENFORCE(length.UVALUE == 26); }
COMPRESSED sack4_list_item { discriminator =:= '00000100'; block_1 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF); block_3 =:= sack_block(block_2.UVALUE && 0xFFFFFFFF); block_4 =:= sack_block(block_3.UVALUE && 0xFFFFFFFF); ENFORCE(length.UVALUE == 34); }
COMPRESSED sack_unchanged_irregular { discriminator =:= '00000000'; block_1 =:= static; block_2 =:= static; block_3 =:= static; block_4 =:= static; }
COMPRESSED sack1_irregular { discriminator =:= '00000001'; block_1 =:= sack_block(ack_value); ENFORCE(length.UVALUE == 10); }
COMPRESSED sack2_irregular { discriminator =:= '00000010'; block_1 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF); ENFORCE(length.UVALUE == 18); }
COMPRESSED sack3_irregular { discriminator =:= '00000011'; block_1 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF); block_3 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF); ENFORCE(length.UVALUE == 26); }
COMPRESSED sack4_irregular { discriminator =:= '00000100'; block_1 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF); block_3 =:= sack_block(block_2.UVALUE && 0xFFFFFFFF); block_4 =:= sack_block(block_3.UVALUE && 0xFFFFFFFF); ENFORCE(length.UVALUE == 34); } }
tcp_opt_sack_permitted { UNCOMPRESSED { type =:= uncompressed_value(8, 4) [ 8 ]; length =:= uncompressed_value(8, 2) [ 8 ]; }
COMPRESSED sack_permitted_list_item { }
COMPRESSED sack_permitted_irregular { } }
tcp_opt_generic { UNCOMPRESSED { type [ 8 ]; length_msb =:= uncompressed_value(1, 0) [ 1 ]; length_lsb [ 7 ]; contents [ length_lsb.UVALUE*8-16 ]; }
CONTROL { option_static [ 1 ]; }
DEFAULT { type =:= static; length_lsb =:= static; contents =:= static; }
COMPRESSED generic_list_item { type =:= irregular(8) [ 8 ]; option_static =:= one_bit_choice [ 1 ]; length_lsb =:= irregular(7) [ 7 ]; contents =:= irregular(length_lsb.UVALUE*8-16) [ length_lsb.UVALUE*8-16 ]; }
// Used when context of option has option_static set to one COMPRESSED generic_static_irregular { ENFORCE(option_static.UVALUE == 1); }
// An item that can change, but currently is unchanged COMPRESSED generic_stable_irregular { discriminator =:= '11111111' [ 8 ]; ENFORCE(option_static.UVALUE == 0); }
// An item that is assumed to change constantly. // Length is not allowed to change here, since a length change is // most likely to cause new NOPs or an EOL length change. COMPRESSED generic_full_irregular { discriminator =:= '00000000' [ 8 ]; contents =:= irregular(length_lsb.UVALUE*8-16) [ length_lsb.UVALUE*8-16 ]; ENFORCE(option_static.UVALUE == 0); } }
tcp_list_presence_enc(presence) { UNCOMPRESSED { tcp_options; } COMPRESSED list_not_present { tcp_options =:= static [ 0 ]; ENFORCE(presence == 0); }
COMPRESSED list_present { tcp_options =:= list_tcp_options [ VARIABLE ]; ENFORCE(presence == 1); } }
///////////////////////////////////////////// // TCP Header /////////////////////////////////////////////
port_replicate(flags) { UNCOMPRESSED { port [ 16 ]; }
COMPRESSED port_static_enc { port =:= static [ 0 ]; ENFORCE(flags == 0b00); }
COMPRESSED port_lsb8 { port =:= lsb(8, 64) [ 8 ]; ENFORCE(flags == 0b01); }
COMPRESSED port_irr_enc { port =:= irregular(16) [ 16 ]; ENFORCE(flags == 0b10); } }
tcp_irreg_ip_ecn(ip_inner_ecn) { UNCOMPRESSED { ip_ecn_flags [ 2 ]; }
COMPRESSED ecn_present { // This field does not exist in the uncompressed header // and therefore cannot use uncompressed_value. ip_ecn_flags =:= compressed_value(2, ip_inner_ecn) [ 2 ];
ENFORCE(ecn_used.UVALUE == 1); }
COMPRESSED ecn_not_present { ip_ecn_flags =:= static [ 0 ]; ENFORCE(ecn_used.UVALUE == 0); } }
rsf_index_enc { UNCOMPRESSED { rsf_flag [ 3 ]; }
COMPRESSED none { rsf_idx =:= '00' [ 2 ]; rsf_flag =:= uncompressed_value(3, 0x00); }
COMPRESSED rst_only { rsf_idx =:= '01' [ 2 ]; rsf_flag =:= uncompressed_value(3, 0x04); }
COMPRESSED syn_only { rsf_idx =:= '10' [ 2 ]; rsf_flag =:= uncompressed_value(3, 0x02); }
COMPRESSED fin_only { rsf_idx =:= '11' [ 2 ]; rsf_flag =:= uncompressed_value(3, 0x01); } }
optional_2bit_padding(used_flag) { UNCOMPRESSED { }
COMPRESSED used { padding =:= compressed_value(2, 0x0) [ 2 ]; ENFORCE(used_flag == 1); }
COMPRESSED unused { padding =:= compressed_value(0, 0x0); ENFORCE(used_flag == 0); } }
// ack_stride_value is the user-selected stride for scaling the // TCP ack_number // ip_inner_ecn is the value bound when processing the innermost // IP header (ipv4 or ipv6 encoding method) tcp(payload_size, ack_stride_value, ip_inner_ecn) { UNCOMPRESSED { src_port [ 16 ]; dst_port [ 16 ]; seq_number [ 32 ]; ack_number [ 32 ]; data_offset [ 4 ]; tcp_res_flags [ 4 ]; tcp_ecn_flags [ 2 ]; urg_flag [ 1 ]; ack_flag [ 1 ]; psh_flag [ 1 ]; rsf_flags [ 3 ]; window [ 16 ]; checksum [ 16 ]; urg_ptr [ 16 ]; options [ (data_offset.UVALUE-5)*32 ]; }
CONTROL { dummy_field_s =:= field_scaling(payload_size, seq_number_scaled.UVALUE, seq_number.UVALUE, seq_number_residue.UVALUE) [ 0 ]; dummy_field_a =:= field_scaling(ack_stride.UVALUE, ack_number_scaled.UVALUE, ack_number.UVALUE, ack_number_residue.UVALUE) [ 0 ]; ENFORCE(ack_stride.UVALUE == ack_stride_value); }
INITIAL { ack_stride =:= uncompressed_value(16, 0); }
DEFAULT { src_port =:= static; dst_port =:= static; seq_number =:= static; ack_number =:= static; data_offset =:= inferred_offset; tcp_res_flags =:= static; tcp_ecn_flags =:= static; urg_flag =:= static; ack_flag =:= uncompressed_value(1, 1); rsf_flags =:= uncompressed_value(3, 0); window =:= static; urg_ptr =:= static; ack_stride =:= static; ack_number_scaled =:= static; seq_number_scaled =:= static; ack_number_residue =:= static; seq_number_residue =:= static; }
COMPRESSED tcp_static { src_port =:= irregular(16) [ 16 ]; dst_port =:= irregular(16) [ 16 ]; }
COMPRESSED tcp_dynamic { ecn_used =:= one_bit_choice [ 1 ]; ack_stride_flag =:= irregular(1) [ 1 ]; ack_zero =:= irregular(1) [ 1 ]; urp_zero =:= irregular(1) [ 1 ]; tcp_res_flags =:= irregular(4) [ 4 ]; tcp_ecn_flags =:= irregular(2) [ 2 ]; urg_flag =:= irregular(1) [ 1 ]; ack_flag =:= irregular(1) [ 1 ]; psh_flag =:= irregular(1) [ 1 ]; rsf_flags =:= irregular(3) [ 3 ]; msn =:= irregular(16) [ 16 ]; seq_number =:= irregular(32) [ 32 ]; ack_number =:= zero_or_irreg(ack_zero.CVALUE, 32) [ 0, 32 ]; window =:= irregular(16) [ 16 ]; checksum =:= irregular(16) [ 16 ]; urg_ptr =:= zero_or_irreg(urp_zero.CVALUE, 16) [ 0, 16 ]; ack_stride =:= static_or_irreg(ack_stride_flag.CVALUE, 16) [ 0, 16 ]; options =:= list_tcp_options [ VARIABLE ]; }
COMPRESSED tcp_replicate { reserved =:= '0' [ 1 ]; window_presence =:= irregular(1) [ 1 ]; list_present =:= irregular(1) [ 1 ]; src_port_presence =:= irregular(2) [ 2 ]; dst_port_presence =:= irregular(2) [ 2 ]; ack_stride_flag =:= irregular(1) [ 1 ]; ack_presence =:= irregular(1) [ 1 ]; urp_presence =:= irregular(1) [ 1 ]; urg_flag =:= irregular(1) [ 1 ]; ack_flag =:= irregular(1) [ 1 ]; psh_flag =:= irregular(1) [ 1 ]; rsf_flags =:= rsf_index_enc [ 2 ]; ecn_used =:= one_bit_choice [ 1 ]; msn =:= irregular(16) [ 16 ]; seq_number =:= irregular(32) [ 32 ]; src_port =:= port_replicate(src_port_presence) [ 0, 8, 16 ]; dst_port =:= port_replicate(dst_port_presence) [ 0, 8, 16 ]; window =:= static_or_irreg(window_presence, 16) [ 0, 16 ]; urg_point =:= static_or_irreg(urp_presence, 16) [ 0, 16 ]; ack_number =:= static_or_irreg(ack_presence, 32) [ 0, 32 ]; ecn_padding =:= optional_2bit_padding(ecn_used.CVALUE) [ 0, 2 ]; tcp_res_flags =:= static_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ]; tcp_ecn_flags =:= static_or_irreg(ecn_used.CVALUE, 2) [ 0, 2 ]; checksum =:= irregular(16) [ 16 ]; ack_stride =:= static_or_irreg(ack_stride_flag.CVALUE, 16) [ 0, 16 ]; options =:= tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; }
COMPRESSED tcp_irregular { ip_ecn_flags =:= tcp_irreg_ip_ecn(ip_inner_ecn) [ 0, 2 ]; tcp_res_flags =:= static_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ]; tcp_ecn_flags =:= static_or_irreg(ecn_used.CVALUE, 2) [ 0, 2 ]; checksum =:= irregular(16) [ 16 ]; } }
/////////////////////////////////////////////////// // Encoding methods used in compressed base headers /////////////////////////////////////////////////// dscp_enc(flag) { UNCOMPRESSED { dscp [ 6 ]; }
COMPRESSED static_enc { dscp =:= static [ 0 ]; ENFORCE(flag == 0); }
COMPRESSED irreg { dscp =:= irregular(6) [ 6 ]; padding =:= compressed_value(2, 0) [ 2 ]; ENFORCE(flag == 1); } }
Okay so this is where the compressed packet formats actually start to get going, bestie 💖 First up are the little helpers that deal with the IP-ID field and the Don't Fragment bit, and they're giving very structured, very particular energy ✨
ip_id_lsb(behavior, k, p)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
CONTROL {
ip_id_nbo [ 16 ];
}
COMPRESSED nbo {
ip_id_offset =:= lsb(k, p) [ k ];
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
}
COMPRESSED non_nbo {
ip_id_offset =:= lsb(k, p) [ k ];
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
ENFORCE(ip_id_nbo.UVALUE ==
(ip_id.UVALUE / 256) + (ip_id.UVALUE % 256) * 256);
ENFORCE(ip_id_nbo.ULENGTH == 16);
ENFORCE(ip_id_offset.UVALUE == ip_id_nbo.UVALUE - msn.UVALUE);
}
}
optional_ip_id_lsb(behavior, indicator)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
COMPRESSED short {
ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ];
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
ENFORCE(indicator == 0);
}
COMPRESSED long {
ip_id =:= irregular(16) [ 16 ];
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
ENFORCE(indicator == 1);
ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
}
COMPRESSED not_present {
ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
(behavior == IP_ID_BEHAVIOR_ZERO));
}
}
dont_fragment(version)
{
UNCOMPRESSED {
df [ 1 ];
}
COMPRESSED v4 {
df =:= irregular(1) [ 1 ];
ENFORCE(version == 4);
}
COMPRESSED v6 {
df =:= compressed_value(1, 0) [ 1 ];
ENFORCE(version == 6);
}
}Next up is the big one, the base header for the common format. It's the compressed version of the innermost IP header AND the TCP header all squished together, so it's basically the main character of this whole section 💅🦋
//////////////////////////////////
// Actual start of compressed packet formats
// Important note:
// The base header is the compressed representation
// of the innermost IP header AND the TCP header.
//////////////////////////////////
// ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit
// of an outer header has changed. The same value must be passed as
// an argument to the ipv4/ipv6 encoding methods when extracting
// the irregular chain items.
co_baseheader(payload_size, ack_stride_value,
ttl_irregular_chain_flag, ip_id_behavior_value)
{
UNCOMPRESSED v4 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
dscp [ 6 ];
ip_ecn_flags [ 2 ];
length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
next_header [ 8 ];
checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dest_port [ 16 ];
seq_number [ 32 ];
ack_number [ 32 ];
data_offset [ 4 ];
tcp_res_flags [ 4 ];
tcp_ecn_flags [ 2 ];
urg_flag [ 1 ];
ack_flag [ 1 ];
psh_flag [ 1 ];
rsf_flags [ 3 ];
window [ 16 ];
tcp_checksum [ 16 ];
urg_ptr [ 16 ];
options [ (data_offset.UVALUE-5)*32 ];
}
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
version =:= uncompressed_value(4, 6) [ 4 ];
dscp [ 6 ];
ip_ecn_flags [ 2 ];
flow_label [ 20 ];
payload_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dest_port [ 16 ];
seq_number [ 32 ];
ack_number [ 32 ];
data_offset [ 4 ];
tcp_res_flags [ 4 ];
tcp_ecn_flags [ 2 ];
urg_flag [ 1 ];
ack_flag [ 1 ];
psh_flag [ 1 ];
rsf_flags [ 3 ];
window [ 16 ];
tcp_checksum [ 16 ];
urg_ptr [ 16 ];
options [ (data_offset.UVALUE-5)*32 ];
df =:= uncompressed_value(0,0) [ 0 ];
ip_id =:= uncompressed_value(0,0) [ 0 ];
}
CONTROL {
dummy_field_s =:= field_scaling(payload_size,
seq_number_scaled.UVALUE, seq_number.UVALUE,
seq_number_residue.UVALUE) [ 0 ];
dummy_field_a =:= field_scaling(ack_stride.UVALUE,
ack_number_scaled.UVALUE, ack_number.UVALUE,
ack_number_residue.UVALUE) [ 0 ];
ENFORCE(ack_stride.UVALUE == ack_stride_value);
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
}
INITIAL {
ack_stride =:= uncompressed_value(16, 0);
}
DEFAULT {
tcp_ecn_flags =:= static;
data_offset =:= inferred_offset;
tcp_res_flags =:= static;
rsf_flags =:= uncompressed_value(3, 0);
dest_port =:= static;
dscp =:= static;
src_port =:= static;
urg_flag =:= uncompressed_value(1, 0);
window =:= static;
dest_addr =:= static;
version =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
ack_number =:= static;
urg_ptr =:= static;
seq_number =:= static;
ack_flag =:= uncompressed_value(1, 1);
// The default for "options" is case 2) and 3) from
// the list in Section 6.3.1 (i.e., nothing present in the
// baseheader itself).
payload_length =:= inferred_ip_v6_length;
checksum =:= inferred_ip_v4_header_checksum;
length =:= inferred_ip_v4_length;
flow_label =:= static;
next_header =:= static;
ip_ecn_flags =:= static;
// The tcp_checksum has no default,
// it is considered a part of tcp_irregular
ip_id_behavior_innermost =:= static;
ecn_used =:= static;
ack_stride =:= static;
ack_number_scaled =:= static;
seq_number_scaled =:= static;
ack_number_residue =:= static;
seq_number_residue =:= static;
// Default is to have no TTL in irregular chain
// Can only be nonzero if co_common is used
ENFORCE(ttl_irregular_chain_flag == 0);
}Now we get to the compressed formats themselves. The common one is the everyday workhorse, and then there are two sneaky little variants that send scaled sequence number LSBs, which is peak efficiency energy 🍓✨
////////////////////////////////////////////
// Common compressed packet format
////////////////////////////////////////////
COMPRESSED co_common {
discriminator =:= '1111101' [ 7 ];
ttl_hopl_outer_flag =:=
compressed_value(1, ttl_irregular_chain_flag) [ 1 ];
ack_flag =:= irregular(1) [ 1 ];
psh_flag =:= irregular(1) [ 1 ];
rsf_flags =:= rsf_index_enc [ 2 ];
msn =:= lsb(4, 4) [ 4 ];
seq_indicator =:= irregular(2) [ 2 ];
ack_indicator =:= irregular(2) [ 2 ];
ack_stride_indicator =:= irregular(1) [ 1 ];
window_indicator =:= irregular(1) [ 1 ];
ip_id_indicator =:= irregular(1) [ 1 ];
urg_ptr_present =:= irregular(1) [ 1 ];
reserved =:= compressed_value(1, 0) [ 1 ];
ecn_used =:= one_bit_choice [ 1 ];
dscp_present =:= irregular(1) [ 1 ];
ttl_hopl_present =:= irregular(1) [ 1 ];
list_present =:= irregular(1) [ 1 ];
ip_id_behavior_innermost =:= irregular(2) [ 2 ];
urg_flag =:= irregular(1) [ 1 ];
df =:= dont_fragment(version.UVALUE) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
seq_number =:=
variable_length_32_enc(seq_indicator.CVALUE) [ 0, 8, 16, 32 ];
ack_number =:=
variable_length_32_enc(ack_indicator.CVALUE) [ 0, 8, 16, 32 ];
ack_stride =:=
static_or_irreg(ack_stride_indicator.CVALUE, 16) [ 0, 16 ];
window =:=
static_or_irreg(window_indicator.CVALUE, 16) [ 0, 16 ];
ip_id =:=
optional_ip_id_lsb(ip_id_behavior_innermost.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
urg_ptr =:=
static_or_irreg(urg_ptr_present.CVALUE, 16) [ 0, 16 ];
dscp =:=
dscp_enc(dscp_present.CVALUE) [ 0, 8 ];
ttl_hopl =:=
static_or_irreg(ttl_hopl_present.CVALUE, 8) [ 0, 8 ];
options =:=
tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ];
}
// Send LSBs of sequence number
COMPRESSED rnd_1 {
discriminator =:= '101110' [ 6 ];
seq_number =:= lsb(18, 65535) [ 18 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send scaled sequence number LSBs
COMPRESSED rnd_2 {
discriminator =:= '1100' [ 4 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE(payload_size != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
} // Send acknowledgment number LSBs
COMPRESSED rnd_3 {
discriminator =:= '0' [ 1 ];
ack_number =:= lsb(15, 8191) [ 15 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send acknowledgment number scaled
COMPRESSED rnd_4 {
discriminator =:= '1101' [ 4 ];
ack_number_scaled =:= lsb(4, 3) [ 4 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE(ack_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send ACK and sequence number
COMPRESSED rnd_5 {
discriminator =:= '100' [ 3 ];
psh_flag =:= irregular(1) [ 1 ];
msn =:= lsb(4, 4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
seq_number =:= lsb(14, 8191) [ 14 ];
ack_number =:= lsb(15, 8191) [ 15 ];
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send both ACK and scaled sequence number LSBs
COMPRESSED rnd_6 {
discriminator =:= '1010' [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
psh_flag =:= irregular(1) [ 1 ];
ack_number =:= lsb(16, 16383) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
ENFORCE(payload_size != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send ACK and window
COMPRESSED rnd_7 {
discriminator =:= '101111' [ 6 ];
ack_number =:= lsb(18, 65535) [ 18 ];
window =:= irregular(16) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// An extended packet type for seldom-changing fields
// Can send LSBs of TTL, RSF flags, change ECN behavior, and
// options list
COMPRESSED rnd_8 {
discriminator =:= '10110' [ 5 ];
rsf_flags =:= rsf_index_enc [ 2 ];
list_present =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
ttl_hopl =:= lsb(3, 3) [ 3 ];
ecn_used =:= one_bit_choice [ 1 ];
seq_number =:= lsb(16, 65535) [ 16 ];
ack_number =:= lsb(16, 16383) [ 16 ];
options =:=
tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ];
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send LSBs of sequence number
COMPRESSED seq_1 {
discriminator =:= '1010' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ];
seq_number =:= lsb(16, 32767) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send scaled sequence number LSBs
COMPRESSED seq_2 {
discriminator =:= '11010' [ 5 ];
ip_id =:=
ip_id_lsb(ip_id_behavior_innermost.UVALUE, 7, 3) [ 7 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE(payload_size != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send acknowledgment number LSBs
COMPRESSED seq_3 {
discriminator =:= '1001' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ];
ack_number =:= lsb(16, 16383) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send scaled acknowledgment number scaled
COMPRESSED seq_4 {
discriminator =:= '0' [ 1 ];
ack_number_scaled =:= lsb(4, 3) [ 4 ];
// Due to having very few ip_id bits, no negative offset
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 3, 1) [ 3 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE(ack_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send ACK and sequence number
COMPRESSED seq_5 {
discriminator =:= '1000' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ];
ack_number =:= lsb(16, 16383) [ 16 ];
seq_number =:= lsb(16, 32767) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send both ACK and scaled sequence number LSBs
COMPRESSED seq_6 {
discriminator =:= '11011' [ 5 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 7, 3) [ 7 ];
ack_number =:= lsb(16, 16383) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE(payload_size != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send ACK and window
COMPRESSED seq_7 {
discriminator =:= '1100' [ 4 ];
window =:= lsb(15, 16383) [ 15 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5, 3) [ 5 ];
ack_number =:= lsb(16, 32767) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// An extended packet type for seldom-changing fields
// Can send LSBs of TTL, RSF flags, change ECN behavior, and
// options list
COMPRESSED seq_8 {
discriminator =:= '1011' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4, 3) [ 4 ];
list_present =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
ttl_hopl =:= lsb(3, 3) [ 3 ];
ecn_used =:= one_bit_choice [ 1 ];
ack_number =:= lsb(15, 8191) [ 15 ];
rsf_flags =:= rsf_index_enc [ 2 ];
seq_number =:= lsb(14, 8191) [ 14 ];
options =:=
tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ];
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
}8.3. Feedback Formats and Options ✨
RFC>>>
8.3.1. Feedback Formats 💌
Okay so this bit covers the feedback formats for the ROHC-TCP profile 🎀. They follow the general ROHC feedback format from Section 5.2.4 of [RFC5795], so if you know that one, you're already halfway there 🧚
Every feedback format carries a field called MSN 🫶. The MSN field holds the LSBs of the MSN control field from Section 6.1.1. The sequence number to use is the MSN that goes with the last header that got successfully CRC-8 validated or CRC verified ✨
FEEDBACK-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MSN |
+---+---+---+---+---+---+---+---+MSN: The LSB-encoded master sequence number.
A FEEDBACK-1 is an ACK 💖. If you want to send a NACK or a STATIC-NACK, you need FEEDBACK-2 instead, no exceptions 💅
FEEDBACK-2
FEEDBACK-2 is the upgraded one 👑. It always carries a CRC, which makes it way more robust than FEEDBACK-1. Check out the layout:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| MSN |
+---+---+---+---+---+---+---+---+
| MSN |
+---+---+---+---+---+---+---+---+
| CRC |
+---+---+---+---+---+---+---+---+
/ Feedback options /
+---+---+---+---+---+---+---+---+Acktype:0 = ACK1 = NACK2 = STATIC-NACK3is reserved (MUST NOT be used for parsability) 🙈
MSN: The LSB-encoded master sequence number.CRC: 8-bit CRC computed over the entire feedback element (as defined in Section 5.3.1.1 of [RFC5795]). For the purpose of computing the CRC, the CRC field is zero. The CRC is calculated using the polynomial defined in [RFC5795].Feedback options: A variable number of feedback options, see Section 8.3.2. Options may appear in any order. 🌈
Here's the vibe check for receiving a FEEDBACK-2 🔥. The compressor MUST verify the info by computing the CRC and comparing the result with the CRC carried in the feedback format. If the two are not identical, the feedback element MUST be discarded 💀
A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an acknowledgment for a successfully decompressed packet 🦋. That packet is whichever one matches the MSN of the feedback element, unless the MSN-NOT-VALID option (Section 8.3.2.2) shows up in the element.
8.3.2. Feedback Options 🍓
A ROHC-TCP feedback option is variable length and looks like this:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type | Opt Len |
+---+---+---+---+---+---+---+---+
/ option data / Opt Length (octets)
+---+---+---+---+---+---+---+---+Each ROHC-TCP feedback option can appear at most once within a FEEDBACK-2 ✨
8.3.2.1. The REJECT Option 🙅♀️
The REJECT option basically tells the compressor that the decompressor doesn't have enough resources to handle the flow 😩
+---+---+---+---+---+---+---+---+
| Opt Type = 2 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+When a compressor gets a REJECT option, it MUST stop compressing the packet flow 🛑. It SHOULD also refrain from trying to increase the number of compressed packet flows for some time. The REJECT option MUST NOT appear more than once in the FEEDBACK-2 format. If it does, the compressor MUST discard the entire feedback element 💅
8.3.2.2. The MSN-NOT-VALID Option 🙈
The MSN-NOT-VALID option says the MSN of the feedback is not valid 🙃
+---+---+---+---+---+---+---+---+
| Opt Type = 3 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+A compressor MUST ignore the MSN of the feedback element whenever this option is present. So a NACK or a STATIC-NACK feedback type sent with the MSN-NOT-VALID option is equivalent to a STATIC-NACK, semantically speaking 🧠
The MSN-NOT-VALID option MUST NOT appear more than once in the FEEDBACK-2 format. It also MUST NOT appear in the same feedback element as the MSN option. Break either rule and the compressor MUST discard the entire feedback element 🚫
8.3.2.3. The MSN Option 🔢
The MSN option gives you 2 additional bits of MSN ✨
+---+---+---+---+---+---+---+---+
| Opt Type = 4 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| MSN | Reserved |
+---+---+---+---+---+---+---+---+Those 2 bits are the least significant bits of the MSN, so they get concatenated with the 14 bits already in the FEEDBACK-2 format 🧩
The MSN option MUST NOT appear more than once in the FEEDBACK-2 format. It also MUST NOT appear in the same feedback element as the MSN-NOT-VALID option. If either happens, the compressor MUST discard the entire feedback element 💀
8.3.2.4. The CONTEXT_MEMORY Feedback Option 🧚♀️
The CONTEXT_MEMORY option means the decompressor doesn't have enough memory to handle the context of the packet flow, given how the flow is currently compressed 🥺
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+When a compressor receives a CONTEXT_MEMORY option, it SHOULD take actions to compress the packet flow in a way that needs less decompressor memory, or it can stop compressing the flow altogether 🧃
The CONTEXT_MEMORY option MUST NOT appear more than once in the FEEDBACK-2 format. If it does, the compressor MUST discard the entire feedback element 🙅♀️
8.3.2.5. Unknown Option Types 👀
If the compressor runs into an option type it doesn't know, it MUST keep parsing the rest of the FEEDBACK element. That's totally doable because the option length is explicit 🫶. It MUST otherwise ignore the unknown option, so no drama 💜
9. Changes from RFC 4996 🌸
This RFC revises RFC 4996 💖. It's mostly backwards-compatible with RFC 4996, except for two cases that didn't interoperate the way they were described, which we'll get into below 👀
9.1. Functional Changes ⭐
- The SACK option compression in [RFC4996] assumed that multiple SACK blocks inside the same option would be in sorted order, so the block starts were LSB-encoded from the end of the previous block. That meant SACK blocks that weren't sorted could be impossible to compress in some cases 😭. So the SACK compression in the formal notation changed, and the bits-on-the-wire changed along with it 🔥.
- The ESP NULL header compression got deprecated because of interoperability problems with needing to know information from the trailer 💀. ESP NULL compression was already removed from ROHCv2 [RFC5225] for the same reason, and it was considered better to remove it from this profile instead of trying to fix the interoperability issue 🙅♀️.
9.2. Non-functional Changes 🧁
- The way sequential IP-ID compression was described in the FN code was incorrect, so the code used for ROHCv2 [RFC5225] got imported into this specification. For example, offset is now a global control field. This doesn't change the bits-on-the-wire 🙌. The only change is how the encoding is described in the formal notation, not how compression actually happens.
- Default encoding for the
'df'and'ip_id'fields has been added for IPv6 with the 0-bit uncompressed format. This just clarifies that these never appear in IPv6 ✨. - The scaled encoding of the Acknowledgment Number and Sequence Number was described incorrectly in the FN code in [RFC4996]. It's been updated in the same style as in ROHCv2 [RFC5225]. Again, this doesn't change the bits-on-the-wire, only how the compression is described in the FN code 🧠.
- The external arguments to ipv4 and co_baseheader have been updated. This is again only a change for FN correctness and doesn't affect interoperability 🫶.
- Errata for [RFC4996] related to minor errors in the FN and textual errors have also been corrected 🎀.
10. Security Considerations 💀
Okay, bestie, this section is SERIOUS, so let's take it seriously 🙏. A malfunctioning or malicious header compressor could make the header decompressor rebuild packets that don't match the original packets, even though they still have valid IP and TCP headers, and possibly valid TCP checksums too 😱. That kind of corruption may be detected with end-to-end authentication and integrity mechanisms, which won't be affected by the compression. On top of that, this header compression scheme uses an internal checksum to verify reconstructed headers 🔐. That lowers the chance of decompressed headers not matching the originals without anyone noticing.
Denial-of-service attacks are possible if an intruder can slip bogus IR, CO, or FEEDBACK packets onto the link and reduce compression efficiency as a result 🚨. Honestly though, an intruder who can inject arbitrary packets at the link layer raises security issues that completely dwarf the ones related to header compression 💅.
11. IANA Considerations 🌈
The reference for the ROHC profile identifier 0x0006 has been updated to point to this document instead of RFC 4996 ✨.
A ROHC profile identifier has been reserved by IANA for the profile defined in this document. Profiles 0x0000-0x0005 were reserved before, and this profile is 0x0006 🎀. Just like with previous ROHC profiles, profile numbers 0xnn06 have been reserved for future updates of this profile 🔮.
Profile Usage Document
identifier
0x0006 ROHC TCP [RFC6846]
0xnn06 Reserved12. Acknowledgments 🫶
The authors want to thank Qian Zhang, Hong Bin Liao, Richard Price, and Fredrik Lindstroem for their work on early versions of this specification 💜. Thanks also to Robert Finking and Carsten Bormann for valuable input, and to Carl Knutsson and Gilbert Strom for suggestions and review of the updates made in this document 🙌.
Additional thanks go out to committed reviewers Joe Touch and Ted Faber, who reviewed this document during working group last-call, and to Sally Floyd, who provided a review at the request of the Transport Area Directors 👑.
13. References 📚
13.1. Normative References 💖
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC4164] Pelletier, G., "RObust Header Compression (ROHC): Context
Replication for ROHC Profiles", RFC 4164, August 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust
Header Compression (ROHC-FN)", RFC 4997, July 2007.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795,
March 2010.13.2. Informative References ✨
okay bestie, this is the reading list 📚 these are the background docs. they're not required to implement the thing, but they're the receipts for the context 💅
[RFC1144]Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990. 🦋[RFC1323]Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. 🌸[RFC2018]Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996. 💜[RFC2507]Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999. 🎀[RFC2883]Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000. ✨[RFC3095]Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. 🧚 this one has SO many authors, the group project energy is unmatched 😭[RFC3168]Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. 🍓[RFC3759]Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004. 🌈[RFC4163]Jonsson, L-E., "RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression", RFC 4163, August 2005. 💅[RFC4224]Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006. 🫶[RFC4413]West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, March 2006. 🌸[RFC4996]Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", RFC 4996, July 2007. 👑 this is the one we've been talking about this whole time, iconic[RFC5225]Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008. 🔥[RFC5681]Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009. ⭐
Authors' Addresses 🎀
these are the people behind the spec, so here's how to reach them if you have questions. be nice and say hi 🫶
Ghyslain Pelletier InterDigital Communications 1000, Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada
Phone: +46 (0) 70 609 27 73 EMail: ghyslain.pelletier@interdigital.com
Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28 Sweden
Phone: +46 (0) 8 404 41 58 EMail: kristofer.sandlund@ericsson.com
Lars-Erik Jonsson Optand 737 Ostersund SE-831 92 Sweden
Phone: +46 70 365 20 58 EMail: lars-erik@lejonsson.com
Mark A West Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hampshire SO51 0ZN UK
Phone: +44 1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk
📦 where this page comes from
- ietf: rfc6846 2013-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms