summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2507.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc2507.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc2507.txt')
-rw-r--r--doc/rfc/rfc2507.txt2635
1 files changed, 2635 insertions, 0 deletions
diff --git a/doc/rfc/rfc2507.txt b/doc/rfc/rfc2507.txt
new file mode 100644
index 0000000..72a93bf
--- /dev/null
+++ b/doc/rfc/rfc2507.txt
@@ -0,0 +1,2635 @@
+
+
+
+
+
+
+Network Working Group M. Degermark
+Request for Comments: 2507 Lulea University of Technology/SICS
+Category: Standards Track B. Nordgren
+ Lulea University of Technology/Telia Research AB
+ S. Pink
+ Lulea University of Technology/SICS
+ February 1999
+
+
+ IP Header Compression
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+Abstract
+
+ This document describes how to compress multiple IP headers and TCP
+ and UDP headers per hop over point to point links. The methods can be
+ applied to of IPv6 base and extension headers, IPv4 headers, TCP and
+ 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 largely
+ removes the negative impact of large IP headers and allows efficient
+ use of bandwidth on low and medium speed links.
+
+ The compression algorithms are specifically designed to work well
+ over links with nontrivial packet-loss rates. Several wireless and
+ modem technologies result in such links.
+
+TABLE OF CONTENTS
+
+ 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. Introduction
+
+ There are several reasons to do header compression on low- or
+ medium-speed links. Header compression can
+
+ * Improve interactive response time
+
+ For very low-speed links, echoing of characters may take longer
+ than 100-200 ms because of the time required to transmit large
+ headers. 100-200 ms is the maximum time people can tolerate
+ without feeling that the system is sluggish.
+
+ * Allow using small packets for bulk data with good line efficiency
+
+ This is important when interactive (for example Telnet) and bulk
+ traffic (for example FTP) is mixed because the bulk data should be
+ carried in small packets to decrease the waiting time when a
+ packet with interactive data is caught behind a bulk data packet.
+
+ Using small packet sizes for the FTP traffic in this case is a
+ global solution to a local problem. It will increase the load on
+ the network as it has to deal with many small packets. A better
+ solution might be to locally fragment the large packets over the
+ slow link.
+
+ * Allow using small packets for delay sensitive low data-rate traffic
+
+ For such applications, for example voice, the time to fill a
+ packet with data is significant if packets are large. To get low
+ end-to-end delay small packets are preferred. Without header
+ 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 in
+ each packet. IPv4/UDP headers consumes 11.2 kbit/s at 50
+ packets/s. Tunneling or routing headers, for example to support
+ mobility, will increase the bandwidth consumed by headers by 10-20
+ kbit/s. This should be compared with the bandwidth required for
+ the actual sound samples, for example 13 kbit/s with GSM encoding.
+ Header compression can reduce the bandwidth needed for headers
+ significantly, in the example to about 1.7 kbit/s. This enables
+ higher quality voice transmission over 14.4 and 28.8 kbit/s
+ modems.
+
+ * Decrease header overhead.
+
+ A common size of TCP segments for bulk transfers over medium-speed
+ links is 512 octets today. When TCP segments are tunneled, for
+ 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 for
+ IPv6/TCP from 19.5 per cent to less than 1 per cent, and for
+ tunneled IPv4/TCP from 11.7 to less than 1 per cent. This is a
+ significant gain for line-speeds as high as a few Mbit/s.
+
+ The IPv6 specification prescribes path MTU discovery, so with IPv6
+ bulk TCP transfers should use segments larger than 512 octets when
+ possible. Still, with 1400 octet segments (RFC 894 Ethernet
+ encapsulation allows 1500 octet payloads, of which 100 octets are
+ used for IP headers), header compression reduces IPv6 header
+ 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 will
+ be lower for a given bit-error rate. This results in higher
+ throughput for TCP as the sending window can open up more between
+ 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-access
+ links and multicast.
+
+ Headers that can be compressed include TCP, UDP, IPv4, and IPv6 base
+ and extension headers. For TCP packets, the mechanisms of Van
+ Jacobson [RFC-1144] are used to recover from loss. Two additional
+ mechanisms that increase the efficiency of VJ header compression over
+ lossy links are also described. For non-TCP packets, compression
+ slow-start and periodic header refreshes allow minimal periods of
+ packet discard after loss of a header that changes the context. There
+ are hooks for adding header compression schemes on top of UDP, for
+ example compression of RTP headers.
+
+ Header compression relies on many fields being constant or changing
+ seldomly in consecutive packets belonging to the same packet stream.
+ Fields that do not change between packets need not be transmitted at
+ all. Fields that change often with small and/or predictable values,
+ e.g., TCP sequence numbers, can be encoded incrementally so that the
+ number of bits needed for these fields decrease significantly. Only
+ fields that change often and randomly, e.g., checksums or
+ authentication data, need to be transmitted in every header.
+
+ The general principle of header compression is to occasionally send a
+ packet with a full header; subsequent compressed headers refer to the
+ context established by the full header and may contain incremental
+ 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 in
+ the same stream passes over the compressed link. However, for TCP
+ streams the difference between subsequent headers can become more
+ irregular and the compression rate can decrease. Neither is it
+ required that corresponding TCP data and acknowledgment packets
+ traverse the link in opposite directions.
+
+ This header compression scheme is useful on first-hop or last-hop
+ links as well as links in the middle of the network. When many packet
+ streams (several hundred) traverse the link, a phenomenon that could
+ be called CID thrashing could occur, where headers seldom can be
+ matched with an existing context and have to be sent uncompressed or
+ as full headers. It is up to an implementation to use techniques such
+ as hysteresis to ensure that the packet streams that give the highest
+ compression rates keep their context. Such techniques are more
+ likely to be needed in the middle of the network.
+
+2. Terminology
+
+ 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 this
+ document are to be interpreted as described in RFC 2119.
+
+ Subheader
+
+ An IPv6 base header, an IPv6 extension header, an IPv4 header, a
+ UDP header, or a TCP header.
+
+ Header
+
+ A chain of subheaders.
+
+ Compress
+
+ The act of reducing the size of a header by removing header fields
+ or reducing the size of header fields. This is done in a way such
+ that a decompressor can reconstruct the header if its context
+ state is identical to the context state used when compressing the
+ header.
+
+ Decompress
+
+ 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 used
+ to decompress a compressed header. Carried in full headers and
+ compressed headers.
+
+ Context
+
+ The state which the compressor uses to compress a header and the
+ decompressor uses to decompress a header. The context is the
+ uncompressed version of the last header sent (compressor) or
+ received (decompressor) over the link, except for fields in the
+ header that are included "as-is" in compressed headers or can be
+ inferred from, e.g., the size of the link-level frame.
+
+ The context for a packet stream is associated with a context
+ identifier. The context for non-TCP packet streams is also
+ associated with a generation.
+
+ Generation
+
+ For non-TCP packet streams, each new version of the context for a
+ given CID is associated with a generation: a small number that is
+ incremented whenever the context associated with that CID changes.
+ Carried by full and compressed non-TCP headers.
+
+ Packet stream
+
+ A sequence of packets whose headers are similar and share context.
+ For example, headers in a TCP packet stream have the same source
+ and final destination address, and the same port numbers in the
+ TCP header. Similarly, headers in a UDP packet stream have the
+ same source and destination address, and the same port numbers in
+ the UDP header.
+
+ Full header (header refresh)
+
+ An uncompressed header that updates or refreshes the context for a
+ packet stream. It carries a CID that will be used to identify the
+ context.
+
+ Full headers for non-TCP packet streams also carry the generation
+ of the context they update or refresh.
+
+ Regular header
+
+ A normal, uncompressed, header. Does not carry CID or generation
+ association.
+
+
+
+Degermark, et. al. Standards Track [Page 6]
+
+RFC 2507 IP Header Compression February 1999
+
+
+ Incorrect decompression
+
+ When a compressed and then decompressed header is different from
+ the uncompressed header. Usually due to mismatching context
+ between the compressor and decompressor or bit errors during
+ transmission of the compressed header.
+
+ Differential coding
+
+ A compression technique where the compressed value of a header
+ field is the difference between the current value of the field and
+ the value of the same field in the previous header belonging to
+ the same packet stream. A decompressor can thus obtain the value
+ of the field by adding the value in the compressed header to its
+ context. This technique is used for TCP streams but not for non-
+ TCP streams.
+
+3. Compression method
+
+ Much of the header information stays the same over the life-time of a
+ packet stream. For non-TCP packet streams almost all fields of the
+ headers are constant. For TCP many fields are constant and others
+ change with small and predictable values.
+
+ To initiate compression of the headers of a packet stream, a full
+ header carrying a context identifier, CID, is transmitted over the
+ link. The compressor and decompressor store most fields of this full
+ header as context. The context consists of the fields of the header
+ whose values are constant and thus need not be sent over the link at
+ all, or change little between consecutive headers so that it uses
+ fewer bits to send the difference from the previous value compared to
+ sending the absolute value.
+
+ Any change in fields that are expected to be constant in a packet
+ stream will cause the compressor to send a full header again to
+ update the context at the decompressor. As long as the context is the
+ same at compressor and decompressor, headers can be decompressed to
+ be exactly as they were before compression. However, if a full header
+ or compressed header is lost during transmission, the context of the
+ 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 a
+ significant fraction of damaged packets to the IPv6 module. This
+ means that links must have a very low bit-error rate or that link-
+ level frames must be protected by strong checksums, forward error
+ correction or something of that nature. Header compression SHOULD
+ not be used for IPv4 without strong link-level checksums. Damaged
+
+
+
+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 layer
+ implementation might indicate to the header compression module that a
+ frame was damaged, but it cannot say what packet stream it belonged
+ to as it might be the CID that is damaged. Moreover, frames may
+ disappear without the link layer implementation's knowledge, for
+ example if the link is a multi-hop link where frames can be dropped
+ due to congestion at each hop. The kind of link errors that a header
+ compression module should deal with and protect against will thus be
+ packet loss.
+
+ So a header compression scheme needs mechanisms to update the context
+ at the decompressor and to detect or avoid incorrect decompression.
+ These mechanisms are very different for TCP and non-TCP streams, and
+ are described in sections 3.2 and 3.3.
+
+ The compression mechanisms in this document assume that packets are
+ not reordered between the compressor and decompressor. If the link
+
+ does reorder, section 11 describes mechanisms for ordering the
+ packets before decompression. It is also assumed that the link-layer
+ implementation can provide the length of packets, and that there is
+ no padding in UDP packets or tunneled packets.
+
+3.1. Packet types
+
+ This compression method uses four packet types in addition to the
+ IPv4 and IPv6 packet types. The combination of link-level packet
+ type and the value of the first four bits of the packet uniquely
+ determines the packet type. Details on how these packet types are
+ 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. It
+ establishes or refreshes the context for the packet stream
+ identified by the CID.
+
+ COMPRESSED_NON_TCP - indicates a non-TCP packet with a compressed
+ header. The compressed header consists of a CID identifying what
+ context to use for decompression, a generation to detect an
+ inconsistent context and the randomly changing fields of the
+ header.
+
+ COMPRESSED_TCP - indicates a packet with a compressed TCP header,
+ containing a CID, a flag octet indentifying what fields have
+ changed, and the changed fields encoded as the difference from
+ 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 TCP
+ header where all fields that are normally sent as the difference
+ to the previous value are instead sent as-is. This packet type
+ is only sent as the response to a header request from the
+ decompressor. It must not be sent as the result of a
+ retransmission.
+
+ In addition to the packet types used for compression, regular IPv4
+ and IPv6 packets are used whenever a compressor decides to not
+ compress a packet. An additional packet type may be used to speed up
+ repair of TCP streams over links where the decompressor can send
+ packets to the compressor.
+
+ CONTEXT_STATE - indicates a special packet sent from the
+ decompressor to the compressor to communicate a list of (TCP)
+ CIDs for which synchronization has been lost. This packet is only
+ sent over a single link so it requires no IP header. The format
+ is shown in section 10.2.
+
+3.2. Lost packets in TCP packet streams
+
+ Since TCP headers are compressed using the difference from the
+ previous TCP header, loss of a packet with a compressed or full
+ header will cause subsequent compressed headers to be decompressed
+ incorrectly because the context used for decompression was not
+ incremented properly.
+
+ Loss of a compressed TCP header will cause the TCP sequence numbers
+ of subsequently decompressed TCP headers to be off by k, where k is
+ the size of the lost segment. Such incorrectly decompressed TCP
+ headers will be discarded by the TCP receiver as the TCP checksum
+ reliably catches "off-by-k" errors in the sequence numbers for
+ plausible k.
+
+ TCP's repair mechanisms will eventually retransmit the discarded
+ segment and the compressor peeks into the TCP headers to detect when
+ TCP retransmits. When this happens, the compressor sends a full
+ header on the assumption that the retransmission was due to
+ mismatching compression state at the decompressor. [RFC-1144] has a
+ good explanation of this mechanism.
+
+ The mechanisms of section 10 should be used to speed up the repair of
+ the context. This is important over medium speed links with high
+ packet loss rates, for example wireless. Losing a timeout's worth of
+ packets due to inconsistent context after each packet lost over the
+ link is not acceptable, especially when the TCP connection is over
+ 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 streams
+
+ Incorrectly decompressed headers of UDP packets and other non-TCP
+ packets are not so well-protected by checksums as TCP packets. There
+ are no sequence numbers that become "off-by-k" and virtually
+ guarantees a failed checksum as there are for TCP. The UDP checksum
+ only covers payload, UDP header, and pseudo header. The pseudo
+ header includes the source and destination addresses, the transport
+ protocol type and the length of the transport packet. Except for
+ those fields, large parts of the IPv6 header are not covered by the
+ UDP checksum. Moreover, other non-TCP headers lack checksums
+ 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 identified
+ by a generation, a small number that is carried by the full headers
+ that establish and refresh the context. Compressed headers carry the
+ generation value of the context that were used to compress them.
+ When a decompressor sees that a compressed header carries a
+ generation value other than the generation of its context for that
+ packet stream, the context is not up to date and the packet must be
+ discarded or stored until a full header establishes correct context.
+
+ Differential coding is not used for non-TCP streams, so compressed
+ non-TCP headers do not change the context. Thus, loss of a
+ compressed header does not invalidate subsequent packets with
+ compressed headers. Moreover, the generation changes only when the
+ context of a full header is different from the context of the
+ previous full header. This means that losing a full header will make
+ the context of the decompressor obsolete only when the full header
+ would actually have changed the context.
+
+ The generation field is 6 bits long so the generation value repeats
+ itself after 64 changes to the context. To avoid incorrect
+ decompression after error bursts or other temporary disruptions, the
+ compressor must not reuse the same generation value after a shorter
+ time than MIN_WRAP seconds. A decompressor which has been
+ disconnected MIN_WRAP seconds or more must wait for the next full
+ header before decompressing. A compressor must wait at least MIN_WRAP
+ seconds after booting before compressing non-TCP headers. Instead of
+ reusing a generation value too soon, a compressor may switch to
+ another CID or send regular headers until MIN_WRAP seconds have
+ 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-Start
+
+ To allow the decompressor to recover quickly from loss of a full
+ header that would have changed the context, full headers are sent
+ periodically with an exponentially increasing period after a change
+ in the context. This technique avoids an exchange of messages between
+ compressor and decompressor used by other compression schemes, such
+ as in [RFC-1553]. Such exchanges can be costly for wireless mobiles
+ as more power is consumed by the transmitter and delay can be
+ introduced by switching between sending and receiving. Moreover,
+ techniques that require an exchange of messages cannot be used over
+ simplex links, such as direct-broadcast satellite channels or cable
+ TV systems, and are hard to adapt to multicast over multi-access
+ links.
+
+ |.|..|....|........|................|..............................
+ ^
+ Change Sent packets: | with full header, . with compressed header
+
+ The picture shows how packets are sent after change. The compressor
+ keeps a variable for each non-TCP packet stream, F_PERIOD, that keeps
+ track of how many compressed headers may be sent between full
+ headers. When the headers of a non-TCP packet stream change so that
+ its context changes, a full header is sent and F_PERIOD is set to
+ one. After sending F_PERIOD compressed headers, a full header is
+ sent. F_PERIOD is doubled each time a full header is sent during
+ compression slow-start.
+
+3.3.2. Periodic Header Refreshes
+
+ 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-TCP
+ packets with compressed headers that may be sent between header
+ refreshes. If a packet is to be sent and F_MAX_PERIOD compressed
+ headers have been sent since the last full header for this packet
+ stream was sent, a full header must be sent.
+
+ To avoid long periods of disconnection for low data rate packet
+ streams, there is also an upper bound, F_MAX_TIME, on the time
+ between full headers in a non-TCP packet stream. If a packet is to be
+ sent and more than F_MAX_TIME seconds have passed since the last full
+ 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 Headers
+
+ The following pseudo code can be used by the compressor to determine
+ when to send a full header for a non-TCP packet stream. The code
+ maintains two variables:
+
+ C_NUM -- a count of the number of compressed headers sent
+ since the last full header was sent.
+ F_LAST -- the time of sending the last full header.
+
+ and uses the functions
+
+ current_time() return the current time
+ min(a,b) return the smallest of a and b
+
+ the procedures send_full_header(), increment_generation_value(),
+ and send_compressed_header()
+ do the obvious thing.
+
+ if ( <this header changes the context> )
+
+ 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();
+
+ else
+
+ C_NUM := C_NUM + 1
+ send_compressed_header();
+
+ endif
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 12]
+
+RFC 2507 IP Header Compression February 1999
+
+
+3.3.4. Cost of sending Header Refreshes
+
+ If every f'th packet carries a full header, H is the size of a full
+ header, and C is the size of a compressed header, the average header
+ size is
+
+ (H-C)/f + C
+
+ For f > 1, the average header size is (H-C)/f larger than a
+ compressed header.
+
+ In a diagram where the average header size is plotted for various f
+ values, there is a distinct knee in the curve, i.e., there is a limit
+ beyond which further increasing f gives diminishing returns.
+ F_MAX_PERIOD should be chosen to be a frequency well to the right of
+ the knee of the curve. For typical sizes of H and C, say 48 octets
+ for the full header (IPv6/UDP) and 4 octets for the compressed
+ header, setting F_MAX_PERIOD > 44 means that full headers will
+ contribute less than an octet to the average header size. With a
+ four-address routing header, F_MAX_PERIOD > 115 will have the same
+ effect.
+
+ The default F_MAX_PERIOD value of 256 (section 14) puts the full
+ header frequency well to the right of the knee and means that full
+ headers will typically contribute considerably less than an octet to
+ the average header size. For H = 48 and C = 4, full headers
+ contribute about 1.4 bits to the average header size after reaching
+ the steady-state header refresh frequency determined by the default
+
+ F_MAX_PERIOD. 1.4 bits is a very small overhead.
+
+ After a change in the context, the exponential backoff scheme will
+ initially send full headers frequently. The default F_MAX_PERIOD
+ will be reached after nine full headers and 255 compressed headers
+ have been sent. This is equivalent to a little over 5 seconds for a
+ typical voice stream with 20 ms worth of voice samples per packet.
+
+ During the whole backoff period, full headers contribute 1.5 octets
+ to the average header size when H = 48 and C = 4. For 20 ms voice
+ samples, it takes less than 1.3 seconds until full headers contribute
+ less than one octet to the average header size, and during these
+ initial 1.3 seconds full headers add less than 4 octets to the
+ average header size. The cost of the exponential backoff is not
+ great and as the headers of non-TCP packet streams are expected to
+ 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 than
+ similar costs for hard state schemes like [RFC-1553] where full
+ headers must be acknowledged by the decompressor before compressed
+ headers may be sent. Such schemes typically send one full header plus
+ a few control messages when the context changes. Hard state schemes
+ require more types of protocol messages and an exchange of messages
+ is necessary. Hard state schemes also need to deal explicitly with
+ various error conditions that soft state handles automatically, for
+ instance the case of one party disappearing unexpectedly, a common
+ situation on wireless links where mobiles may go out of range of the
+ base station.
+
+ The major advantage of the soft state scheme is that no handshakes
+ are needed between compressor and decompressor, so the scheme can be
+ used over simplex links. The costs in terms of bandwidth are higher
+ than for hard state schemes, but the simplicity of the decompressor,
+ the simplicity of the protocol, and the lack of handshakes between
+ compressor and decompressor justifies this small cost. Moreover, soft
+ state schemes are more easily extended to multicast over multi-access
+ links, for example radio links.
+
+4. Grouping packets into packet streams
+
+ This section explains how packets MAY be grouped together into packet
+ streams for compression. To achieve the best compression rates,
+ packets SHOULD be grouped together such that packets in the same
+ packet stream have similar headers. If this grouping fails, header
+ compression performance will be bad, since the compression algorithm
+ can rarely utilize the existing context for the packet stream and
+ full headers must be sent frequently.
+
+ Grouping is done by the compressor. A compressor may use whatever
+ criterion it finds appropriate to group packets into packet streams.
+ To determine what packet stream a packet belongs to, a compressor MAY
+
+ a) examine the compressible chain of subheaders (see section 7),
+
+ b) examine the contents of an upper layer protocol header that
+ follows the compressible chain of subheaders, for example ICMP
+ headers, DVMRP headers, or tunneled IPX headers,
+
+ c) use information obtained from a resource manager, for example if a
+ resource manager requests compression for a particular packet
+ stream and provides a way to identify packets belonging to that
+ 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 and
+ the hop limit (TTL) field in a packet stream changes frequently
+ between n and n+k, a compressor may choose to group the packets
+ into two different packet streams.
+
+ A compressor is also free not to group packets into packet streams
+ for compression, letting some packets keep their regular headers and
+ passing them through unmodified.
+
+ As long as the rules for when to send full headers for a non-TCP
+ packet stream are followed and subheaders are compressed as specified
+ in this document, the decompressor is able to reconstruct a
+ compressed header correctly regardless of how packets are grouped
+ into packet streams.
+
+4.1 Guidelines for grouping packets
+
+ In this section we give OPTIONAL guidelines for how a compressor may
+ group packets into packet streams for compression.
+
+ Defining fields
+
+ The defining fields of a header should be present and identical in
+ all packets belonging to the same packet stream. These fields are
+ marked DEF in section 7. The defining fields include the flow
+ label, source and destination addresses of IP headers, final
+ destination address in routing headers, the next header fields
+ (for IPv6), the protocol field (IPv4), port numbers (UDP and TCP),
+ and the SPI in authentication and encryption headers.
+
+ Fragmented packets
+
+ Fragmented and unfragmented packets should never be grouped
+ together in the same packet stream. The Identification field of
+ the Fragment header or IPv4 header should not be used to identify
+ the packet stream. If it was, the first fragment of a new packet
+ would cause a compression slow-start.
+
+ No field after a Fragment Header, or an IPv4 header for a
+ fragment, should be used for grouping purposes.
+
+ Upper protocol identification
+
+ The first next header field identifying a header not described in
+ section 7 should be used for identifying packet streams, i.e., all
+ packets with the same DEF fields and the same upper protocol
+ 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 can
+ occur when there are frequent route flaps so that packets traverse
+ 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 and
+ the Type of Service of the IPv4 header will change frequently
+ between packets with otherwise identical DEF fields. A
+ sophisticated implementation should watch out for this and be
+ prepared to use these fields as defining fields.
+
+ When IP packets are tunneled they are encapsulated with an additional
+ IP header at the tunnel entry point and then sent to the tunnel
+ endpoint. To group such packets into packet streams, the inner
+ headers should also be examined to determine the packet stream. If
+ this is not done, full headers will be sent each time the headers of
+ the inner IP packet changes. So when a packet is tunneled, the
+ identifying fields of the inner subheaders should be considered in
+ addition to the identifying fields of the initial IP header.
+
+ An implementation can use other fields for identification than the
+ ones described here. If too many fields are used for identification,
+ performance might suffer because more CIDs will be used and the wrong
+ CIDs might be reused when new flows need CIDs. If too few fields are
+ used for identification, performance might suffer because there are
+ too frequent changes to the context.
+
+ We stress that these guidelines are educated guesses. When IPv6 is
+ widely deployed and IPv6 traffic can be analyzed, we might find that
+ other grouping algorithms perform better. We also stress that if the
+ grouping fails, the result will be bad performance but not incorrect
+ decompression. The decompressor can do its task regardless of how the
+ grouping algorithm works.
+
+5. Size Issues
+
+5.1. Context Identifiers
+
+ Context identifiers can be 8 or 16 bits long. Their size is not
+ relevant for finding the context. An 8-bit CID with value two and a
+ 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 a
+ non-TCP CID never identify the same context. Even if they have the
+ same value. This doubles the available CID space while using the same
+ number of bits for CIDs. It is always possible to tell whether a
+ full or compressed header is for a TCP or non-TCP packet, so no
+ mixups can occur.
+
+ Non-TCP compressed headers encode the size of the CID using one bit
+ in the second octet of the compressed header. The 8-bit CID allows a
+ minimum compressed header size of 2 octets for non-TCP packets, the
+ CID uses the first octet and the size bit and the 6-bit Generation
+ 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 is
+ intended for use on multi-access links where a larger CID space may
+ be needed for efficient selection of CIDs.
+
+ The major difficulty with multi-access links is that several
+ compressors share the CID space of a decompressor. CIDs can no
+ longer be selected independently by the compressors as collisions may
+ occur. This problem may be resolved by letting the decompressors
+ have a separate CID space for each compressor. Having separate CID
+ spaces requires that decompressors can identify which compressor sent
+ the compressed packet, perhaps by utilizing link-layer information as
+ to who sent the link-layer frame. If such information is not
+ available, all compressors on the multi-access link may be
+ enumerated, automatically or otherwise, and supply their number as
+ part of the CID. This latter method requires a large CID space.
+
+5.2. Size of the context
+
+ The size of the context SHOULD be limited to simplify implementation
+ of compressor and decompressor, and put a limit on their memory
+ requirements. However, there is no upper limit on the size of an
+ IPv6 header as the chain of extension headers can be arbitrarily
+ long. This is a problem as the context is essentially a stored
+ header.
+
+ The configurable parameter MAX_HEADER (see section 14) represents the
+ maximum size of the context, expressed as the maximum sized header
+ that can be stored as context. When a header is larger than
+ MAX_HEADER, only part of it is stored as context. An implementation
+ MUST NOT compress more than the initial MAX_HEADER octets of a
+ 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 is
+ compressed is the longest initial sequence of entire subheaders that
+ is not larger than MAX_HEADER octets.
+
+5.3. Size of full headers
+
+ It is desirable to avoid increasing the size of packets with full
+ headers beyond their original size, as their size may be optimized
+ for the MTU of the link. Since we assume that the link layer
+ implementation provides the length of packets, we can use the length
+ fields in full headers to pass the values of the CID and the
+ generation to the decompressor.
+
+ This requires that the link-layer must not add padding to the
+ payload, at least not padding that can be delivered to the
+ destination link user. It is also required that no extra padding is
+ added after UDP data or in tunneled packets. This allows values of
+ length fields to be calculated from the length of headers and the
+ 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 the
+ IP header to pass the 8 bit CID, which is sufficient. There will be
+ 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 pass
+ the CID. We cannot use the corresponding method as the sequence of
+ IPv6 extension headers is not fixed and CID values are not disjoint
+ from the legal values of Next Header fields.
+
+ An IPv6/UDP or IPv4/UDP packet will have 4 octets available to pass
+ the generation and the CID, so all CID sizes may be used. Fragmented
+ or encrypted packet streams may have only 2 octets available to pass
+ the generation and CID. Thus, 8-bit CIDs may be the only CID sizes
+ that can be used for such packet streams. When IPv6/IPv4 or
+ IPv4/IPv6 tunneling is used, there will be at least 4 octets
+ available, and both CID sizes may be used.
+
+ The generation value is passed in the higher order octet of the first
+ length field in the full header. When only one length field is
+ available, the 8-bit CID is passed in the low order octet. When two
+ length fields are available, the lowest two octets of the CID are
+ passed in the second length field and the low order octet of the
+ 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 headers
+
+ 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 section
+ 11.2.
+
+5.3.2. Use of length fields in full non-TCP headers
+
+ 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 the
+ CID. The Data field is zero if D is zero. The use of the D bit and
+ Data field is explained in section 12.
+
+
+
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 19]
+
+RFC 2507 IP Header Compression February 1999
+
+
+6. Compressed Header Formats
+
+ This section uses some terminology (DELTA, RANDOM) defined in section
+ 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 meaning
+ as in [RFC-1144], regardless of whether the TCP segments are carried
+ by IPv6 or IPv4. The C bit has been eliminated because the CID is
+ always present. The context associated with the CID keeps track of
+ the IP version and what RANDOM fields are present. The order between
+ delta fields specified here is exactly as in [RFC-1144]. An
+ implementation will typically scan the context from the beginning and
+ insert the RANDOM fields in order. The RANDOM fields are thus placed
+ before the DELTA fields of the TCP header in the same order as they
+ 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 TCP
+ header. The combined IPv4/TCP header is then compressed as a unit as
+ described in [RFC-1144]. Identification fields in IPv4 headers that
+ 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 same
+ as in the previous header. The entire Option field are placed last in
+ the compressed TCP header.
+
+ If the R flag is set, there were differences between the context and
+ the Reserved field (6 bits) in the TCP header or bit 6 or 7 of the
+ TOS octet (Traffic Class octet) in a IPv4 header (IPv6 header) that
+ immediately precedes the TCP header. An octet with the actual values
+ of the Reserved field and bit 6 and 7 of the TOS or Traffic Class
+ field is then placed immediately after the RANDOM fields. Bits 0-5
+ of the passed octet is the actual value of the Reserved field, and
+ bits 6 and 7 are the actual values of bits 6 and 7 in the TOS or
+ 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, the
+ nTCP checksum would not guard the receiving TCP from erroneously
+ decompressed headers. Bits 6 and 7 of the TOS octet or Traffic Class
+ octet is expected to change frequently due to Explicit Congestion
+ Notification.
+
+ See section 7.12 and [RFC-1144] for further information on how to
+ compress TCP headers.
+
+ b) COMPRESSED_TCP_NODELTA header format
+
+ +-+-+-+-+-+-+-+-+
+ | CID |
+ +-+-+-+-+-+-+-+-+
+ | RANDOM fields, if any (see section 7) (implied)
+ +-+-+-+-+-+-+-+-+
+ | Whole TCP header except for Port Numbers
+ +-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 by
+ relevant RANDOM fields (see section 7) as implied by the compression
+ state, placed in the same order as they occur in the original
+ uncompressed header, followed by the payload.
+
+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,
+
+
+
+
+
+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) 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.
+
+
+
+
+
+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 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.
+
+
+
+
+
+
+
+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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 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.
+
+
+
+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 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
+
+
+
+Degermark, et. al. Standards Track [Page 27]
+
+RFC 2507 IP Header Compression February 1999
+
+
+ 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.
+
+
+
+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 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.
+
+
+
+
+
+
+
+
+
+
+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 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.
+
+
+
+
+
+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 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.
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 31]
+
+RFC 2507 IP Header Compression February 1999
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 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)
+
+
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 33]
+
+RFC 2507 IP Header Compression February 1999
+
+
+ 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 :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Degermark, et. al. Standards Track [Page 34]
+
+RFC 2507 IP Header Compression February 1999
+
+
+ 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.
+
+8. Changing context identifiers
+
+ On a point-to-point link, the compressor has total knowledge of what
+ CIDs are in use at the decompressor and may change what CID a packet
+ stream uses or reuse CIDs at will.
+
+ Each non-TCP CID is associated with a context with a generation
+ value. To avoid too rapid generation wrap-around and potential
+ incorrect decompression, an implementation MUST avoid wrap-around of
+ the generation value in less than MIN_WRAP seconds (see section 14).
+
+ To aid in avoiding wrap-around, the generation value associated with
+ a CID MUST NOT be reset when changing to a new packet stream.
+ Instead, a compressor MUST increment the generation value by one when
+ using the CID for a new non-TCP packet stream.
+
+9. Rules for dropping or temporarily storing packets
+
+ When a decompressor receives a packet with a compressed TCP header
+ with CID C, it MUST be discarded when the context for C has not been
+ initialized by a full header.
+
+ When a decompressor receives a packet with a compressed non-TCP
+ header with CID C and generation G, the header must not be
+ decompressed using the current context when
+
+ a) the decompressor has been disconnected from the compressor for
+ more than MIN_WRAP seconds, because the context might be
+ obsolete even if it has generation G.
+
+ b) the context for C has a generation other than G.
+
+ In case a) and b) the packet may either be
+
+ i) discarded immediately, or else
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 35]
+
+RFC 2507 IP Header Compression February 1999
+
+
+ ii) stored temporarily until the context is updated by a packet
+ with a full non-TCP header with CID C and generation G, after
+ which the header can be decompressed.
+
+ Packets stored in this manner MUST be discarded when
+
+ *) receiving full or compressed non-TCP headers with CID C
+ and a generation other than G,
+
+ *) the decompressor has not received packets with CID C in
+ the last MIN_WRAP seconds.
+
+ When full headers are lost, a decompressor can receive compressed
+ non-TCP headers with a generation value other than the generation of
+ its context. Rule ii) allows the decompressor to store such headers
+ until they can be decompressed using the correct context.
+
+10. Low-loss header compression for TCP
+
+ Since fewer bits are transmitted per packet with header compression,
+ the packet loss rate is lower with header compression than without,
+ for a fixed bit-error rate. This is beneficial for links with high
+ bit-error rates such as wireless links.
+
+ However, since TCP headers are compressed using differential
+ encoding, a single lost TCP segment can ruin an entire TCP sending
+ window because the context is not incremented properly at the
+ decompressor. Subsequent headers will therefore be decompressed to
+ be different than before compression and discarded by the TCP
+ receiver because the TCP checksum fails.
+
+ A TCP connection in the wide area where the last hop is over a
+ medium-speed lossy link, for example a wireless LAN, will then have
+ poor performance with traditional header compression because the
+ delay-bandwidth product is relatively large and the bit-error rate
+ relatively high. For a 2 Mbit/s wireless LAN and an end-to-end RTT of
+ 200 ms, the delay-bandwidth product is 50 kbyte. That is equivalent
+ to about 97 512-octet segments with compressed headers. Each loss
+ can thus be multiplied by a factor of 100.
+
+ This section describes two simple mechanisms for quick repair of the
+ context. With these mechanisms header compression will improve TCP
+ throughput over lossy links as well as links with low bit-error
+ rates.
+
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 36]
+
+RFC 2507 IP Header Compression February 1999
+
+
+10.1. The "twice" algorithm
+
+ The decompressor may compute the TCP checksum to determine if its
+ context is not updated properly. If the checksum fails, the error is
+ assumed to be caused by a lost segment that did not update the
+ context properly. The delta of the current segment is then added to
+ the context again on the assumption that the lost segment contained
+ the same delta as the current. By decompressing and computing the TCP
+ checksum again, the decompressor checks if the repair succeeded or if
+ the delta should be applied once more.
+
+ Analysis of traces of various TCP bulk transfers show that applying
+ the delta of the current segment one or two times will repair the
+ context for between 83 and 99 per cent of all single-segment losses
+ in the data stream. For the acknowledgment stream, the success rate
+ is smaller due to the delayed ack mechanism of TCP. The "twice"
+ mechanism repairs the context for 53 to 99 per cent of the losses in
+ the acknowledgment stream. A sophisticated implementation of this
+ idea would determine whether the TCP stream is an acknowledgment or
+ data stream and determine the segment size by observing the stream of
+ full and compressed headers. Trying deltas that are small multiples
+ of the segment size will result in even higher rates of successful
+ repairs for acknowledgment streams.
+
+10.2. Header Requests
+
+ The relatively low success rate for the "twice" algorithm for TCP
+ acknowledgment streams calls for an additional mechanism for
+ repairing the context at the decompressor. When the decompressor
+ fails to repair the context after a loss, the decompressor may
+ optionally request a full header from the compressor. This is
+ possible on links where the decompressor can identify the compressor
+ and send packets to it.
+
+ On such links, a decompressor may send a CONTEXT_STATE packet back to
+ the compressor to indicate that one or more contexts are invalid. A
+ decompressor SHOULD NOT transmit a CONTEXT_STATE packet every time a
+ compressed packet refers to an invalid context, but instead should
+ limit the rate of transmission of CONTEXT_STATE packets to avoid
+ flooding the reverse channel. A CONTEXT_STATE packet can indicate
+ that several contexts are out of date, this technique SHOULD be used
+ instead of sending several separate packets. The following diagram
+ shows the format of a CONTEXT_STATE packet.
+
+
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 37]
+
+RFC 2507 IP Header Compression February 1999
+
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | TCP header request = 3 |
+ +---+---+---+---+---+---+---+---+
+ | CID count |
+ +---+---+---+---+---+---+---+---+
+ | CID |
+ +---+---+---+---+---+---+---+---+
+ | CID |
+ +---+---+---+---+---+---+---+---+
+ ...
+ +---+---+---+---+---+---+---+---+
+ | CID |
+ +---+---+---+---+---+---+---+---+
+
+ The first octet is a type code to allow the CONTEXT_STATE packet type
+ to be shared for other compression protocols that are (see [CRTP]) or
+ may be defined in parallel with this one. When used for TCP header
+ requests the type code has the value 3, and the remainder of the
+ packet is a sequence of CIDs preceded by a one-octet count of the
+ number of CIDs.
+
+ On receipt of a CONTEXT_STATE packet, the compressor MUST mark the
+ CIDs invalid to ensure that the next packet emitted in those packet
+ streams are FULL_HEADER or COMPRESSED_TCP_NODELTA packets.
+
+ Header requests are an optimization, so loss of a CONTEXT_STATE
+ packet does not affect the correct operation of TCP header
+ compression. When a CONTEXT_STATE packet is lost, eventually a new
+ one will be transmitted or TCP will timeout and retransmit. The big
+ advantage of using header requests is that TCP acknowledgment streams
+ can be repaired after a roundtrip-time over the lossy link. This
+ will typically avoid a TCP timeout and unnecessary retransmissions.
+ The lower packet loss rate due to smaller packets will then result in
+ higher throughput because the TCP window can grow larger between
+ losses.
+
+11. Links that reorder packets
+
+ Some links reorder packets, for example multi-hop radio links that
+ use deflection routing to route around congested nodes. Packets
+ routed different ways can then arrive at the destination in a
+ different order than they were sent.
+
+
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 38]
+
+RFC 2507 IP Header Compression February 1999
+
+
+11.1. Reordering in non-TCP packet streams
+
+ Compressed non-TCP headers do not change the context, and neither do
+ full headers that refresh it. There can be problems only when a full
+ header that changes the context arrives out of order. There are two
+ cases:
+
+ - A packet with a full header with generation G arrives *after*
+ a packet with a compressed header with generation G. This case
+ is covered by rule b) ii) in section 9.
+
+ - A packet with a full header with generation G arrives *before*
+ a packet with a compressed header with generation G-1 (modulo
+ 64). The decompressor MAY then keep both versions of the
+ context around for a while to be able to decompress subsequent
+ compressed headers with generation G-1 (modulo 64). The old
+ context MUST be discarded after MIN_WRAP seconds.
+
+11.2. Reordering in TCP packet streams
+
+ A compressor may avoid sending COMPRESSED_TCP headers and only send
+ COMPRESSED_TCP_NODELTA headers when there is reordering over the
+ link. Compressed headers will typically be 17 octets with that
+ method, significantly larger than the usual 4-7 octets.
+
+ To achieve better compression rates the following method, adding only
+ two octets to the compressed header for a total of 6-9 octets, may be
+ used. A packet sequence number, incremented by one for every packet
+ in the TCP stream, is then associated with each compressed and full
+ header. This allows the decompressor to place the packets in the
+ correct sequence and apply their deltas to the context in the correct
+ order. A simple sliding window scheme is used to place the packets
+ in the correct order.
+
+ Two octets are needed for the packet sequence numbers. One octet
+ gives only 256 sequence numbers. In a sliding window scheme the
+ window should be no larger than half of the sequence number space, so
+ packets can not arrive more than 127 positions out-of-sequence. This
+ is equivalent to a delay of 260 ms on 2 Mbit/s links with 512 octet
+ segments. Delays of that order are not uncommon over wide-area
+ Internet connections. However, two octets giving 2^16 = 65536 values
+ should be sufficient.
+
+ Full TCP/IP headers will only have space for one octet of sequence
+ number when there is no tunneling. It is not feasible to increase the
+ size of full headers since the packet size might be optimized for the
+ MTU of the link. Therefore only the least significant octet of the
+ packet sequence number can be placed in such full headers. We believe
+
+
+
+Degermark, et. al. Standards Track [Page 39]
+
+RFC 2507 IP Header Compression February 1999
+
+
+ that such full headers can be positioned correctly frequently enough
+ with only the least significant octet of the packet sequence number
+ available.
+
+ The packet sequence number zero MUST be skipped over. Avoiding zero
+ takes care of a problem that can occur when the TCP window scale
+ option is used to enlarge the TCP window. When exactly 2^16 octets of
+ TCP data is lost, a compressed header will be decompressed
+ incorrectly without being detected by the TCP checksum. TCP segment
+ sizes are often a power of two. So by using a packet sequence number
+ space that is not a power of two either the TCP sequence number or
+ the packet sequence number will differ when 2^16 octets are lost.
+ Whenever a compressor sees the window scale option on a SYN segment,
+ it MUST use packet sequence numbers when subsequently compressing
+ that packet stream.
+
+ In compressed TCP headers the two octet packet sequence number MUST
+ be placed immediately after the TCP Checksum. See section 5.3 for
+ placement of packet sequence numbers in full headers.
+
+12. Hooks for additional header compression
+
+ The following hook is supplied to allow additional header compression
+ schemes for headers on top of UDP. The initial chain of subheaders is
+ then compressed as described here, and the other header compression
+ scheme is applied to the header above the UDP header. An example of
+ such additional header compression is Compressed RTP by Casner and
+ Jacobson [CRTP]. To allow some error detection, such schemes
+ typically need a sequence number that may need to be passed in full
+ headers as well as compressed UDP headers.
+
+ The D-bit and Data octet (see section 6) provides the necessary
+ mechanism. When a sequence number, say, needs to be passed in a
+ FULL_HEADER or COMPRESSED_NON_TCP header, the D-bit is set and the
+ sequence number is placed in the Data field. The decompressor must
+ then extract and make the Data field available to the additional
+ header compression scheme.
+
+ Use of additional header compression schemes like CRTP must be
+ negotiated. The D-bit and Data octet mechanism must automatically be
+ enabled whenever use of additional header compression schemes has
+ been negotiated.
+
+
+
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 40]
+
+RFC 2507 IP Header Compression February 1999
+
+
+13. Demultiplexing
+
+ For each link layer, there must be a document specifying how the
+ various packet types used by IP header compression is indicated.
+ Such a document exists for PPP [PPP-HC]. This section gives OPTIONAL
+ guidelines on how packet types may be indicated by a specific link-
+ layer.
+
+ It is necessary to distinguish packets with regular IPv4 headers,
+ regular IPv6 headers, full IPv6 packets, full IPv4 packets,
+ compressed TCP packets, compressed non-TCP packets, and CONTEXT_STATE
+ packets.
+
+ The decision to use a distinct ethertype (or equivalent) for IPv6 has
+ already been taken, which means that link-layers must be able to
+ indicate that a packet is an IPv6 packet.
+
+ IP header compression requires that the link-layer implementation can
+ indicate four kinds of packets: COMPRESSED_TCP for format a) in
+ section 6, COMPRESSED_TCP_NODELTA for format b), COMPRESSED_NON_TCP
+ for formats c) and d), and CONTEXT_STATE as described in section
+ 11.2. It is also desirable to indicate FULL_HEADERS at the link
+ layer.
+
+ Full headers can be indicated by setting the first bit of the Version
+ field in a packet indicated to be an IPv6 packet. In addition, one
+ bit of the Version field is used to indicate if the first subheader
+ is an IPv6 or an IPv4 header, and one bit is used to indicate if this
+ full header carries a TCP CID or a non-TCP CID. The first four bits
+ are encoded as follows:
+
+ Version Meaning
+ ------- -------
+
+ 0110 regular IPv6 header
+
+ 1T*0 T=1 indicates a TCP header, T=0 indicates a non-TCP header
+ 1*V0 V=1 indicates a IPv6 header, V=0 indicates a IPv4 header
+
+ If a link-layer cannot indicate the packet types for the compressed
+ headers or CONTEXT_STATE, packet types that cannot be indicated could
+ start with an octet indicating the packet type, followed by the
+ header.
+
+
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 41]
+
+RFC 2507 IP Header Compression February 1999
+
+
+ First octet Type of compressed header
+ ----------- -------------------------
+
+ 0 COMPRESSED_TCP
+ 1 COMPRESSED_TCP_NODELTA
+ 2 COMPRESSED_NON_TCP
+ 3 CONTEXT_STATE
+
+ The currently assigned CONTEXT_STATE type values are
+
+ Value Type Reference
+ ----- ----- ----------
+ 0 Reserved -
+ 1 IP/UDP/RTP w. 8-bit CID [CRTP]
+ 2 IP/UDP/RTP w. 16-bit CID [CRTP]
+ 3 TCP header request Section 10.2
+
+14. Configuration Parameters
+
+ Header compression parameters are negotiated in a way specific to the
+ link-layer implementation. Such procedures for link-layer xxx needs
+ to be specified in a document "IP header compression over xxx". Such
+ a document exists for PPP [PPP-HC].
+
+ The following parameter is fixed for all implementations of this
+ header compression scheme.
+
+ MIN_WRAP - minimum time of generation value wrap around
+
+ 3 seconds.
+
+ The following parameters can be negotiated between the compressor and
+ decompressor. If not negotiated their values must be as specified by
+ DEFAULT.
+
+ F_MAX_PERIOD - Largest number of compressed non-TCP headers that
+ may be sent without sending a full header.
+
+ DEFAULT is 256
+
+ F_MAX_PERIOD must be at least 1 and at most 65535.
+
+
+ F_MAX_TIME - Compressed headers may not be sent more than
+ F_MAX_TIME seconds after sending last full header.
+
+ DEFAULT is 5
+
+
+
+
+Degermark, et. al. Standards Track [Page 42]
+
+RFC 2507 IP Header Compression February 1999
+
+
+ F_MAX_TIME must be at least 1 and at most 255.
+
+ NOTE: F_MAX_PERIOD and F_MAX_TIME should be lower when it is
+ likely that a decompressor loses its state.
+
+
+ MAX_HEADER - The largest header size in octets that may
+ be compressed.
+
+ DEFAULT is 168 octets, which covers
+
+ - Two IPv6 base headers
+ - A Keyed MD5 Authentication Header
+ - A maximum-sized TCP header
+
+ MAX_HEADER must be at least 60 octets and
+ at most 65535 octets.
+
+
+ TCP_SPACE - Maximum CID value for TCP.
+
+ DEFAULT is 15 (which gives 16 CID values)
+
+ TCP_SPACE must be at least 3 and at most 255.
+
+
+ NON_TCP_SPACE - Maximum CID value for non-TCP.
+
+ DEFAULT is 15 (which gives 16 CID values)
+
+ NON_TCP_SPACE must be at least 3 and at most 65535.
+
+
+ EXPECT_REORDERING - The mechanisms in section 11 are used.
+
+ DEFAULT no.
+
+15. Implementation Status
+
+ A prototype using UDP as the link layer has been operational since
+ March 1996. A NetBSD implementation for PPP has been operational
+ since October 1996.
+
+
+
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 43]
+
+RFC 2507 IP Header Compression February 1999
+
+
+16. Acknowledgments
+
+ This protocol uses many ideas originated by Van Jacobson in the
+ design of header compression for TCP/IP over slow-speed links [RFC-
+ 1144]. It has benefited from discussions with Stephen Casner and
+ Carsten Bormann.
+
+ We thank Craig Partridge for pointing out a problem that can occur
+ when the TCP window scale option is used. A solution to this problem
+ relying on the packet sequence numbers used for reordering is
+ described in section 11.2.
+
+17. Security Considerations
+
+ The compression protocols in this document run on top of a link-layer
+ protocol. The compression protocols themselves introduce no new
+ additional vulnerabilities beyond those associated with the specific
+ link-layer technology being used.
+
+ Denial-of-service attacks are possible if an intruder can introduce
+ (for example) bogus Full Header packets onto the link. However, an
+ intruder having the ability to inject arbitrary packets at the link-
+ layer in this manner raises additional security issues that dwarf
+ those related to the use of header compression.
+
+ We advise implementors against identifying packet streams with the
+ aid of information that is encrypted, even if such information
+ happens to be available to the compressor. Doing so may expose
+ traffic patterns.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 44]
+
+RFC 2507 IP Header Compression February 1999
+
+
+18. Authors' Addresses
+
+ Mikael Degermark
+ Department of Computer Science and Electrical Engineering
+ Lulea University of Technology
+ SE-971 87 Lulea, Sweden
+
+ Phone: +46 920 91188
+ Fax: +46 920 72831
+ Mobile: +46 70 833 8933
+ EMail: micke@sm.luth.se
+
+
+ Bjorn Nordgren
+ CDT/Telia Research AB
+ Aurorum 6
+ S-977 75 Lulea, Sweden
+
+ Phone: +46 920 75400
+ Fax: +46 920 75490
+ EMail: bcn@lulea.trab.se, bcn@cdt.luth.se
+
+
+ Stephen Pink
+ Department of Computer Science and Electrical Engineering
+ Lulea University of Technology
+ SE-971 87 Lulea, Sweden
+
+ Phone: +46 920 752 29
+ Fax: +46 920 728 31
+ Mobile: +46 70 532 0007
+ EMail: steve@sm.luth.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 45]
+
+RFC 2507 IP Header Compression February 1999
+
+
+19. References
+
+ [RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC-793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, September 1981.
+
+ [RFC-1144] Jacobson, V., "Compressing TCP/IP Headers for Low-
+ Speed Serial Links", RFC 1144, February 1990.
+
+ [RFC-1553] Mathur, A. and M. Lewis, "Compressing IPX Headers
+ Over WAN Media (CIPX)", RFC 1553, December 1993.
+
+ [RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD
+ 2, RFC 1700, October 1994. See also:
+ http://www.iana.org/numbers.html
+
+ [RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header",
+ RFC 2402, November 1998.
+
+ [RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
+ Protocol (ESP)", RFC 2406, November 1998.
+
+ [RFC-1828] Metzger, W., "IP Authentication using Keyed MD5", RFC
+ 1828, August 1995.
+
+ [IPv6] Deering, S. and R. Hinden, "Internet Protocol,
+ Version 6 (IPv6) Specification", RFC 2460, December
+ 1998.
+
+ [ICMPv6] Conta, A. and S. Deering, "Internet Control Message
+ Protocol (ICMPv6) for the Internet Protocol Version 6
+ (IPv6) Specification.", RFC 2463, December 1998.
+
+ [RFC-2004] Perkins, C., "Minimal Encapsulation within IP", RFC
+ 2004, October 1996.
+
+ [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
+ Headers for Low-Speed Serial Links", RFC 2508,
+ February 1999.
+
+ [PPP-HC] Engan, M., Casner, S. and C. Bormann, "IP Header
+ Compression for PPP", RFC 2509, February 1999.
+
+
+
+
+Degermark, et. al. Standards Track [Page 46]
+
+RFC 2507 IP Header Compression February 1999
+
+
+20. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. .fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degermark, et. al. Standards Track [Page 47]
+