WDIFF

draft-degermark-ipv6-hc-01.txt --> draft-degermark-ipv6-hc-02.txt

Network Working Group Mikael Degermark /Lulea University
INTERNET-DRAFT Bjorn Nordgren
Expires December 18, 1996 Stephen Pink
Lulea Technical University
Telia /Telia Research AB
Swedish
Expires: May 1997 Stephen Pink /Swedish Institute of Computer Science
Sweden
June 13,
November 26, 1996

Header Compression for IPv6
<draft-degermark-ipv6-hc-01.txt>
<draft-degermark-ipv6-hc-02.txt>

Status of this Memo

Publication of this document does not imply acceptance by the IPng
Area of any ideas expressed within. Comments should be submitted to
the mailing list ipng@sunroof.eng.sun.com .

Distribution of this memo is unlimited.

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This document describes how to compress IPv6 headers per-hop over point-to-
point
point-to-point links. The method methods can be applied to IPv6 base and
extension headers, IPv4 headers, TCP and UDP headers, and
encapsulated IPv6 and IPv4 headers.

Headers of typical IPv6/UDP header UDP or TCP packets can be compressed down to 4 4-7
octets including the 2 byte UDP checksum. A typical IPv6/TCP header can be
compressed down to 4-6 bytes including the or TCP checksum. This largely
removes the negative impact of large headers and allows efficient use
of bandwidth on low- and medium-speed links.

Degermark, Nordgren, Pink [Page 1]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

TABLE OF CONTENTS
1. Introduction..............................................3
2. Terminology...............................................5
3. Compression method........................................7
3.1. Packet types.......................................7
3.2. Lost packets in TCP packet streams.................7
3.2. streams.................8
3.3. Lost packets in UDP and non-TCP packet streams.....8
3.2.1. Compression Slow-Start........................9
3.2.2. Periodic Header Refreshes.....................9
3.2.3. Rules for sending Full Headers...............10
3.2.4. Cost of sending Header Refreshes.............11 streams.....9
4. Grouping packets into packet streams.....................13
4.1. Guidelines for grouping packets...................13 packets...................14
5. Size Issues..............................................15 Issues..............................................16
5.1. Compression identifiers...........................15 identifiers...........................16
5.2. Size of compression state.........................16
5.3. Size of full headers..............................16 headers..............................17
5.3.1. Length fields in full TCP headers............18
5.3.2. Length fields in full non-TCP headers........18
6. Compressed Header Formats................................19
7. Compression of subheaders................................21
7.1. IPv6 Header.......................................23
7.2. IPv6 Extension Headers............................23
7.3. Options...........................................24
7.4. Hop-by-hop Options Header.........................25
7.5. Routing Header....................................26
7.6. Fragment Header...................................28 Header...................................27
7.7. Destination Options Header........................29 Header........................28
7.8. No Next Header....................................29 Header....................................28
7.9. Authentication Header.............................30 Header.............................29
7.10. Encapsulating Security Payload Header.............31 Header.............29
7.11. UDP Header........................................31 Header........................................30
7.12. TCP Header........................................32 Header........................................31
7.13. IPv4 Header.......................................33
8. Changing compression identifiers.........................35 identifiers.........................34
9. Rules for dropping or temporarily storing packets........36 packets........35
10. Low-loss header compression for TCP .....................37 .....................36
10.1. The twice algorithm..............................37 algorithm..............................36
10.2. Header Requests..................................38 Requests..................................37
11. Links that reorder packets...............................39 packets...............................38
11.1. Reordering in non-TCP packet streams.............39 streams.............38
11.2. Reordering in TCP packet streams.................39 streams.................38
12. Demultiplexing...........................................41 Hooks for additional header compression..................40
13. Demultiplexing...........................................41
14. Configuration Parameters.................................42
14.
15. Implementation Status....................................44
15.
16. Acknowledgments..........................................44
15.
17. Security Considerations..................................44
16.
18. Author's Addresses.......................................44
17.
19. References...............................................45

Degermark, Nordgren, Pink [Page 2]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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 as suggested by Oran, Casner, and Jacobson
in section 5 of [CRTP].

* 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. Tunneling or routing headers, for
example to support mobility, will increase the bandwidth
consumed by headers by at least 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.

Degermark, Nordgren, Pink [Page 3]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

A common size of TCP segments for bulk transfers over medium-
speed links is 512 bytes. octets today. When TCP segments are
tunneled, for example because Mobile IP is used, the header is
100 bytes. octets. Header compression will decrease the header
overhead from 19.5 per cent to about 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
bytes 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 IP
header overhead from 7.1% to 0.4%.

* Reduce packet loss rate over lossy links.

Degermark, Nordgren, Pink [Page 3]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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 mechanisms
that increase the efficiency of VJ header compression over lossy
links are also described. For non-TCP packets, compression slow-start slow-
start and periodic header refreshes allow minimal periods of packet
discard after loss of a header that changes the compression state.
There are hooks for adding header compression schemes for headers of
protocols layered on top of UDP, for example compressed RTP now being
developed by Casner and Jacobson.

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
full header and may contain incremental changes to the full header.

Degermark, Nordgren, Pink [Page 4]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

