7. Compression of subheaders
This section gives rules for how the compressible chain of subheaders is compressed. These rules MUST be followed. Subheaders that may be compressed include IPv6 base and extension headers, TCP headers, UDP headers, and IPv4 headers. The compressible chain of subheaders extends from the beginning of the header
a) up to but not including the first header that is not an IPv4 header, an IPv6 base or extension header, a TCP header, or a UDP header, or
b) up to and including the first TCP header, UDP header, Fragment Header, Encapsulating Security Payload Header, or IPv4 header for a fragment,
whichever gives the shorter chain. For example, rules a) and b) both fit a chain of subheaders that contain a Fragment Header and ends at a tunneled IPX packet. Since rule b) gives a shorter chain, the compressible chain of subheaders stops at the Fragment Header.
The following subsections are a systematic classification of how all fields in subheaders are expected to change.
NOCHANGE The field is not expected to change. Any change means that a full header MUST be sent to update the context.
DELTA The field may change often but usually the difference from the field in the previous header is small, so that it is cheaper to send the change from the previous value rather than the current value. This type of compression is only used for TCP packet streams.
RANDOM The field must be included "as-is" in compressed headers, usually because it changes unpredictably.
INFERRED The field contains a value that can be inferred from other values, for example the size of the frame carrying the packet, and thus must not be included in the compressed header.
The classification implies how a compressed header is constructed. No field that is NOCHANGE or INFERRED is present in a compressed header. A compressor obtains the values of NOCHANGE fields from the context identified by the compression identifier, and obtains the values of INFERRED fields from the link-layer implementation, e.g., from the size of the link-layer frame, or from other fields, e.g., by recalculating the IPv4 header checksum. DELTA fields are encoded as the difference to the value in the previous packet in the same packet stream. The decompressor must update the context by adding the value in the compressed header to the value in its context. The result is the proper value of the field. RANDOM fields must be sent "as-is" in the compressed header. RANDOM fields must occur in the same order in the compressed header as they occur in the full header.
Fields that may optionally be used to identify what packet stream a packet belongs to according to section 4.1 are marked with the word DEF. To a compressor using the optional guidelines from section 4.1, any difference in corresponding DEF fields between two packets implies that they belong to different packet streams. Moreover, if a DEF field is present in one packet but not in another, the packets belong to different packet streams.
7.1. IPv6 Header [IPv6, section 3]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version NOCHANGE (DEF)
Traffic Class NOCHANGE (might be DEF, see sect 4.1)
(see also sect 6 a)
Flow Label NOCHANGE (DEF)
Payload Length INFERRED
Next Header NOCHANGE
Hop Limit NOCHANGE (might be DEF, see sect 4.1)
Source Address NOCHANGE (DEF)
Destination Address NOCHANGE (DEF)
The Payload Length field of encapsulated headers must correspond to the length value of the encapsulating header. If not, the header chain MUST NOT be compressed.
NOTE: If this the IP header closest to a TCP header, bit 7 of the Traffic Class field can be passed using the R-flag of the compressed TCP header. See section 6 a).
This classification implies that the entire IPv6 base header will be compressed away.
7.2. IPv6 Extension Headers [IPv6, section 4]
What extension headers are present and the relative order of them is not expected to change in a packet stream. Whenever there is a change, a full packet header must be sent. All Next Header fields in IPv6 base header and IPv6 extension headers are NOCHANGE.
7.3. Options [IPv6, section 4.2]
The contents of Hop-by-hop Options and Destination Options extension headers are encoded with TLV "options" (see [IPv6]):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type and Opt Data Len fields are assumed to be fixed for a given packet stream, so they are classified as NOCHANGE. The Option data is RANDOM unless specified otherwise below.
Padding
Pad1 option
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Entire option is NOCHANGE.
PadN option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
All fields are NOCHANGE.
7.4. Hop-by-Hop Options Header [IPv6, section 4.3]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE
Hdr Ext Len NOCHANGE
Options TLV coded values and padding.
Classified according to 7.3 above, unless
being a Jumbo Payload option (see below).
Jumbo Payload option +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 194 |Opt Data Len=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Jumbo Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First two fields are NOCHANGE and Jumbo Payload Length INFERRED. (frame length must be supplied by link layer implementation).
NOTE: It is silly to compress the headers of a packet carrying a
Jumbo Payload Option since the relative header overhead is
negligible. Moreover, it is usually a bad idea to send such
large packets over low- and medium-speed links.
7.5. Routing Header [IPv6, section 4.4]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fields of the Routing Header are NOCHANGE.
If the Routing Type is not recognized, it is impossible to determine the final Destination Address unless the Segments Left field has the value zero, in which case the Destination Address is the final Destination Address in the basic IPv6 header.
In the Type 0 Routing Header, the last address is DEF if (Segments Left > 0).
Routing Headers are compressed away completely. This is a big win as the maximum size of the Routing Header is 392 octets. Moreover, Type 0 Routing Headers with one address, size 24 octets, are used by Mobile IP.
7.6. Fragment Header [IPv6, section 4.5]
The first fragment of a packet has Fragment Offset = 0 and the chain of subheaders extends beyond its Fragment Header. If a fragment is not the first (Fragment Offset not 0), there are no subsequent subheaders (unless the chain of subheaders in the first fragment didn't fit entirely in the first fragment).
Since packets may be reordered before reaching the compression point, and some fragments may follow other routes through the network, a compressor cannot rely on seeing the first fragment before other fragments. This implies that information in subheaders following the Fragment Header of the first fragment cannot be examined to determine the proper packet stream for other fragments.
It is possible to design compression schemes that can compress subheaders after the Fragment Header, at least in the first fragment, but to avoid complicating the rules for sending full headers and the rules for compression and decompression, the chain of subheaders that follow a Fragment Header MUST NOT be compressed.
The fields of the Fragment Header are classified as follows.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE
Reserved NOCHANGE
Res RANDOM
M flag RANDOM
Fragment Offset RANDOM
Identification RANDOM
This classification implies that a Fragment Header is compressed down to 6 octets. The minimum IPv6 MTU is 1280 octets so most fragments will be at least 1280 octets. Since the 6 octet overhead of the compressed fragment header is amortized over a fairly large packet, the additional complexity of more sophisticated compression schemes is not justifiable.
NOTE: The Identification field is RANDOM instead of NOCHANGE
to avoid one compression slow-start per original packet.
Grouping of fragments according to the optional guidelines in section4.1:
Fragments and unfragmented packets should not be grouped
together.
Port numbers cannot be used to identify the packet stream because
port numbers are not present in every fragment. To adhere to the
uniqueness rules for the Identification value, a fragmented
packet stream is identified by the combination of Source Address
and (final) Destination Address.
NOTE: The Identification value is NOT used to identify the
packet stream. This avoids using a new CID for each packet and
saves the cost of the associated compression slow-start. We
expect that the unfragmentable part of the headers will not
change too frequently, if it does thrashing may occur.
7.7. Destination Options Header [IPv6, section 4.6]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE
Hdr Ext Len NOCHANGE
Options TLV coded values and padding.
Compressed according to 7.3 above.
The only Destination Options defined in [IPv6] are the padding options.
7.8. No Next Header [IPv6, section 4.7]
Covered by rules for IPv6 Header Extensions (7.2).
7.9. Authentication Header [RFC-2402, section 3.2]
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Header | Length | RESERVED |
+---------------+---------------+---------------+---------------+
| Security Parameters Index (SPI) |
+---------------+---------------+---------------+---------------+
| |
+ Authentication Data (variable number of 32-bit words) |
| |
+---------------+---------------+---------------+---------------+
Next Header NOCHANGE
Length NOCHANGE
Reserved NOCHANGE
SPI NOCHANGE (DEF)
Authentication Data RANDOM
[RFC-1828] specifies how to do authentication with keyed MD5, the authentication method all IPv6 implementations must support. For this method, the Authentication Data is 16 octets.
7.10. Encapsulating Security Payload Header [RFC-2406, section 3.1]
This header implies that the subsequent parts of the packet are encrypted. Thus, no further header compression is possible on subsequent headers as encryption is typically already performed when the compressor sees the packet.
However, when the ESP Header is used in tunnel mode an entire IP packet is encrypted, and the headers of that packet MAY be compressed before the packet is encrypted at the entry point of the tunnel. This means that it must be possible to feed an IP packet and its length to the decompressor, as if it came from the link-layer. The mechanisms for dealing with reordering described in section 11 MUST also be used, as packets can be reordered in a tunnel.
+---------------+---------------+---------------+---------------+
| Security Association Identifier (SPI), 32 bits |
+===============+===============+===============+===============+
| Opaque Transform Data, variable length |
+---------------+---------------+---------------+---------------+
SPI NOCHANGE (DEF)
Opaque Transform Data RANDOM
Everything after the SPI is encrypted and is not compressed.
7.11. UDP Header
The UDP header is described in [RFC-768].
The Next Header field (IPv6) or Protocol field (IPv4) in the preceding subheader is DEF.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port NOCHANGE (DEF)
Destination Port NOCHANGE (DEF)
Length INFERRED
Checksum RANDOM, unless it is zero,
in which case it is NOCHANGE.
The Length field of the UDP header MUST match the Length field(s) of preceding subheaders, i.e, there must not be any padding after the UDP payload that is covered by the IP Length.
The UDP header is typically compressed down to 2 octets, the UDP checksum. When the UDP checksum is zero (which it cannot be with IPv6), it is likely to be so for all packets in the flow and is defined to be NOCHANGE. This saves 2 octets in the compressed header.
7.12. TCP Header
The TCP header is described in [RFC-793].
The Next Header field (IPv6) or Protocol field (IPv4) in the preceding subheader is DEF.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset| Reserved |U|A|P|R|S|F| Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U, A, P, R, S, and F stands for Urg, Ack, Psh, Rst, Syn, and Fin.
There are two ways to compress the TCP header.
7.12.1. Compressed with differential encoding
Source Port NOCHANGE (DEF) Destination Port NOCHANGE (DEF) Sequence Number DELTA Acknowledgment Number DELTA Offset NOCHANGE Reserved DELTA (if differs from context, set R-flag in flag octet and send absolute value as described in 6 a.) Urg,Psh RANDOM (placed in flag octet) Ack INFERRED to be 1 Rst,Syn,Fin INFERRED to be 0 Window DELTA (if change in Window, set W-flag in flag octet and send difference) Checksum RANDOM Urgent Pointer DELTA (if Urg is set, send absolute value) Options, Padding DELTA (if change in Options, set O-flag and send whole Options, Padding)
A packet with a TCP header compressed according to the above must be indicated to be of type COMPRESSED_TCP. The compressed header is described in section 6.
This method is essentially the differential encoding techniques of Jacobson, described in [RFC-1144], the differences being the placement of the compressed TCP header fields (see section 6), the use of the O-flag, the use of the R-flag, and elimination of the C-flag. The O-flag allows compression of the TCP header when the Timestamp option is used and the Options fields changes with each header.
DELTA values (except for Reserved field and Options, Padding) MUST be coded as in [RFC-1144]. A Reserved field value passed with the R-flag MUST NOT update the context at compressor or decompressor.
7.12.2. Without differential encoding
Source Port NOCHANGE (DEF)
Destination Port NOCHANGE (DEF)
(all the rest) RANDOM
The Identification field in a preceding IPv4 header is RANDOM.
A packet with a TCP header compressed according to the above must be indicated to be of type COMPRESSED_TCP_NODELTA. It uses the same CID space as COMPRESSED_TCP packets, and the header MUST be saved as context. The compressed header is described in section 6.
This packet type can be sent as the response to a header request instead of sending a full header, can be used over links that reorder packets, and can be sent instead of a full header when there are changes that cannot be represented by a compressed header. A sophisticated compressor can switch to sending only COMPRESSED_TCP_NODELTA headers when the packet loss frequency is high.
7.13. IPv4 header [RFC-791, section 3.1]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are two ways to compress the IPv4 header
a) If the IPv4 header is not for a fragment (MF flag is not set and Fragment Offset is zero) and there are no options (IHL is 5), it is classified as follows
Version NOCHANGE (DEF)
IHL NOCHANGE (DEF, must be 5)
Type of Service NOCHANGE (might be DEF, see sect 4.1)
(see also 6 a)
Total Length INFERRED (from link-layer implementation
or encapsulating IP header)
Identification DELTA/ (If the Protocol field has the
(value corresponding to TCP)
RANDOM (otherwise)
Flags NOCHANGE (MF flag must not be set)
Fragment Offset NOCHANGE (must be zero)
Time to Live NOCHANGE (might be DEF, see sect 4.1)
Protocol NOCHANGE
Header Checksum INFERRED (calculated from other fields)
Source Address NOCHANGE (DEF)
Destination Address NOCHANGE (DEF)
Options, Padding (not present)
Note: When a TCP header immediately follows, the IPv4 and TCP
header MUST be compressed as a unit as described in section 6.
Bits 6 and 7 of the Type of Service field (bits 14 and 15 of the
first word) can then be passed using the R-flag (see section 6
a).
b) If the IPv4 header is for a fragment (MF bit set or Fragment Offset nonzero), or there are options (IHL > 5), all fields are RANDOM (i.e., if the header is compressed all fields are sent as-is and not compressed). This classification allows compression of the tunnel header, but not the fragment header, when fragments are tunneled. If the IPv4 header is for a fragment it ends the compressible chain of subheaders, i.e., it must be the last subheader to be compressed. If the IPv4 header has options but is not for a fragment it does not end the compressible chain of subheaders, so subsequent subheaders can be compressed.
A compressor that follows the optional guidelines of section 4.1 will in case a) use the Version, Source Address and Destination Address to define the packet stream, together with the fact that there are no IPv4 options and that this is not a fragment.
Case b) can define two kinds of packet streams depending on whether the IPv4 header is for a fragment or not.
If the IPv4 header in case b) is for a fragment, a compressor following the optional guidelines will use that fact together with the Version, Source Address, and Destination Address to determine the packet stream.
If the IPv4 header in case b) is not for a fragment, it must have options. A compressor following the optional guidelines will use that fact, but not the size of the options, together with the Version, Source Address, and Destination Address to determine the packet stream.
7.14. Minimal Encapsulation header [RFC-2004, section 3.1]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |S| reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Original Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol NOCHANGE
Original Source Address Present (S) NOCHANGE
reserved NOCHANGE
Header Checksum INFERRED (calculated from
other values)
Original Destination Address NOCHANGE
Original Source Address NOCHANGE (present only
if S=1)
This header is likely to be used by Mobile IP.