As per Relevance of the word february, we have this rfc below:
Network Working Group M.
Request for Comments: 2507 Lulea University of Technology/
Category: Standards Track B.
Lulea University of Technology/Telia Research
S.
Lulea University of Technology/
February 1999
IP Header
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document describes how to compress multiple IP headers and
and UDP headers per hop over point to point links. The methods can
applied to of IPv6 base and extension headers, IPv4 headers, TCP
UDP headers, and encapsulated IPv6 and IPv4 headers
Headers of typical UDP or TCP packets can be compressed down to 4-7
octets including the 2 octet UDP or TCP checksum. This
removes the negative impact of large IP headers and allows
use of bandwidth on low and medium speed links
The compression algorithms are specifically designed to work
over links with nontrivial packet-loss rates. Several wireless
modem technologies result in such links
TABLE OF
1. Introduction..............................................3
2. Terminology...............................................5
3. Compression method........................................7
3.1. Packet types.......................................8
3.2. Lost packets in TCP packet streams.................9
3.3. Lost packets in UDP and non-TCP packet streams....10
4. Grouping packets into packet streams.....................14
Degermark, et. al. Standards Track [Page 1]
RFC 2507 IP Header Compression February 1999
4.1. Guidelines for grouping packets...................15
5. Size Issues..............................................16
5.1. Context identifiers...............................16
5.2. Size of the context...............................17
5.3. Size of full headers..............................18
5.3.1. Length fields in full TCP headers............19
5.3.2. Length fields in full non-TCP headers........19
6. Compressed Header Formats................................20
7. Compression of subheaders................................22
7.1. IPv6 Header.......................................24
7.2. IPv6 Extension Headers............................25
7.3. Options...........................................25
7.4. Hop-by-hop Options Header.........................26
7.5. Routing Header....................................26
7.6. Fragment Header...................................27
7.7. Destination Options Header........................28
7.8. No Next Header....................................29
7.9. Authentication Header.............................29
7.10. Encapsulating Security Payload Header.............29
7.11. UDP Header........................................30
7.12. TCP Header........................................30
7.13. IPv4 Header.......................................33
7.14 Minimal Encapsulation header......................34
8. Changing context identifiers.............................35
9. Rules for dropping or temporarily storing packets........35
10. Low-loss header compression for TCP .....................36
10.1. The "twice" algorithm............................37
10.2. Header Requests..................................37
11. Links that reorder packets...............................38
11.1. Reordering in non-TCP packet streams.............39
11.2. Reordering in TCP packet streams.................39
12. Hooks for additional header compression..................40
13. Demultiplexing...........................................41
14. Configuration Parameters.................................42
15. Implementation Status....................................43
16. Acknowledgments..........................................44
17. Security Considerations..................................44
18. Authors' Addresses.......................................45
19. References...............................................46
20. Full Copyright Statement.................................47
Degermark, et. al. Standards Track [Page 2]
RFC 2507 IP Header Compression February 1999
1.
There are several reasons to do header compression on low-
medium-speed links. Header compression
* Improve interactive response
For very low-speed links, echoing of characters may take
than 100-200 ms because of the time required to transmit
headers. 100-200 ms is the maximum time people can
without feeling that the system is sluggish
* Allow using small packets for bulk data with good line
This is important when interactive (for example Telnet) and
traffic (for example FTP) is mixed because the bulk data should
carried in small packets to decrease the waiting time when
packet with interactive data is caught behind a bulk data packet
Using small packet sizes for the FTP traffic in this case is
global solution to a local problem. It will increase the load
the network as it has to deal with many small packets. A
solution might be to locally fragment the large packets over
slow link
* Allow using small packets for delay sensitive low data-rate
For such applications, for example voice, the time to fill
packet with data is significant if packets are large. To get
end-to-end delay small packets are preferred. Without
compression, the smallest possible IPv6/UDP headers (48 octets
consume 19.2 kbit/s with a packet rate of 50 packets/s. 50
packets/s is equivalent to having 20 ms worth of voice samples
each packet. IPv4/UDP headers consumes 11.2 kbit/s at 50
packets/s. Tunneling or routing headers, for example to
mobility, will increase the bandwidth consumed by headers by 10-20
kbit/s. This should be compared with the bandwidth required
the actual sound samples, for example 13 kbit/s with GSM encoding
Header compression can reduce the bandwidth needed for
significantly, in the example to about 1.7 kbit/s. This
higher quality voice transmission over 14.4 and 28.8 kbit/
modems
* Decrease header overhead
A common size of TCP segments for bulk transfers over medium-
links is 512 octets today. When TCP segments are tunneled,
example because Mobile IP is used, the IPv6/IPv6/TCP header is 100
Degermark, et. al. Standards Track [Page 3]
RFC 2507 IP Header Compression February 1999
octets. Header compression will decrease the header overhead
IPv6/TCP from 19.5 per cent to less than 1 per cent, and
tunneled IPv4/TCP from 11.7 to less than 1 per cent. This is
significant gain for line-speeds as high as a few Mbit/s
The IPv6 specification prescribes path MTU discovery, so with IPv
bulk TCP transfers should use segments larger than 512 octets
possible. Still, with 1400 octet segments (RFC 894
encapsulation allows 1500 octet payloads, of which 100 octets
used for IP headers), header compression reduces IPv6
overhead from 7.1% to 0.4%.
* Reduce packet loss rate over lossy links
Because fewer bits are sent per packet, the packet loss rate
be lower for a given bit-error rate. This results in
throughput for TCP as the sending window can open up more
losses, and in fewer lost packets for UDP
The mechanisms described here are intended for a point-to-point link
However, care has been taken to allow extensions for multi-
links and multicast
Headers that can be compressed include TCP, UDP, IPv4, and IPv6
and extension headers. For TCP packets, the mechanisms of
Jacobson [RFC-1144] are used to recover from loss. Two
mechanisms that increase the efficiency of VJ header compression
lossy links are also described. For non-TCP packets,
slow-start and periodic header refreshes allow minimal periods
packet discard after loss of a header that changes the context.
are hooks for adding header compression schemes on top of UDP,
example compression of RTP headers
Header compression relies on many fields being constant or
seldomly in consecutive packets belonging to the same packet stream
Fields that do not change between packets need not be transmitted
all. Fields that change often with small and/or predictable values
e.g., TCP sequence numbers, can be encoded incrementally so that
number of bits needed for these fields decrease significantly.
fields that change often and randomly, e.g., checksums
authentication data, need to be transmitted in every header
The general principle of header compression is to occasionally send
packet with a full header; subsequent compressed headers refer to
context established by the full header and may contain
changes to the context
Degermark, et. al. Standards Track [Page 4]
RFC 2507 IP Header Compression February 1999
This header compression scheme does not require that all packets
the same stream passes over the compressed link. However, for
streams the difference between subsequent headers can become
irregular and the compression rate can decrease. Neither is
required that corresponding TCP data and acknowledgment
traverse the link in opposite directions
This header compression scheme is useful on first-hop or last-
links as well as links in the middle of the network. When many
streams (several hundred) traverse the link, a phenomenon that
be called CID thrashing could occur, where headers seldom can
matched with an existing context and have to be sent uncompressed
as full headers. It is up to an implementation to use techniques
as hysteresis to ensure that the packet streams that give the
compression rates keep their context. Such techniques are
likely to be needed in the middle of the network
2.
This section explains some terms used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.
An IPv6 base header, an IPv6 extension header, an IPv4 header,
UDP header, or a TCP header
A chain of subheaders
The act of reducing the size of a header by removing header
or reducing the size of header fields. This is done in a way
that a decompressor can reconstruct the header if its
state is identical to the context state used when compressing
header
The act of reconstructing a compressed header
Degermark, et. al. Standards Track [Page 5]
RFC 2507 IP Header Compression February 1999
Context identifier (CID
A small unique number identifying the context that should be
to decompress a compressed header. Carried in full headers
compressed headers
The state which the compressor uses to compress a header and
decompressor uses to decompress a header. The context is
uncompressed version of the last header sent (compressor)
received (decompressor) over the link, except for fields in
header that are included "as-is" in compressed headers or can
inferred from, e.g., the size of the link-level frame
The context for a packet stream is associated with a
identifier. The context for non-TCP packet streams is
associated with a generation
For non-TCP packet streams, each new version of the context for
given CID is associated with a generation: a small number that
incremented whenever the context associated with that CID changes
Carried by full and compressed non-TCP headers
Packet
A sequence of packets whose headers are similar and share context
For example, headers in a TCP packet stream have the same
and final destination address, and the same port numbers in
TCP header. Similarly, headers in a UDP packet stream have
same source and destination address, and the same port numbers
the UDP header
Full header (header refresh
An uncompressed header that updates or refreshes the context for
packet stream. It carries a CID that will be used to identify
context
Full headers for non-TCP packet streams also carry the
of the context they update or refresh
Regular
A normal, uncompressed, header. Does not carry CID or
association
Degermark, et. al. Standards Track [Page 6]
RFC 2507 IP Header Compression February 1999
Incorrect
When a compressed and then decompressed header is different
the uncompressed header. Usually due to mismatching
between the compressor and decompressor or bit errors
transmission of the compressed header
Differential
A compression technique where the compressed value of a
field is the difference between the current value of the field
the value of the same field in the previous header belonging
the same packet stream. A decompressor can thus obtain the
of the field by adding the value in the compressed header to
context. This technique is used for TCP streams but not for non
TCP streams
3. Compression
Much of the header information stays the same over the life-time of
packet stream. For non-TCP packet streams almost all fields of
headers are constant. For TCP many fields are constant and
change with small and predictable values
To initiate compression of the headers of a packet stream, a
header carrying a context identifier, CID, is transmitted over
link. The compressor and decompressor store most fields of this
header as context. The context consists of the fields of the
whose values are constant and thus need not be sent over the link
all, or change little between consecutive headers so that it
fewer bits to send the difference from the previous value compared
sending the absolute value
Any change in fields that are expected to be constant in a
stream will cause the compressor to send a full header again
update the context at the decompressor. As long as the context is
same at compressor and decompressor, headers can be decompressed
be exactly as they were before compression. However, if a full
or compressed header is lost during transmission, the context of
decompressor may become obsolete as it is not updated properly
Compressed headers will then be decompressed incorrectly
IPv6 is not meant to be used over links that can deliver
significant fraction of damaged packets to the IPv6 module.
means that links must have a very low bit-error rate or that link
level frames must be protected by strong checksums, forward
correction or something of that nature. Header compression
not be used for IPv4 without strong link-level checksums.
Degermark, et. al. Standards Track [Page 7]
RFC 2507 IP Header Compression February 1999
frames will thus be discarded by the link layer. The link
implementation might indicate to the header compression module that
frame was damaged, but it cannot say what packet stream it
to as it might be the CID that is damaged. Moreover, frames
disappear without the link layer implementation's knowledge,
example if the link is a multi-hop link where frames can be
due to congestion at each hop. The kind of link errors that a
compression module should deal with and protect against will thus
packet loss
So a header compression scheme needs mechanisms to update the
at the decompressor and to detect or avoid incorrect decompression
These mechanisms are very different for TCP and non-TCP streams,
are described in sections 3.2 and 3.3.
The compression mechanisms in this document assume that packets
not reordered between the compressor and decompressor. If the
does reorder, section 11 describes mechanisms for ordering
packets before decompression. It is also assumed that the link-
implementation can provide the length of packets, and that there
no padding in UDP packets or tunneled packets
3.1. Packet
This compression method uses four packet types in addition to
IPv4 and IPv6 packet types. The combination of link-level
type and the value of the first four bits of the packet
determines the packet type. Details on how these packet types
represented are in section 13.
FULL_HEADER - indicates a packet with an uncompressed header
including a CID and, if not a TCP packet, a generation.
establishes or refreshes the context for the packet
identified by the CID
COMPRESSED_NON_TCP - indicates a non-TCP packet with a
header. The compressed header consists of a CID identifying
context to use for decompression, a generation to detect
inconsistent context and the randomly changing fields of
header
COMPRESSED_TCP - indicates a packet with a compressed TCP header
containing a CID, a flag octet indentifying what fields
changed, and the changed fields encoded as the difference
the previous value
Degermark, et. al. Standards Track [Page 8]
RFC 2507 IP Header Compression February 1999
COMPRESSED_TCP_NODELTA - indicates a packet with a compressed
header where all fields that are normally sent as the
to the previous value are instead sent as-is. This packet
is only sent as the response to a header request from
decompressor. It must not be sent as the result of
retransmission
In addition to the packet types used for compression, regular IPv
and IPv6 packets are used whenever a compressor decides to
compress a packet. An additional packet type may be used to speed
repair of TCP streams over links where the decompressor can
packets to the compressor
CONTEXT_STATE - indicates a special packet sent from
decompressor to the compressor to communicate a list of (TCP
CIDs for which synchronization has been lost. This packet is
sent over a single link so it requires no IP header. The
is shown in section 10.2.
3.2. Lost packets in TCP packet
Since TCP headers are compressed using the difference from
previous TCP header, loss of a packet with a compressed or
header will cause subsequent compressed headers to be
incorrectly because the context used for decompression was
incremented properly
Loss of a compressed TCP header will cause the TCP sequence
of subsequently decompressed TCP headers to be off by k, where k
the size of the lost segment. Such incorrectly decompressed
headers will be discarded by the TCP receiver as the TCP
reliably catches "off-by-k" errors in the sequence numbers
plausible k
TCP's repair mechanisms will eventually retransmit the
segment and the compressor peeks into the TCP headers to detect
TCP retransmits. When this happens, the compressor sends a
header on the assumption that the retransmission was due
mismatching compression state at the decompressor. [RFC-1144] has
good explanation of this mechanism
The mechanisms of section 10 should be used to speed up the repair
the context. This is important over medium speed links with
packet loss rates, for example wireless. Losing a timeout's worth
packets due to inconsistent context after each packet lost over
link is not acceptable, especially when the TCP connection is
the wide area
Degermark, et. al. Standards Track [Page 9]
RFC 2507 IP Header Compression February 1999
3.3. Lost packets in UDP and other non-TCP packet
Incorrectly decompressed headers of UDP packets and other non-
packets are not so well-protected by checksums as TCP packets.
are no sequence numbers that become "off-by-k" and
guarantees a failed checksum as there are for TCP. The UDP
only covers payload, UDP header, and pseudo header. The
header includes the source and destination addresses, the
protocol type and the length of the transport packet. Except
those fields, large parts of the IPv6 header are not covered by
UDP checksum. Moreover, other non-TCP headers lack
altogether, for example fragments
In order to safely avoid incorrect decompression of non-TCP headers
each version of the context for non-TCP packet streams is
by a generation, a small number that is carried by the full
that establish and refresh the context. Compressed headers carry
generation value of the context that were used to compress them
When a decompressor sees that a compressed header carries
generation value other than the generation of its context for
packet stream, the context is not up to date and the packet must
discarded or stored until a full header establishes correct context
Differential coding is not used for non-TCP streams, so
non-TCP headers do not change the context. Thus, loss of
compressed header does not invalidate subsequent packets
compressed headers. Moreover, the generation changes only when
context of a full header is different from the context of
previous full header. This means that losing a full header will
the context of the decompressor obsolete only when the full
would actually have changed the context
The generation field is 6 bits long so the generation value
itself after 64 changes to the context. To avoid
decompression after error bursts or other temporary disruptions,
compressor must not reuse the same generation value after a
time than MIN_WRAP seconds. A decompressor which has
disconnected MIN_WRAP seconds or more must wait for the next
header before decompressing. A compressor must wait at least MIN_
seconds after booting before compressing non-TCP headers. Instead
reusing a generation value too soon, a compressor may switch
another CID or send regular headers until MIN_WRAP seconds
passed. The value of MIN_WRAP is found in section 14.
Degermark, et. al. Standards Track [Page 10]
RFC 2507 IP Header Compression February 1999
3.3.1. Compression Slow-
To allow the decompressor to recover quickly from loss of a
header that would have changed the context, full headers are
periodically with an exponentially increasing period after a
in the context. This technique avoids an exchange of messages
compressor and decompressor used by other compression schemes,
as in [RFC-1553]. Such exchanges can be costly for wireless
as more power is consumed by the transmitter and delay can
introduced by switching between sending and receiving. Moreover
techniques that require an exchange of messages cannot be used
simplex links, such as direct-broadcast satellite channels or
TV systems, and are hard to adapt to multicast over multi-
links
|.|..|....|........|................|..............................
^
Change Sent packets: | with full header, . with compressed
The picture shows how packets are sent after change. The
keeps a variable for each non-TCP packet stream, F_PERIOD, that
track of how many compressed headers may be sent between
headers. When the headers of a non-TCP packet stream change so
its context changes, a full header is sent and F_PERIOD is set
one. After sending F_PERIOD compressed headers, a full header
sent. F_PERIOD is doubled each time a full header is sent
compression slow-start
3.3.2. Periodic Header
To avoid losing too many packets if a receiver has lost its context
there is an upper limit, F_MAX_PERIOD, on the number of non-
packets with compressed headers that may be sent between
refreshes. If a packet is to be sent and F_MAX_PERIOD
headers have been sent since the last full header for this
stream was sent, a full header must be sent
To avoid long periods of disconnection for low data rate
streams, there is also an upper bound, F_MAX_TIME, on the
between full headers in a non-TCP packet stream. If a packet is to
sent and more than F_MAX_TIME seconds have passed since the last
header was sent for this packet stream, a full header must be sent
The values of F_MAX_PERIOD and F_MAX_TIME are found in section 14.
Degermark, et. al. Standards Track [Page 11]
RFC 2507 IP Header Compression February 1999
3.3.3. Rules for sending Full
The following pseudo code can be used by the compressor to
when to send a full header for a non-TCP packet stream. The
maintains two variables
C_NUM -- a count of the number of compressed headers
since the last full header was sent
F_LAST -- the time of sending the last full header
and uses the
current_time() return the current
min(a,b) return the smallest of a and
the procedures send_full_header(), increment_generation_value(),
and send_compressed_header()
do the obvious thing
if ( )
C_NUM := 0;
F_LAST := current_time();
F_PERIOD := 1;
increment_generation_value();
send_full_header();
elseif ( C_NUM >= F_PERIOD )
C_NUM := 0;
F_LAST := current_time();
F_PERIOD := min(2 * F_PERIOD, F_MAX_PERIOD);
send_full_header();
elseif ( current_time() > F_LAST + F_MAX_TIME )
C_NUM := 0;
F_LAST := current_time();
send_full_header();
C_NUM := C_NUM + 1
send_compressed_header();
Degermark, et. al. Standards Track [Page 12]
RFC 2507 IP Header Compression February 1999
3.3.4. Cost of sending Header
If every f'th packet carries a full header, H is the size of a
header, and C is the size of a compressed header, the average
size
(H-C)/f +
For f > 1, the average header size is (H-C)/f larger than
compressed header
In a diagram where the average header size is plotted for various
values, there is a distinct knee in the curve, i.e., there is a
beyond which further increasing f gives diminishing returns
F_MAX_PERIOD should be chosen to be a frequency well to the right
the knee of the curve. For typical sizes of H and C, say 48
for the full header (IPv6/UDP) and 4 octets for the
header, setting F_MAX_PERIOD > 44 means that full headers
contribute less than an octet to the average header size. With
four-address routing header, F_MAX_PERIOD > 115 will have the
effect
The default F_MAX_PERIOD value of 256 (section 14) puts the
header frequency well to the right of the knee and means that
headers will typically contribute considerably less than an octet
the average header size. For H = 48 and C = 4, full
contribute about 1.4 bits to the average header size after
the steady-state header refresh frequency determined by the
F_MAX_PERIOD. 1.4 bits is a very small overhead
After a change in the context, the exponential backoff scheme
initially send full headers frequently. The default F_MAX_
will be reached after nine full headers and 255 compressed
have been sent. This is equivalent to a little over 5 seconds for
typical voice stream with 20 ms worth of voice samples per packet
During the whole backoff period, full headers contribute 1.5
to the average header size when H = 48 and C = 4. For 20 ms
samples, it takes less than 1.3 seconds until full headers
less than one octet to the average header size, and during
initial 1.3 seconds full headers add less than 4 octets to
average header size. The cost of the exponential backoff is
great and as the headers of non-TCP packet streams are expected
change seldomly, it will be amortized over a long time
Degermark, et. al. Standards Track [Page 13]
RFC 2507 IP Header Compression February 1999
The cost of header refreshes in terms of bandwidth are higher
similar costs for hard state schemes like [RFC-1553] where
headers must be acknowledged by the decompressor before
headers may be sent. Such schemes typically send one full header
a few control messages when the context changes. Hard state
require more types of protocol messages and an exchange of
is necessary. Hard state schemes also need to deal explicitly
various error conditions that soft state handles automatically,
instance the case of one party disappearing unexpectedly, a
situation on wireless links where mobiles may go out of range of
base station
The major advantage of the soft state scheme is that no
are needed between compressor and decompressor, so the scheme can
used over simplex links. The costs in terms of bandwidth are
than for hard state schemes, but the simplicity of the decompressor
the simplicity of the protocol, and the lack of handshakes
compressor and decompressor justifies this small cost. Moreover,
state schemes are more easily extended to multicast over multi-
links, for example radio links
4. Grouping packets into packet
This section explains how packets MAY be grouped together into
streams for compression. To achieve the best compression rates
packets SHOULD be grouped together such that packets in the
packet stream have similar headers. If this grouping fails,
compression performance will be bad, since the compression
can rarely utilize the existing context for the packet stream
full headers must be sent frequently
Grouping is done by the compressor. A compressor may use
criterion it finds appropriate to group packets into packet streams
To determine what packet stream a packet belongs to, a compressor
a) examine the compressible chain of subheaders (see section 7),
b) examine the contents of an upper layer protocol header
follows the compressible chain of subheaders, for example
headers, DVMRP headers, or tunneled IPX headers
c) use information obtained from a resource manager, for example if
resource manager requests compression for a particular
stream and provides a way to identify packets belonging to
packet stream
Degermark, et. al. Standards Track [Page 14]
RFC 2507 IP Header Compression February 1999
d) use any other relevant information, for example if routes flap
the hop limit (TTL) field in a packet stream changes
between n and n+k, a compressor may choose to group the
into two different packet streams
A compressor is also free not to group packets into packet
for compression, letting some packets keep their regular headers
passing them through unmodified
As long as the rules for when to send full headers for a non-
packet stream are followed and subheaders are compressed as
in this document, the decompressor is able to reconstruct
compressed header correctly regardless of how packets are
into packet streams
4.1 Guidelines for grouping
In this section we give OPTIONAL guidelines for how a compressor
group packets into packet streams for compression
Defining
The defining fields of a header should be present and identical
all packets belonging to the same packet stream. These fields
marked DEF in section 7. The defining fields include the
label, source and destination addresses of IP headers,
destination address in routing headers, the next header
(for IPv6), the protocol field (IPv4), port numbers (UDP and TCP),
and the SPI in authentication and encryption headers
Fragmented
Fragmented and unfragmented packets should never be
together in the same packet stream. The Identification field
the Fragment header or IPv4 header should not be used to
the packet stream. If it was, the first fragment of a new
would cause a compression slow-start
No field after a Fragment Header, or an IPv4 header for
fragment, should be used for grouping purposes
Upper protocol
The first next header field identifying a header not described
section 7 should be used for identifying packet streams, i.e.,
packets with the same DEF fields and the same upper
should be grouped together
Degermark, et. al. Standards Track [Page 15]
RFC 2507 IP Header Compression February 1999
TTL field (Hop Limit field
A sophisticated implementation might monitor the TTL (Hop Limit
field and if it changes frequently use it as a DEF field. This
occur when there are frequent route flaps so that packets
different paths through the internet
Traffic Class field (IPv6), Type of Service field (IPv4)
It is possible that the Traffic Class field of the IPv6 header
the Type of Service of the IPv4 header will change
between packets with otherwise identical DEF fields.
sophisticated implementation should watch out for this and
prepared to use these fields as defining fields
When IP packets are tunneled they are encapsulated with an
IP header at the tunnel entry point and then sent to the
endpoint. To group such packets into packet streams, the
headers should also be examined to determine the packet stream.
this is not done, full headers will be sent each time the headers
the inner IP packet changes. So when a packet is tunneled,
identifying fields of the inner subheaders should be considered
addition to the identifying fields of the initial IP header
An implementation can use other fields for identification than
ones described here. If too many fields are used for identification
performance might suffer because more CIDs will be used and the
CIDs might be reused when new flows need CIDs. If too few fields
used for identification, performance might suffer because there
too frequent changes to the context
We stress that these guidelines are educated guesses. When IPv6
widely deployed and IPv6 traffic can be analyzed, we might find
other grouping algorithms perform better. We also stress that if
grouping fails, the result will be bad performance but not
decompression. The decompressor can do its task regardless of how
grouping algorithm works
5. Size
5.1. Context
Context identifiers can be 8 or 16 bits long. Their size is
relevant for finding the context. An 8-bit CID with value two and
16-bit CID with value two are equivalent
Degermark, et. al. Standards Track [Page 16]
RFC 2507 IP Header Compression February 1999
The CID spaces for TCP and non-TCP are separate, so a TCP CID and
non-TCP CID never identify the same context. Even if they have
same value. This doubles the available CID space while using the
number of bits for CIDs. It is always possible to tell whether
full or compressed header is for a TCP or non-TCP packet, so
mixups can occur
Non-TCP compressed headers encode the size of the CID using one
in the second octet of the compressed header. The 8-bit CID allows
minimum compressed header size of 2 octets for non-TCP packets,
CID uses the first octet and the size bit and the 6-bit
value fit in the second octet
For TCP the only available CID size is 8 bits as in [RFC-1144]. 8
bits is probably sufficient as TCP connections are always point-to
point
The 16 bit CID size may not be needed for point-to-point links; it
intended for use on multi-access links where a larger CID space
be needed for efficient selection of CIDs
The major difficulty with multi-access links is that
compressors share the CID space of a decompressor. CIDs can
longer be selected independently by the compressors as collisions
occur. This problem may be resolved by letting the
have a separate CID space for each compressor. Having separate
spaces requires that decompressors can identify which compressor
the compressed packet, perhaps by utilizing link-layer information
to who sent the link-layer frame. If such information is
available, all compressors on the multi-access link may
enumerated, automatically or otherwise, and supply their number
part of the CID. This latter method requires a large CID space
5.2. Size of the
The size of the context SHOULD be limited to simplify
of compressor and decompressor, and put a limit on their
requirements. However, there is no upper limit on the size of
IPv6 header as the chain of extension headers can be
long. This is a problem as the context is essentially a
header
The configurable parameter MAX_HEADER (see section 14) represents
maximum size of the context, expressed as the maximum sized
that can be stored as context. When a header is larger
MAX_HEADER, only part of it is stored as context. An
MUST NOT compress more than the initial MAX_HEADER octets of
header. An implementation MUST NOT partially compress a subheader
Degermark, et. al. Standards Track [Page 17]
RFC 2507 IP Header Compression February 1999
Thus, the part of the header that is stored as context and
compressed is the longest initial sequence of entire subheaders
is not larger than MAX_HEADER octets
5.3. Size of full
It is desirable to avoid increasing the size of packets with
headers beyond their original size, as their size may be
for the MTU of the link. Since we assume that the link
implementation provides the length of packets, we can use the
fields in full headers to pass the values of the CID and
generation to the decompressor
This requires that the link-layer must not add padding to
payload, at least not padding that can be delivered to
destination link user. It is also required that no extra padding
added after UDP data or in tunneled packets. This allows values
length fields to be calculated from the length of headers and
length of the link-layer frame
The generation requires one octet and the CID may require up to 2
octets. There are length fields of 2 octets in the IPv6 Base Header
the IPv4 header, and the UDP header
A full TCP header will thus have at least 2 octets available in
IP header to pass the 8 bit CID, which is sufficient. There will
more than two octets available if there is more than one IP header
[RFC-1144] uses the 8 bit Protocol field of the IPv4 header to
the CID. We cannot use the corresponding method as the sequence
IPv6 extension headers is not fixed and CID values are not
from the legal values of Next Header fields
An IPv6/UDP or IPv4/UDP packet will have 4 octets available to
the generation and the CID, so all CID sizes may be used.
or encrypted packet streams may have only 2 octets available to
the generation and CID. Thus, 8-bit CIDs may be the only CID
that can be used for such packet streams. When IPv6/IPv4
IPv4/IPv6 tunneling is used, there will be at least 4
available, and both CID sizes may be used
The generation value is passed in the higher order octet of the
length field in the full header. When only one length field
available, the 8-bit CID is passed in the low order octet. When
length fields are available, the lowest two octets of the CID
passed in the second length field and the low order octet of
first length field carries the highest octet of the CID
Degermark, et. al. Standards Track [Page 18]
RFC 2507 IP Header Compression February 1999
5.3.1. Use of length fields in full TCP
Use of first length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length field | LSB of pkt nr | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Use of second length field if available
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | MSB of pkt nr | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pkt nr is short for packet sequence number, described in
11.2.
5.3.2. Use of length fields in full non-TCP
Full non-TCP headers with 8-bit CID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |0|D| Generation| CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field (if avail.) | 0 | Data (if D=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Full non-TCP headers with 16-bit CID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |1|D| Generation| Data (if D=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first bit in the first length field indicates the length of
CID. The Data field is zero if D is zero. The use of the D bit
Data field is explained in section 12.
Degermark, et. al. Standards Track [Page 19]
RFC 2507 IP Header Compression February 1999
6. Compressed Header
This section uses some terminology (DELTA, RANDOM) defined in
7.
a) COMPRESSED_TCP format (similar to [RFC 1144]):
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
|R O I P S A W U
+-+-+-+-+-+-+-+-+
| |
+ TCP Checksum +
| |
+-+-+-+-+-+-+-+-+
| RANDOM fields, if any (see section 7) (implied
- - - - - - - -
| R-octet | (if R=1)
- - - - - - - -
| Urgent Pointer Value (if U=1)
- - - - - - - -
| Window Delta (if W=1)
- - - - - - - -
| Acknowledgment Number Delta (if A=1)
- - - - - - - -
| Sequence Number Delta (if S=1)
- - - - - - - -
| IPv4 Identification Delta (if I=1)
- - - - - - - -
| Options (if O=1)
- - - - - - - -
The latter flags in the second octet (IPSAWU) have the same
as in [RFC-1144], regardless of whether the TCP segments are
by IPv6 or IPv4. The C bit has been eliminated because the CID
always present. The context associated with the CID keeps track
the IP version and what RANDOM fields are present. The order
delta fields specified here is exactly as in [RFC-1144].
implementation will typically scan the context from the beginning
insert the RANDOM fields in order. The RANDOM fields are thus
before the DELTA fields of the TCP header in the same order as
occur in the original uncompressed header
Degermark, et. al. Standards Track [Page 20]
RFC 2507 IP Header Compression February 1999
The I flag is zero unless an IPv4 header immediately precedes the
header. The combined IPv4/TCP header is then compressed as a unit
described in [RFC-1144]. Identification fields in IPv4 headers
are not immediately followed by a TCP header are RANDOM
If the O flag is set, the Options of the TCP header were not the
as in the previous header. The entire Option field are placed last
the compressed TCP header
If the R flag is set, there were differences between the context
the Reserved field (6 bits) in the TCP header or bit 6 or 7 of
TOS octet (Traffic Class octet) in a IPv4 header (IPv6 header)
immediately precedes the TCP header. An octet with the actual
of the Reserved field and bit 6 and 7 of the TOS or Traffic
field is then placed immediately after the RANDOM fields. Bits 0-5
of the passed octet is the actual value of the Reserved field,
bits 6 and 7 are the actual values of bits 6 and 7 in the TOS
Traffic Class field. If there is no preceding IP header, bits 6 and 7
are 0. The octet passed with the R flag MUST NOT update the context
NOTE: The R-octet does not update the context because if it did,
nTCP checksum would not guard the receiving TCP from
decompressed headers. Bits 6 and 7 of the TOS octet or Traffic
octet is expected to change frequently due to Explicit
Notification
See section 7.12 and [RFC-1144] for further information on how
compress TCP headers
b) COMPRESSED_TCP_NODELTA header
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
| RANDOM fields, if any (see section 7) (implied
+-+-+-+-+-+-+-+-+
| Whole TCP header except for Port
+-+-+-+-+-+-+-+-+
Degermark, et. al. Standards Track [Page 21]
RFC 2507 IP Header Compression February 1999
c) Compressed non-TCP header, 8 bit CID
0 7
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
|0|D| Generation
+-+-+-+-+-+-+-+-+
| data | (if D=1)
- - - - - - - -
| RANDOM fields, if any (section 7) (implied
- - - - - - - -
d) Compressed non-TCP header, 16 bit CID
0 7
+-+-+-+-+-+-+-+-+
| msb of CID |
+-+-+-+-+-+-+-+-+
|1|D| Generation
+-+-+-+-+-+-+-+-+
| lsb of CID |
+-+-+-+-+-+-+-+-+
| data | (if D=1)
- - - - - - - -
| RANDOM fields, if any (section 7) (implied
- - - - - - - -
The generation, CID and optional one octet data are followed
relevant RANDOM fields (see section 7) as implied by the
state, placed in the same order as they occur in the
uncompressed header, followed by the payload
7. Compression of
This section gives rules for how the compressible chain of
is compressed. These rules MUST be followed. Subheaders that may
compressed include IPv6 base and extension headers, TCP headers,
headers, and IPv4 headers. The compressible chain of
extends from the beginning of the
a) up to but not including the first header that is not an IPv
header, an IPv6 base or extension header, a TCP header, or a
header,
b) up to and including the first TCP header, UDP header,
Header, Encapsulating Security Payload Header, or IPv4 header
a fragment
Degermark, et. al. Standards Track [Page 22]
RFC 2507 IP Header Compression February 1999
whichever gives the shorter chain. For example, rules a) and b)
fit a chain of subheaders that contain a Fragment Header and ends
a tunneled IPX packet. Since rule b) gives a shorter chain,
compressible chain of subheaders stops at the Fragment Header
The following subsections are a systematic classification of how
fields in subheaders are expected to change
NOCHANGE The field is not expected to change. Any change
that a full header MUST be sent to update the context
DELTA The field may change often but usually the
from the field in the previous header is small, so
it is cheaper to send the change from the previous
rather than the current value. This type of
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
other values, for example the size of the frame
the packet, and thus must not be included in
compressed header
The classification implies how a compressed header is constructed.
field that is NOCHANGE or INFERRED is present in a compressed header
A compressor obtains the values of NOCHANGE fields from the
identified by the compression identifier, and obtains the values
INFERRED fields from the link-layer implementation, e.g., from
size of the link-layer frame, or from other fields, e.g.,
recalculating the IPv4 header checksum. DELTA fields are encoded
the difference to the value in the previous packet in the same
stream. The decompressor must update the context by adding the
in the compressed header to the value in its context. The result
the proper value of the field. RANDOM fields must be sent "as-is"
the compressed header. RANDOM fields must occur in the same order
the compressed header as they occur in the full header
Fields that may optionally be used to identify what packet stream
packet belongs to according to section 4.1 are marked with the
DEF. To a compressor using the optional guidelines from section 4.1,
any difference in corresponding DEF fields between two
implies that they belong to different packet streams. Moreover, if
DEF field is present in one packet but not in another, the
belong to different packet streams
Degermark, et. al. Standards Track [Page 23]
RFC 2507 IP Header Compression February 1999
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
Next Header
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
the length value of the encapsulating header. If not, the
chain MUST NOT be compressed
NOTE: If this the IP header closest to a TCP header, bit 7 of
Traffic Class field can be passed using the R-flag of the
TCP header. See section 6 a).
This classification implies that the entire IPv6 base header will
compressed away
Degermark, et. al. Standards Track [Page 24]
RFC 2507 IP Header Compression February 1999
7.2. IPv6 Extension Headers [IPv6, section 4]
What extension headers are present and the relative order of them
not expected to change in a packet stream. Whenever there is
change, a full packet header must be sent. All Next Header fields
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
headers are encoded with TLV "options" (see [IPv6]):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type and Opt Data Len fields are assumed to be fixed for
given packet stream, so they are classified as NOCHANGE. The
data is RANDOM unless specified otherwise below
Pad1
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Entire option is NOCHANGE
PadN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
All fields are NOCHANGE
Degermark, et. al. Standards Track [Page 25]
RFC 2507 IP Header Compression February 1999
7.4. Hop-by-Hop Options Header [IPv6, section 4.3]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
Hdr Ext Len
Options TLV coded values and padding
Classified according to 7.3 above,
being a Jumbo Payload option (see below).
Jumbo Payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Jumbo Payload Option since the relative header overhead
negligible. Moreover, it is usually a bad idea to send
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
Degermark, et. al. Standards Track [Page 26]
RFC 2507 IP Header Compression February 1999
If the Routing Type is not recognized, it is impossible to
the final Destination Address unless the Segments Left field has
value zero, in which case the Destination Address is the
Destination Address in the basic IPv6 header
In the Type 0 Routing Header, the last address is DEF if (
Left > 0).
Routing Headers are compressed away completely. This is a big win
the maximum size of the Routing Header is 392 octets. Moreover,
0 Routing Headers with one address, size 24 octets, are used
Mobile IP
7.6. Fragment Header [IPv6, section 4.5]
The first fragment of a packet has Fragment Offset = 0 and the
of subheaders extends beyond its Fragment Header. If a fragment
not the first (Fragment Offset not 0), there are no
subheaders (unless the chain of subheaders in the first
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,
compressor cannot rely on seeing the first fragment before
fragments. This implies that information in subheaders following
Fragment Header of the first fragment cannot be examined to
the proper packet stream for other fragments
It is possible to design compression schemes that can
subheaders after the Fragment Header, at least in the first fragment
but to avoid complicating the rules for sending full headers and
rules for compression and decompression, the chain of subheaders
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
Reserved
Res
M flag
Fragment Offset
Identification
Degermark, et. al. Standards Track [Page 27]
RFC 2507 IP Header Compression February 1999
This classification implies that a Fragment Header is compressed
to 6 octets. The minimum IPv6 MTU is 1280 octets so most
will be at least 1280 octets. Since the 6 octet overhead of
compressed fragment header is amortized over a fairly large packet
the additional complexity of more sophisticated compression
is not justifiable
NOTE: The Identification field is RANDOM instead of
to avoid one compression slow-start per original packet
Grouping of fragments according to the optional guidelines
section4.1:
Fragments and unfragmented packets should not be
together
Port numbers cannot be used to identify the packet stream
port numbers are not present in every fragment. To adhere to
uniqueness rules for the Identification value, a
packet stream is identified by the combination of Source
and (final) Destination Address
NOTE: The Identification value is NOT used to identify
packet stream. This avoids using a new CID for each packet
saves the cost of the associated compression slow-start.
expect that the unfragmentable part of the headers will
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
Hdr Ext Len
Options TLV coded values and padding
Compressed according to 7.3 above
The only Destination Options defined in [IPv6] are the
options
Degermark, et. al. Standards Track [Page 28]
RFC 2507 IP Header Compression February 1999
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
Length
Reserved
SPI NOCHANGE (DEF
Authentication Data
[RFC-1828] specifies how to do authentication with keyed MD5,
authentication method all IPv6 implementations must support.
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
encrypted. Thus, no further header compression is possible
subsequent headers as encryption is typically already performed
the compressor sees the packet
However, when the ESP Header is used in tunnel mode an entire
packet is encrypted, and the headers of that packet MAY be
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
length to the decompressor, as if it came from the link-layer.
mechanisms for dealing with reordering described in section 11
also be used, as packets can be reordered in a tunnel
Degermark, et. al. Standards Track [Page 29]
RFC 2507 IP Header Compression February 1999
+---------------+---------------+---------------+---------------+
| Security Association Identifier (SPI), 32 bits |
+===============+===============+===============+===============+
| Opaque Transform Data, variable length |
+---------------+---------------+---------------+---------------+
SPI NOCHANGE (DEF
Opaque Transform Data
Everything after the SPI is encrypted and is not compressed
7.11. UDP
The UDP header is described in [RFC-768].
The Next Header field (IPv6) or Protocol field (IPv4) in
preceding subheader is DEF
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port NOCHANGE (DEF
Destination Port NOCHANGE (DEF
Length
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)
preceding subheaders, i.e, there must not be any padding after
UDP payload that is covered by the IP Length
The UDP header is typically compressed down to 2 octets, the
checksum. When the UDP checksum is zero (which it cannot be
IPv6), it is likely to be so for all packets in the flow and
defined to be NOCHANGE. This saves 2 octets in the compressed header
7.12. TCP
The TCP header is described in [RFC-793].
The Next Header field (IPv6) or Protocol field (IPv4) in
preceding subheader is DEF
Degermark, et. al. Standards Track [Page 30]
RFC 2507 IP Header Compression February 1999
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Source Port NOCHANGE (DEF
Destination Port NOCHANGE (DEF
Sequence Number
Acknowledgment Number
Offset
Reserved DELTA (if differs from context
set R-flag in flag
and send absolute
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
and send difference
Checksum
Urgent Pointer DELTA (if Urg is set,
absolute value
Options, Padding DELTA (if change in Options
set O-flag and
whole Options, Padding
A packet with a TCP header compressed according to the above must
indicated to be of type COMPRESSED_TCP. The compressed header
described in section 6.
Degermark, et. al. Standards Track [Page 31]
RFC 2507 IP Header Compression February 1999
This method is essentially the differential encoding techniques
Jacobson, described in [RFC-1144], the differences being the
of the compressed TCP header fields (see section 6), the use of
O-flag, the use of the R-flag, and elimination of the C-flag.
O-flag allows compression of the TCP header when the Timestamp
is used and the Options fields changes with each header
DELTA values (except for Reserved field and Options, Padding) MUST
coded as in [RFC-1144]. A Reserved field value passed with the R-
MUST NOT update the context at compressor or decompressor
7.12.2. Without differential
Source Port NOCHANGE (DEF
Destination Port NOCHANGE (DEF
(all the rest)
The Identification field in a preceding IPv4 header is RANDOM
A packet with a TCP header compressed according to the above must
indicated to be of type COMPRESSED_TCP_NODELTA. It uses the same
space as COMPRESSED_TCP packets, and the header MUST be saved
context. The compressed header is described in section 6.
This packet type can be sent as the response to a header
instead of sending a full header, can be used over links that
packets, and can be sent instead of a full header when there
changes that cannot be represented by a compressed header.
sophisticated compressor can switch to sending
COMPRESSED_TCP_NODELTA headers when the packet loss frequency is high
Degermark, et. al. Standards Track [Page 32]
RFC 2507 IP Header Compression February 1999
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
a) If the IPv4 header is not for a fragment (MF flag is not set
Fragment Offset is zero) and there are no options (IHL is 5),
is classified as
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
or encapsulating IP header
Identification DELTA/ (If the Protocol field has
(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
Header Checksum INFERRED (calculated from other fields
Source Address NOCHANGE (DEF
Destination Address NOCHANGE (DEF
Op