2. Terminology

This section explains some terms used in this document.

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
compression state is identical to the compression state used
when compressing the header.

Decompress

The act of reconstructing a compressed header.

Compression identifier (CID)

A small unique number identifying the compression state that
should be used to decompress a compressed header. Carried in
full headers and compressed headers.

Compression state

The state which the compressor uses to compress a header and
the decompressor uses to decompress a header. The compression
state 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 compression state for a packet stream is associated with a
compression identifier. The compression state for non-TCP
packet streams is also associated with a generation.

Degermark, Nordgren, Pink [Page 5]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

Generation

For non-TCP packet streams, each new version of the compression
state for a given CID is associated with a generation: a small
number that is incremented whenever the compression state
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
compression state. 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
compression state for a packet stream. It carries a CID that
will be used to identify the compression state.

Full headers for non-TCP packet streams also carry the
generation of the compression state they update or refresh.

Regular header

A normal, uncompressed, header. Does not carry CID or
generation association.

Incorrect decompression

When a compressed and then decompressed header is different
from the uncompressed header. Usually due to mismatching
compression state 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 compression state. This technique is
used for TCP streams but not for non-TCP streams.

Degermark, Nordgren, Pink [Page 6]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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 compression identifier, CID, is transmitted over
the link. The compressor and decompressor store most fields of this
full header as compression state. The compression state 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 compression state at the decompressor. As long as the
compression state 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 damaged or lost during
transmission, the compression state of the decompressor may become
obsolete as it is not updated properly. Compressed headers will then
be decompressed incorrectly.

So a header compression scheme

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 checksums, forward error correction
or something of that nature. Damaged 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
compression state 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.1 3.2 and 3.2. 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

Degermark, Nordgren, Pink [Page 7]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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 compression state 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
compression state to use for decompression, a generation to detect
inconsistent compression state and the randomly changing fields of
the header.

COMPRESSED_TCP - indicates a packet with a compressed TCP header,
containing a CID, a flag byte indentifying what fields have
changed, and the changed fields encoded as the difference from the
previous value.

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 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 will be used whenever a compressor decides to not
compress a packet.

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 compression state 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

Degermark, Nordgren, Pink [Page 7] 8]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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.

3.2.

The mechanisms of section 10 should be used to speed up the repair of
the compression state. 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 compression state
after each packet lost over the link is not acceptable, especially
when the TCP connection is over the wide area.

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 because
differential coding is not used and there are no sequence numbers.
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 compression state 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 compression state.
Compressed headers carry the generation value of the compression
state that were used to compress them. When a decompressor sees that
a compressed header carries a generation value other than the
generation of its compression state for that packet stream, the
compression state is not up to date and the packet must be discarded
or stored until a full header establishes correct compression state.

Differential coding is not used for non-TCP streams, so compressed
non-TCP headers do not change the compression state. Thus, loss of a
compressed header does not invalidate subsequent packets with
compressed headers. Moreover, the generation field changes only when
the compression state of a full header is different from the
compression state of the previous full header. This means that losing

Degermark, Nordgren, Pink [Page 9]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

a full header will make the compression state of the decompressor
obsolete only when the full header would actually have changed the
compression state.

The generation field is 7 6 bits long so the generation value repeats
itself after 128 64 changes to the compression state. To avoid incorrect
decompression after error bursts or other temporary disruptions, the

Degermark, Nordgren, Pink [Page 8]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996
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 else send regular headers until MIN_WRAP seconds have
passed. The value of MIN_WRAP is found in section 12.

3.2.1. 14.

3.3.1. Compression Slow-Start

To allow the decompressor to recover quickly from loss of a full
header that would have changed the compression state, full headers
are sent periodically with an exponentially increasing period after a
change in the compression state. 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 repeated switching between sending
and receiving. Moreover, techniques that require an exchange of
messages cannot be used over simplex links, such as direct-
broadcast direct-broadcast
satellite channels or cable TV systems, and are hard to adapt to multicast.
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 compression state changes, a full header is sent and F_PERIOD is
set to one. After sending F_PERIOD compressed headers headers, a full header
is sent, and sent. F_PERIOD is doubled each time a full header is sent.

3.2.2. sent during
compression slow-start.

3.3.2. Periodic Header Refreshes

To avoid losing too many packets if a receiver has lost its
compression state, there is an upper limit, F_MAX_PERIOD, on the

Degermark, Nordgren, Pink [Page 10]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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

Degermark, Nordgren, Pink [Page 9]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996
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 12.

3.2.3. 14.

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() and send_compressed_header()
do the obvious thing.

if ( <this header changes the compression state> )

C_NUM := 0;
F_LAST := current_time();
F_PERIOD := 1;
send_full_header(); -- generation value incremented

elseif ( C_NUM >= F_PERIOD )

C_NUM := 0;
F_LAST := current_time();
F_PERIOD := min(2 * F_PERIOD, F_MAX_PERIOD);
send_full_header(); -- generation value unchanged

elseif ( current_time() > F_LAST + F_MAX_TIME )

C_NUM := 0;
F_LAST := current_time();

Degermark, Nordgren, Pink [Page 11]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

send_full_header(); -- generation value unchanged

else

C_NUM := C_NUM + 1
send_compressed_header(); -- with current generation value

endif

Degermark, Nordgren, Pink [Page 10]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

3.2.4.

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 a byte 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 12) 14) puts the full
header frequency well to the right of the knee and means that full
headers will typically contribute considerably less than a byte 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 compression state, 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, size when H = 48 and C = 4. For 20 ms voice
samples, it takes less than 1.3 seconds until full headers contribute

Degermark, Nordgren, Pink [Page 12]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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, Nordgren, Pink [Page 11]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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 compression state 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 our 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 we feel that 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 and multicast.

Degermark, Nordgren, Pink [Page 12]

INTERNET-DRAFT Header Compression links, for IPv6 June 13, 1996 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, the
header compression performance will be bad, since the compression
algorithm can rarely utilize the existing compression state 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
might

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,

Degermark, Nordgren, Pink [Page 13]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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,

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 sender 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 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 the absence of specific instructions as to which packet streams to
compress, we offer the following quidelines for how a compressor may
group packets into packet streams for compression.

Degermark, Nordgren, Pink [Page 13]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

Defining fields

All fields in subheaders that are marked with DEF in section 7
should be present and identical in all packets belonging to the
same packet stream. The DEF marked fields include the flow
label, source and destination addresses of IP headers, final
destination address in routing headers, the next header field
preceding a UDP or TCP header, port numbers, and the SPI in
authentication and encryption headers.

Fragmented packets

Fragmented and unfragmented packets are never grouped together
in the same packet stream. The Identification field of the
Fragment header or IPv4 header is not 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

Degermark, Nordgren, Pink [Page 14]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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.

TTL field

A sophisticated implementation can monitor the TTL field and if
it changes frequently use it as a DEF field. This might occur
when there are frequent route flaps so that packets traverse
different paths through the internet.

Priority field

It is concievable that the Priority field of the IPv6 header
can change between packets with identical DEF fields when the
Flow Label is zero. A sophisticated implementation can watch
out for this and be prepared to use the Priority field as a DEF
field.

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

Degermark, Nordgren, Pink [Page 14]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996
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 in the compression state.

We stress that these guidlines are only 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 and not
incorrect decompression. The decompressor can do its task regardless
of how the grouping algorithm works.

Degermark, Nordgren, Pink [Page 15]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

5. Size Issues

5.1. Compression Identifiers

Compression identifiers can be 8 or 24 16 bits long. Their size is not
relevant for finding the compression state. An 8-bit CID with value
two and an 24-bit 16-bit CID with value two are equivalent.

The CID spaces for TCP and non-TCP are separate, so a TCP CID and a
non-TCP CID never identify the same compression state, 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 first byte of the compressed header. The 8-bit CID allows a
minimum compressed header size of 2 octets for non-TCP packets, the
size bit and the 7-bit 6-bit Generation value fit in the first octet and
the CID uses the second octet.

For TCP the only available CID size is 8 bits. 8 bits is probably
sufficient as TCP connections are always point-to-point.

The 24 16 bit CID size is probably not 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

Degermark, Nordgren, Pink [Page 15]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996 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 Compression State

The size of the compression state 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 compression state is
essentially a stored header.

Degermark, Nordgren, Pink [Page 16]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

The configurable parameter MAX_HEADER (see section 12) 14) represents the
maximum size of the compression state, expressed as the maximum sized
header that can be stored as compression state. When an IPv6 header
is larger than MAX_HEADER, only part of it is stored as compression
state. An implementation must not compress more than the initial
MAX_HEADER octets of a header. An implementation must not partially
compress a subheader. Thus, the part of the header that is stored as
compression state and is compressed is the longest initial sequence
of entire subheaders that is not larger than MAX_HEADER.

NOTE: We are not totally happy with this solution since most of
the [MAX_HEADER * (size of CID spaces)] sized memory is wasted
if headers are small. We are investigating other solutions to
the problem of specifying tight memory requirements while
allowing correct decompression and a low number of packet
discards. 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

Degermark, Nordgren, Pink [Page 16]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996
added after UDP data or in tunneled packets so that the values of
lenght
length fields can 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 3 2
octets. Length fields of 2 octets occur 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
IPv6 base header to pass the 8 bit CID, which is sufficient. [RFC-
1144] uses the 8 bit Protocol field of the IPv4 header to pass the
CID. We cannot use the corresponding method for IPv6 as the sequence
of 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 all both CID sizes may be used for non-TCP packet streams. used.

The 7-bit 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

Degermark, Nordgren, Pink [Page 17]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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, Nordgren, Pink [Page 17]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

5.3.1. Length Use of length fields in full TCP headers

Full TCP headers with one

Use of first length field:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length field | LSB of pkt nr | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Full TCP headers with two or more length fields:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First

Use of second length field | LSB of pkt nr | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ if available:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | MSB of pkt nr | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

See section 11 for a description of how the pkt nr field is used.

5.3.2. Length Use of length fields in full non-TCP headers

Full non-TCP headers with 1 octet CID field: 8-bit CID:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |0| Generation | |0|D| Generation| CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field (if avail.) | 0 | Data (if D=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Full non-TCP headers with 3 octet CID field: 16-bit CID:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |1| Generation | MSB of CID |1|D| Generation| Data (if D=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | two lowest octets of CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first bit inthe 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, Nordgren, Pink [Page 18]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

6. Compressed Header Formats

This section uses some terminology (DELTA, RANDOM) defined in section
7.

a) Compressed TCP header COMPRESSED_TCP format (same as (similar to [RFC 1144]):

+-+-+-+-+-+-+-+-+- - - - - - - -

The latter flags in the first second byte (CIPSAWU) (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 compression state associated with the CID keeps track of
the IP version. version and what RANDOM fields are present. The order between
delta fields specified here is different from [RFC-1144].

The initial flag byte is followed by an 8-bit CID if An
implementation will typically scan the C flag compression state from the
beginning and insert the RANDOM fields in order. It is
set, after which thus simpler
if the RANDOM and DELTA fields of the subheaders follow occur in the same order as they occur
in the original uncompressed header.

The C-flag must always be set on links that can reorder packets.

The I flag is zero unless an IPv4 header is present as there is no
Identification field in the IPv6 header. If there are more than one
IPv4 header present, only the Identification field of the IPv4 header
closest to the TCP header is delta encoded, other Identification
fields are RANDOM. The delta of the Identification field is placed
among the RANDOM fields at the position corresponding to the IPv4
header.

Degermark, Nordgren, Pink [Page 19]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

If the I O flag is set, the delta Options of the IPv4 Identifier value is
placed at the position that corresponds to TCP header were not the place of same
as in the IPv4
subheader previous header. The entire Option field are placed last in
the uncompressed compressed TCP header. The first bit in the flag byte is
reserved. It is always zero.

See section 7.12 and [RFC-1144] for further information about on how to
compress TCP headers.

Degermark, Nordgren, Pink [Page 19]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

b) Compressed non-TCP header, 8 bit CID:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Generation COMPRESSED_TCP_NODELTA header format

+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| RANDOM fields, if any (see section 7) (implied)
+-+-+-+-+-+-+-+-+
| Whole TCP header except for Port Numbers
+-+-+-+-+-+-+-+-+

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)
- - - - -

c) - - -

d) Compressed non-TCP header, 24 16 bit CID:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Generation
0 7
+-+-+-+-+-+-+-+-+
| msb of CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|1|D| Generation|
+-+-+-+-+-+-+-+-+
| RANDOM fields, if any (see section 7) lsb of CID |
+-+-+-+-+-+-+-+-+
| data | (if D=1)
- - - - - - - -
| RANDOM fields, if any (section 7) (implied)
- - - - - - - -

Compressed non-TCP headers

The generation, CID and optional one byte 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.

Degermark, Nordgren, Pink [Page 20]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

7. Compression of subheaders

This section gives rules for how the compressible chain of subheaders
is compressed. Subheaders that may be compressed include IPv6 base
and extension headers, TCP headers, UDP headers, and IPv4 headers.
The compressible chain of subheaders extends from the beginning of
the header

a) up to but not including the first header that is not an IPv4
header, an IPv6 base or extension header, a TCP header, or a UDP
header, or

b) up to and including the first TCP header, UDP header, Fragment
Header, Encapsulating Security Payload Header, or IPv4 header for
a fragment,

whichever gives the shorter chain. For example, rules a) and b) both
fit a chain of subheaders that contain a Fragment Header and ends at
a tunneled IPX packet. Since rule b) gives a shorter chain, the
compressible chain of subheaders stops at the Fragment Header.

The following subsections are a systematic classification of how all
fields in subheaders are expected to change.

NOCHANGE The field is not expected to change. Any change means
that a full header must be sent to update the compression
state.

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 not used for non-TCP packet streams.

RANDOM The field should 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 need not be included in the
compressed header.

Degermark, Nordgren, Pink [Page 21]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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
compression state 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 adds the value in
the compressed header to the value in its compression state to obtain
the proper value. RANDOM fields are sent "as-is" in the compressed
header. DELTA and RANDOM fields occur in the same order in the
compressed header as they occur in the full header.

There is currently little experience with actual IPv6 traffic, so
this classification may change as IPv6 traffic can be observed.

Fields that may 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 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, Nordgren, Pink [Page 22]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

7.1. IPv6 Header [IPv6, section 3]

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version NOCHANGE (DEF)
Prio NOCHANGE
Flow Label NOCHANGE (DEF)
Payload Length INFERRED
Next Header NOCHANGE
Hop Limit NOCHANGE
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 cannot be compressed.

This classification implies that the whole IPv6 base header can be
compressed away.

7.2. IPv6 Extension Headers [IPv6, section 4]

What extension headers are present and the relative order of them is
not expected to change in a packet stream. Whenever there is a
change, a full packet header must be sent. All Next Header fields in
IPv6 base header and IPv6 extension headers are NOCHANGE.

Degermark, Nordgren, Pink [Page 23]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

7.3. Options [IPv6, section 4.2]

The contents of Hop-by-hop Options and Destination Options extension
headers are encoded with TLV "options":

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 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, Nordgren, Pink [Page 24]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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.

Degermark, Nordgren, Pink [Page 25]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

7.5. Routing Header [IPv6, section 4.4]

All fields of the Routing Header are NOCHANGE.

If the Routing Type is not recognized, it is impossible to determine
the final Destination Address unless the Segments Left field has the
value zero, in which case the Destination Address is the final
Destination Address. For unknown routing types, all fields of the
Routing Header are NOCHANGE.

If the Flow Label is zero and the Segments Left field is not zero,
the packet stream can be identified only when the Routing Type is 0, Address in the only Routing Type currently defined.

The fields of basic IPv6 header.

In the Type 0 Routing Header are classified as follows:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type=0| Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Strict/Loose Bit Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[1] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[2] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .

Degermark, Nordgren, Pink [Page 26]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[n] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header NOCHANGE
Routing Type NOCHANGE
Hdr Ext Len NOCHANGE
Segments Left NOCHANGE

Reserved NOCHANGE

Strict/Loose Bit Mask
NOCHANGE

Address[1..n] NOCHANGE
(Address[n] Header, the last address is DEF if (Segments
Left > 0))

This classification allows 0).

Routing Headers of type 0 to be 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.

Degermark, Nordgren, Pink [Page 27] 26]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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 (it is never compressed away)

This classification implies that a Fragment Header is compressed down
to 6 octets. The minimum IPv6 MTU is 576 octets so most fragments
will be at least 576 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.

Degermark, Nordgren, Pink [Page 28] 27]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

Grouping of fragments according to the guidelines in section 4.1 4.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 hope 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 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. When further Destination Options are defined, more clever
compression techniques may be defined.

7.8. No Next Header [IPv6, section 4.7]

Covered by rules for IPv6 Header Extensions (7.2).

Degermark, Nordgren, Pink [Page 29] 28]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

7.9. Authentication Header [RFC-1826, 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 128 bits. These 128 bits are
sent "as-is" in compressed headers and thus increase the size of must support. For
this method, the
compressed header by Authentication Data is 16 octets. This is typically more than a 300%
increase in the size of the compressed header.

Degermark, Nordgren, Pink [Page 30]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

7.10. Encapsulating Security Payload Header [RFC-1827, 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 should must
also be used, as packets are likely to be reordered in a tunnel.

+---------------+---------------+---------------+---------------+
| Security Association Identifier (SPI), 32 bits |
+===============+===============+===============+===============+
| Opaque Transform Data, variable length |
+---------------+---------------+---------------+---------------+

SPI NOCHANGE (DEF)
Opaque Transform Data RANDOM

Everything after the SPI is encrypted, encrypted and is not compressed.

Degermark, Nordgren, Pink [Page 29]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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 NOCHANGE (DEF)
Destination Port NOCHANGE (DEF)
Length INFERRED
Checksum RANDOM 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. The
Length field of When the UDP header must correspond checksum is zero (which it cannot be with
IPv6), it is likely to be so for all packets in the Length field(s)
of preceding subheaders. flow and is
defined to be NOCHANGE. This saves 2 octets in the compressed header.

Degermark, Nordgren, Pink [Page 31] 30]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

7.12. TCP Header

The TCP header is described in [RFC-793].

The Next Header field (IbPv6) or Protocol field (IPv4) in the
preceding subheader is DEF.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset| Reserved |U|A|P|R|S|F| Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U, A, P, R, S, and F stands for Urg, Ack, Psh, Rst, Syn, and Fin.

There are two ways to compress the TCP header. One uses

7.12.1. Compressed with differential encoding

Source Port NOCHANGE (DEF)
Destination Port NOCHANGE (DEF)
Sequence Number DELTA
Acknowledgment Number DELTA
Offset NOCHANGE
Reserved NOCHANGE
Urg,Psh RANDOM (placed in flag byte)
Ack INFERRED to be 1
Rst,Syn,Fin INFERRED to be 0
Window DELTA (if change in Window,
set W-flag in flag byte
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)

Degermark, Nordgren, Pink [Page 31]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

A packet with a TCP header compressed according to the above must be
indicated to be of type COMPRESSED_TCP. The compressed header is
described in section 6.

This method is essentially the differential encoding techniques of
Jacobsson, described in [RFC-
1144], [RFC-1144], the only difference differences being the
placement of the compressed TCP header fields (see section 6). 6), the
use of the O-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.

7.12.2. Without differential encoding

Source Port NOCHANGE (DEF)
Destination Port NOCHANGE (DEF)
Sequence Number DELTA
Acknowledgment Number DELTA
Offset INFERRED
Reserved NOCHANGE
U,A,P,R,S,F see [RFC-1144]
WINDOW DELTA, see [RFC-1144]
Checksum

(all the rest) RANDOM
Urgent Pointer see [RFC-1144]
Options see [RFC-1144]
Padding NOCHANGE

The other method classifies

A packet with a TCP header compressed according to the Source Port and Destination Port above must be
indicated to be of type COMPRESSED_TCP_NODELTA. It uses the same CID
space as
NOCHANGE COMPRESSED_TCP packets, and the rest of the TCP header fields as RANDOM. This is a
simple way to deal with links that reorder. saved as
compression state. The packet stream compressed header is
considered to described in section 6.

This packet type can be sent as the response to a non-TCP packet stream (!), so header request
instead of sending a non-TCP CID should full header, can be used over links that reorder
packets, and format b), c), or d) must can be used for the compressed
header. The rules for sending sent instead of a full headers in section 3.2.3 apply.

Section 11 describes header when there are
changes that cannot be represented by a method compressed header. A
sophisticated compressor can switch to deal with reordering that sending only adds
two bytes to compressed headers.
COMPRESSED_TCP_NODELTA headers when the packet loss frequency is
high.

Degermark, Nordgren, Pink [Page 32]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

7.13. IPv4 header [RFC-791, section 3.1]

As we expect many IPv6 packets to be encapsulated in IPv4 packets,
and many IPv4 packets to be encapsulated in IPv6 packets, it is
important to be able to compress IPv4 headers.

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
Total Length INFERRED (from link-layer implementation
or encapsulating IP header)

Identification DELTA/ (for TCP)
RANDOM
NOCHANGE/ (for non-TCP) UDP when UDP Checksum = 0)
RANDOM (otherwise)

Flags NOCHANGE (MF bit flag must not be set)
Fragment Offset NOCHANGE (must be zero)
Time to Live NOCHANGE
Protocol NOCHANGE
Header Checksum INFERRED (calculated from other fields)
Source Address NOCHANGE (DEF)
Destination Address NOCHANGE (DEF)
Options, Padding (not present)

Degermark, Nordgren, Pink [Page 33]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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., they are sent as-is and not compressed). If the
IPv4 header is for a fragment it ends the compressible chain of
subheaders, i.e., it is 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
will be compressed.

A compressor that follows the 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, the compressor uses
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. The compressor uses that fact, but not the size of the
options, together with the Version, Source Address, and Destination
Address to determine the packet stream.

Degermark, Nordgren, Pink [Page 34]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

8. Changing compression identifiers

On a point-to-point link, the compressor has total knowledge of what
CIDs are in use at the decompressor and can change what CID a packet
stream uses or reuse CIDs at will. To get the highest possible
compression rate, 4-bit CIDs should be allocated to the non-TCP
packet streams with the highest packet rates. However, changing a decompressor and can change what CID to a new packet
stream involves paying the cost of uses or reuse CIDs at least one
exponential backoff, so it should not be done too frequently. will.

Each non-TCP CID is associated with a compression state 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 12). 14).

To aid in avoiding wrap-around, the generation value associated with
a non-TCP CID should must not be maintained reset when changing a CID to a new packet stream. A
Instead, a compressor must increment the generation value by one when switching to a new non-TCP packet stream.

An implementation must not reset
using the generation value when allocating
a CID to for a new non-TCP packet stream.

Degermark, Nordgren, Pink [Page 35] 34]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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 compression state 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 compression state when

a) the decompressor has been disconnected from the compressor for
more than MIN_WRAP seconds, because the compression state might
be obsolete even if it has generation G.

b) the compression state for C has a generation other than G.

In case a) and b) the packet can either be

i) discarded immediately, or else

ii) stored temporarily until the compression state 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 may receive compressed
non-TCP headers with a generation value other than the generation of
its compression state. Rule ii) allows the decompressor to store
such headers until they can be decompressed using correct compression
state.

Degermark, Nordgren, Pink [Page 36] 35]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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 compression state 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.
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, can will then have
poor performance with traditional header compression because the sending window
delay-bandwidth product is relatively large and the bit-error rate
relatively high. For a 2 Mbit/s wireless LAN and a RTT of 200 ms, the
delay-bandwidth product is 50 kbyte. That is equivalent to about 97
512-byte 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
compression state. With these mechanisms header compression will
improve TCP throughput over lossy links as well as links with low
bit-error rates.

10.1. The "twice" algorithm

The decompressor can compute the TCP checksum to determine if its
compression state is not updated properly. If the checksum fails, the
error is assumed to caused by a lost segment that did not update the
compression state properly. The delta of the current segment is then
added to the compression state 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
compression state 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 compression state for 99 - 53 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

Degermark, Nordgren, Pink [Page 36]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

observing the stream of full and compressed headers. Trying deltas
that are small multiples of the segment size will result in even
higher repair success rates for acknowledgment streams.

Degermark, Nordgren, Pink [Page 37]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

10.2. Header Requests

The relativley low success rate for the "twice" algorithm for TCP
acknowledgment streams calls for an additional mechanism for
repairing the compression state at the decompressor. When the
decompressor fails to repair the compression state after a loss, the
decompressor requests a full header from the compressor.

The most common configuration is likely to be that the TCP
acknowledgment and data streams pass through the same nodes on each
side of a lossy link such as wireless. a wireless link. There will then be a
compressor/decompressor pair on each side of the link.

Assume that an acknowledgement is damaged on the lossy link from node
A to node B. The link-level checksum detects the damaged frame and
discards it. Also, assume that the decompressor in node B fails to
repair its compression state when the next compressed acknowledgment
arrives. The decompressor in node B will then ask the compressor in
node B to set a bit in a full header in the corresponding TCP stream
going in the opposite direction, in this case the data stream. When
the decompressor in node A sees the bit, it asks its companion
compressor to send a full header in the packet stream with the
corresponding IP addresses and port numbers. The full header updates
the compression state for the decompressor in node B and
acknowledgments start to flow again.

In this manner the TCP acknowledgment stream is repaired after a
roundtrip-time over the lossy link. A wide-area TCP connection is not
likely to get a timeout signal during this time, link, and most of the window will get
through undamaged. The lower packet loss rate due to smaller packets
will then result in higher throughput because the TCP transfer window can continue without backing off. grow
larger between losses.

The header request mechanism will not work when routes are not
symmetric and the TCP streams do not visit the same nodes. This
situation is Such

Degermark, Nordgren, Pink [Page 37]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

situations are perfectly normal. Sending a header request is a hint
that it is a good idea to send a full header in the corresponding TCP
packet stream. However, header requests is only a performance
improving mechanism and it is safe to ignore such hints if no
corresponding TCP packet stream can be found. Compressors must

Degermark, Nordgren, Pink [Page 38]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996
silently ignore requests for full headers in TCP streams they are not
compressing. Decompressors must ignore requests for full headers when
they cannot contact a suitable compressor.

What bit to use for requesting a full header is specified in section
12.
13. The corresponding TCP stream going in the opposite direction is
identified by examining the source and final destination addresses of
the innermost IP header plus the TCP source and destination port
numbers. If one TCP stream has the values (SA1, DA1, SP1, DP1) in
these fields and another has the values (SA2, DA2, SP2, DP2), they
correspond to each other if and only if SA1 = DA2, DA1 = SA2, SP1 =
DP2, and DP1 = SP2.

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.

11.1. Reordering in non-TCP packet streams

Compressed non-TCP headers do not change the compression state, and
neither do full headers that refresh it. It is only when a full
header that changes the compression state arrives out of order that
there can be problems. 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
128). The decompressor can then keep both versions of the
compression state around for a while to be able to decompress
subsequent compressed headers with generation G-1 (modulo 128).
The old compression state must be discarded after MIN_WRAP
seconds.

11.2. Reordering in TCP packet streams

Section 7.12 describes a simple method to deal with

A compressor can avoid sending COMPRESSED_TCP headers and only send
COMPRESSED_TCP_NODELTA headers when there is reordering in TCP
streams. It requires using over the methods from 11.1

Degermark, Nordgren, Pink [Page 38]

INTERNET-DRAFT Header Compression for dealing with
reordering in non-TCP streams. IPv6 June 13, 1996

link. Compressed headers will typically be
18 17 bytes with that
method, which is significantly larger than the usual 4-6 4-7 bytes.

To achieve better compression rates the following method, adding only

Degermark, Nordgren, Pink [Page 39]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996
two bytes to the compressed header for a total of 6-8 6-9 bytes, can be
used. A packet sequence number, incremented by one for every packet
in the TCP stream, is associated with each compressed and full
header. This allows the decompressor to place the packets in the
correct sequence and it can apply their deltas to the compression state in
the correct order. A simple sliding window scheme can be used to
place the packets in the correct order.

Two bytes are needed for the packet sequence numbers. One byte 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 byte
segments. Delays of that order are not uncommon on multi-hop radio
links. over wide-are
Internet connections. However, two bytes giving 2^16 = 65536 values
should be sufficient.

Full TCP headers will only have space for one byte 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 byte of the packet
sequence number can be placed in such full headers. We believe that
such full headers can be positioned correctly frequently enough with
only the least significant byte of the packet sequence number
available. Experiments are needed to confirm this.

We skip over packet sequence numbers where the least significant byte
is zero. This allows the compressor to signal that it is adding

The packet sequence numbers to compressed headers by placing a value
other than number zero in a full header. is skipped over. Avoiding zero also 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 bytes of TCP data
is lost, a compressed header will be decompressed incorrectly without
being detected by the TCP checksum. TCP segments are usually often a power of
two. So by using a packet sequence number space that is not a power
of two either the sequence number or the packet sequence number will
differ when 2^16 bytes are lost. When 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 byte packet sequence number is
placed immediately after the CID. The CID must not be omitted when
packet sequence numbers are used. TCP Checksum. See section 5.3 for
placement of packet sequence numbers in full headers.

Degermark, Nordgren, Pink [Page 40] 39]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

12. Hooks for additional header compression

The following hook is supplied to allow additional header compression
schemes for headers of protocols layered above 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 would be Compressed RTP by
Jacobson and Casner [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 byte (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 byte mechanism is automatically enabled
whenever use of additional header compression schemes has been
negotiated.

Degermark, Nordgren, Pink [Page 40]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

13. Demultiplexing

It is necessary to distinguish packets with regular IPv4 headers,
regular IPv6 headers, full IPv6 packets, full IPv4 packets,
compressed TCP packets, and compressed non-TCP packets. It is also
desirable to find one bit for requesting a header refresh as
described in section 11.2. 10.2.

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.

IPv6 header compression requires that the link-layer implementation
can indicate two three new kinds of packets: COMPRESSED_TCP for format
a) in section 6, COMPRESSED_TCP_NODELTA for format b), and
COMPRESSED_NON_TCP for formats b) and c) in section
6. and d).

Full headers and header requests are indicated by special encodings of the first four
bits (Version field) in a packet indicated to be an IPv6 packet. packet by
the link layer. The first four bits are encoded as follows:

Version Type of header Meaning
------- ------- --------------

0110 regular IPv6 header

1100 full IPv4 header
1101 full IPv4

1T** T=1 indicates a TCP header, requests full header

1110 full IPv6 T=0 indicates a non-TCP header
1111 full
1*V* V=1 indicates a IPv6 header, V=0 indicates a IPv4 header
1**R R=1 requests a full header

If the link-layer cannot indicate these packet types, all packets
with compressed headers must start with a byte indicating the packet
type, followed by the compressed header.

First byte Type of compressed header
---------- -------------------------

00000000 compressed TCP header (format a) COMPRESSED_TCP
00000001 compressed non-TCP header (formats b or c) COMPRESSED_TCP_NODELTA
00000002 COMPRESSED_NON_TCP

Degermark, Nordgren, Pink [Page 41]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

13.

14. Configuration Parameters

The following parameters are 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 header refresh. 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 seconds

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 8-octet units) that may
be compressed.

DEFAULT is 25 (200 octets).

Minimum is 16 (128 21 (168 octets), which covers

- Two IPv6 Base Header
Routing Header with two addresses base headers
- A Keyed MD5 Authentication Header
Minimum TCP Header

TCP_SPACE
- Size of allowed CID space for TCP streams.

TCP_SPACE is the 2-logarithm of size of TCP CID space.

DEFAULT is 4, giving a maximum A maximum-sized TCP CID of 2^4-1 = 15

TCP_SPACE header

MAX_HEADER must be at least 2 13 (120 octets) and
at most 8. 125 (1000 octets).

TCP_SPACE - Maximum CID value for TCP.

DEFAULT is 15 (which gives 16 CID values)

Degermark, Nordgren, Pink [Page 42]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

TCP_SPACE must be at least 3 and at most 255.

NON_TCP_SPACE - Size of allowed Maximum CID space value for non-TCP streams.

NON_TCP_SPACE is the 2-logarithm of the size of the
non-TCP CID space. non-TCP.

DEFAULT is 4, giving a maximum non-TCP CID of 2^4-1 = 15 (which gives 16 CID values)

NON_TCP_SPACE must be at least 2 3 and at most 24.

ENABLE_CID_COMPRESSION - may TCP CIDs be compressed away?

DEFAULT no. 65535.

EXPECT_REORDERING - The mechanisms in section 11 are used.

DEFAULT no.

Degermark, Nordgren, Pink [Page 43]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

14.

15. Implementation Status

A prototype using UDP as the link layer has been operational since
March 1996. We will have a A NetBSD implementation for PPP for the
Montreal IETF meeting, and will issue a revised draft describing the
PPP specifics in July.

15. has been operational
since October 1996.

16. Acknowledgments

This protocol uses many ideas originated by Van Jacobson in the
design of header compression for TCP/IP [RFC-1144].

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.

16.

17. Security Considerations

We advise 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 would expose traffic patterns.

17.

18. Author's Addresses

Mikael Degermark Tel: +46 920 91188
CDT/Dept of Computer Science Fax: +46 920 72191 72801
Lulea University EMail: micke@sm.luth.se Mobile: +46 70 648 8121
S-971 87 Lulea, Sweden EMail: micke@sm.luth.se

Bjorn Nordgren Tel: +46 920 75400
CDT/Telia Research AB Fax: +46 920 75490
Aurorum 6 EMail: bcn@lulea.trab.se
S-977 75 Lulea, Sweden

Stephen Pink Tel: +46 8 752 15 59
CDT/Swedish Institute of Computer Science Fax: +46 8 751 72 30
PO Box 1263 Mobile: +46 70 532 0007
S-164 28 Kista, Sweden EMail: steve@sics.se

Degermark, Nordgren, Pink [Page 44]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

18.

19. References

[RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980.

[RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981.

[RFC-793] J. Postel, Transmission Control Protocol, RFC 793,
September 1981.

[RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed
Serial Links, RFC 1144, February 1990.

[RFC-1553] A. Mathur, M. Lewis, Compressing IPX Headers Over WAN
Media (CIPX), RFC 1553, December 1993.

[RFC-1700] J. Reynolds and J. Postel, Assigned Numbers, RFC-1700,
October 1994.

[RFC-1826] R. Atkinson, IP Authentication Header, RFC 1826, August
1995.

[RFC-1827] R. Atkinson, IP Encapsulating Security Protocol (ESP),
RFC 1827, August 1995.

[RFC-1828] Metzger, W. Simpson, IP Authentication using Keyed MD5,
RFC 1828, August 1995.

[IPv6] S. Deering, R. Hinden, Internet Protocol, Version 6
(IPv6) Specification, RFC 1883, December 1995.

[ICMPv6] A. Conta, S. Deering, Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6), RFC
1885, December 1995.

[CRTP] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links. Internet-Draft (Work in
progress), August 16, 1996. Expires February 1997.

This draft expires December 18, 1996 in May 1997

Degermark, Nordgren, Pink [Page 45]

----