WDIFF

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

Network Working Group M. Mikael Degermark
INTERNET-DRAFT B. Bjorn Nordgren
Expires August December 18, 1996 S. Stephen Pink
Lulea Technical University
Telia Research AB
Swedish Institute of Computer Science
Sweden
February
June 13, 1996

Header Compression for IPv6
<draft-degermark-ipv6-hc-00.txt>
<draft-degermark-ipv6-hc-01.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 over point-to-
point links. The method can be applied to IPv6 base and extension
headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and
IPv4 headers.

A typical IPv6 IPv6/UDP header can be compressed down to 3-5 octets, 4 octets
including
a 2 octet transport layer the UDP checksum. A typical IPv6/TCP header can be
compressed down to 4-6 bytes including the TCP checksum.

Degermark, Nordgren, Pink [Page 1]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

Table of Contents

TABLE OF CONTENTS
1. Introduction..............................................3
2. Terminology...............................................5
3. Compression method........................................7
3.1. Lost packets in TCP packet streams.................7
3.2. Lost packets in UDP and non-TCP packet streams.............8 streams.....8
3.2.1. Exponential Backoff of Header Refreshes.......9 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
4. Grouping packets into packet streams.....................13
4.1. Guidelines for grouping packets...................13
5. Size Issues..............................................16 Issues..............................................15
5.1. Compression identifiers...........................16 identifiers...........................15
5.2. Size of compression state.........................17 state.........................16
5.3. Size of full headers..............................18 headers..............................16
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
7.7. Destination Options Header........................30 Header........................29
7.8. No Next Header....................................30 Header....................................29
7.9. Authentication Header.............................31 Header.............................30
7.10. Encapsulating Security Payload Header.............32 Header.............31
7.11. UDP Header........................................33 Header........................................31
7.12. TCP Header........................................34 Header........................................32
7.13. IPv4 Header.......................................35 Header.......................................33
8. Changing compression identifiers.........................37 identifiers.........................35
9. Rules for dropping or temporarily storing packets....................38 packets........36
10. More aggressive compression..............................39 Low-loss header compression for TCP .....................37
10.1. The twice algorithm..............................37
10.2. Header Requests..................................38
11. Demultiplexing...........................................40 Links that reorder packets...............................39
11.1. Reordering in non-TCP packet streams.............39
11.2. Reordering in TCP packet streams.................39
12. Configuration Parameters.................................41 Demultiplexing...........................................41
13. Security Considerations..................................43 Configuration Parameters.................................42
14. Author's Addresses.......................................43 Implementation Status....................................44
15. References...............................................44 Acknowledgments..........................................44
15. Security Considerations..................................44
16. Author's Addresses.......................................44
17. References...............................................45

Degermark, Nordgren, Pink [Page 2]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

1. Introduction

There are several reasons to do header compression on a low-speed
link, header 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.

* 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 2 1.7 kbit/s.

* Decrease header overhead.

A common size of TCP segments for bulk transfers over medium-
speed links is 512 bytes. When TCP segments are tunneled, for
example because Mobile IP is used, the header is 100 bytes.
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.

* 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. For non-TCP
packets, an exponential backoff mechanism allows compression slow-start and periodic header refreshes allow
minimal periods of packet discard after loss of a header that changes
the compression state.

Degermark, Nordgren, Pink [Page 3]

INTERNET-DRAFT Header Compression for IPv6 February 1996

Header compression relies on many fields being constant or rarely 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 February 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 which that are included "as-is" in
compressed headers or can be inferred from 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 February 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 February 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 needs mechanisms to update the
compression state at the decompressor and to detect or avoid
incorrect decompression. Sections 3.1 and 3.2 describe how packet
loss is dealt with These mechanisms are very different for TCP
and non-TCP packet streams. streams, and are described in sections 3.1 and 3.2.

The compression mechanisms in this document assume that packets are
not reordered between the compressor and decompressor. They If the link
does reorder, section 11 describes mechanisms for ordering the
packets before decompression. It is also
assume 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. 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 header or a 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]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

the number size of payload octets in the lost packet. segment. Such incorrectly decompressed TCP
headers will be discarded by the TCP receiver as the

Degermark, Nordgren, Pink [Page 7]

INTERNET-DRAFT Header Compression for IPv6 February 1996 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. 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
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 one octet 7 bits long so the generation value repeats
itself after 256 128 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

Degermark, Nordgren, Pink [Page 8]

INTERNET-DRAFT Header Compression for IPv6 February 1996 been
disconnected MIN_WRAP seconds or more must wait for the next full
header before decompressing.

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. Exponential Backoff of Header Refreshes 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 satellite channels or cable TV systems. systems, and are hard to
adapt to multicast.

|.|..|....|........|................|..............................
^
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 a full header
is sent, and F_PERIOD is doubled each time a full header is sent.

3.2.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
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.

Degermark, Nordgren, Pink [Page 9]

INTERNET-DRAFT Header Compression for IPv6 February 1996

3.2.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 sent.
F_LAST -- the time of sending the last full header 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();
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 February June 13, 1996

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

INTERNET-DRAFT Header Compression for IPv6 February 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
multi-access links and multicast.

Degermark, Nordgren, Pink [Page 12]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

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, thrashing may occur as 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,

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 recent traffic
patterns. if routes flap and
the hop limit (TTL) field in a packet stream changes frequently
between n and n+k, a sender 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 the 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 packets a compressor may be grouped
group packets into packet streams. Four kinds of packet streams are recognized in these
guidelines, packets that do not match any of them are not compressed. for compression.

Degermark, Nordgren, Pink [Page 13]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

Flow Label non-zero

When the Flow Label is non-zero, only the Flow Label and Source
Address need to

Defining fields

All fields in subheaders that are marked with DEF in section 7
should be examined present and identical in all packets belonging to determine the
same packet stream of a
packet. However, fragments and unfragmented packets are
separated into different packet streams even in this case.

Transport layer port numbers visible

When the Flow Label is zero, stream. The DEF marked fields include the transport layer's notion of
stream is used. For UDP and TCP packets, flow
label, source and final destination addresses plus transport protocol type plus port
numbers are used to identify the packet stream of IP headers, final
destination address in routing headers, the packet.

Fragmented packets

For packet fragments next header field
preceding a UDP or TCP header, port numbers may not be available. They
might be in another packet, numbers, and thus the rules that guarantee a
unique Identification field SPI in
authentication and encryption headers.

Fragmented packets

Fragmented and unfragmented packets are used to identify never grouped together
in the same packet
stream of a fragmented packet. Note that the stream. The Identification field itself 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
expontential backoff.

Encrypted packets

For encrypted packets, port numbers may 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 available, and
even if they are, it is unwise to utilize them to identify
packet streams. If port numbers were used to identify for identifying packet streams, CIDs would disclose traffic patterns and may defeat
the purpose of the encryption. For encrypted packets, defining
fields are the source address, final destination address, and
the Security Payload Identification, SPI, of the ESP Header.
All of these are in clear text.

When IP
i.e., all packets are tunneled they are encapsulated with an additional
IP header at the tunnel entry point same DEF fields and then sent to the tunnel
endpoint. 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.

Degermark, Nordgren, Pink [Page 14]

INTERNET-DRAFT Header Compression for IPv6 February 1996 We also stress that if
the grouping fails, the result will be bad performance and not
incorrect decompression. The above reasoning results in decompressor can do its task regardless
of how the following header fields that
define packet streams grouping algorithm works.

5. Size Issues

5.1. Compression Identifiers

Compression identifiers can be 8 or 24 bits long. Their size is not
relevant for finding the compression

0. IPv4 addresses
When IPv4 headers are present, their source state. An 8-bit CID with value
two and destination
addresses are defining fields of the packet stream.

1. IPv6 Flows - the Flow Label field is non-zero.

Defining fields:

Flow Label (non-zero). Source Address. (Fragmented pack-
ets are grouped separately.)

2. IPv6 Non-flows - the Flow Label field is zero.

case a: Transport layer header visible

Defining Fields:

Flow Label (zero). Source Address. final Destination
Address (possibly in Routing Header). Transport Pro-
tocol Type (in the subheader immediately preceding the
Transport header; Next Header field if that is an IPv6
base or extension header, or Protocol field if it is
an IPv4 header). Transport stream identification (TCP
or UDP port numbers).

case b: Fragmented packets

Defining Fields:

Flow Label (zero). Source Address. final Destination
Address (possibly in Routing Header).

case c: Encrypted packets

Defining Fields:

Flow Label (zero). Source Address. final Destination
Address (possibly in Routing Header). Security Pay-
load Identifier, SPI, (in ESP Header).

NOTE: Several IP headers may occur in a chain of subheaders. In this
case the defining fields of all subheaders are considered when iden-
tifying the packet stream.

Detailed grouping hints are also found in section 7.

Degermark, Nordgren, Pink [Page 15]

INTERNET-DRAFT Header Compression for IPv6 February 1996

5. Size Issues

5.1. Compression Identifiers

Compression identifiers can be 4, 8 or 24 bits long. Their size is
not relevant for finding the compression state, a 4-bit CID with
value two, 0010, and an 8-bit CID with value two, 00000010, an 24-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 two bits one bit
in the first byte of the compressed header. The 4-bit 8-bit CID allows a
minimum compressed header size of 2 octets for non-TCP packets, the
size bits bit and the CID 7-bit Generation value fit in the first octet and
the generation value CID uses the second octet. A compressor should use 4-bit CIDs for packet
streams with the highest packet frequencies to achieve the best
compression rates.

There are no bits available to encode the CID size in the first octet
of the compressed TCP header, so for

For TCP the only available CID size is 8 bits. Using a 4-bit CID would not reduce the size of the
compressed TCP header, and 8 bits is probably
sufficient as TCP con-
nections connections are always point-to-point.

The 24 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 for multicast packet
streams. CIDs.

The major difficulty with multicast over 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

longer be selected independently by the compressor 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 link-layer frame. If such information is not avail-
able,
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.

Degermark, Nordgren, Pink [Page 16]

INTERNET-DRAFT Header Compression for IPv6 February 1996

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 arbi-
trarily
arbitrarily long. This is a problem as the compression state is essen-
tially
essentially a stored header.

The configurable parameter MAX_HEADER (see section 12) 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 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 dis-
cards.

Degermark, Nordgren, Pink [Page 17]

INTERNET-DRAFT Header Compression for IPv6 February 1996
discards.

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 imple-
mentation
implementation provides the length of packets, we can use the length
fields in a full header headers to pass the values of the CID and the genera-
tion
generation to the decompressor.

This requires that the link-layer must not add padding to the pay-
load,
payload, at least, 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 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
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 avail-
able available to pass
the generation and CID, thus 4 bit and 8 bit CID. Thus, 8-bit CIDs may be the only CID sizes
that can be used for those such packet streams. When IPv6/IPv4 or
IPv4/IPv6 tunneling is used, there will be at least 4 octets
available, and all CID sizes may be used. used for non-TCP packet streams.

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 avail-
able,
available, the 4 bit or 8 bit 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, Nordgren, Pink [Page 17]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

5.3.1. Length fields in full TCP headers

Full TCP headers with one length field:

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

Full TCP headers with two or more length fields:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field | LSB of pkt nr | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 fields in full non-TCP headers

Full non-TCP headers with 1 octet CID field:

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

Full non-TCP headers with 3 octet CID field:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |1| Generation | MSB of CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Degermark, Nordgren, Pink [Page 18]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

6. Compressed Header Formats

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

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

+-+-+-+-+-+-+-+-+- - - - - - - -
| |C I P S A W U| CID (if C=1) |
+-+-+-+-+-+-+-+-+- - - - - - - -

Used in the same way
| RANDOM fields, if any (see section 7)
- - - - - - - - - - - -
| Sequence Number Delta (if S=1)
- - - - - - - - - - - -
| Acknowledgment Number Delta (if A=1)
- - - - - - - - - - - -
| Window (if W=1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Urgent Pointer (present if U=1)
- - - - - - - - - - - -

The flags in the first byte (CIPSAWU) have the same meaning as in
[RFC-1144], regardless of whether the TCP segments are carried by
IPv6 or IPv4. The compression state asso-
ciated associated with the CID keeps
track of the IP version. Note that the
CID The order between delta fields specified
here is present only different from [RFC-1144].

The initial flag byte is followed by an 8-bit CID if the C flag is
set, if not after which the previous TCP
CID is used. See section 10. RANDOM and DELTA fields of the subheaders follow
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 encapsulating or encapsulated IPv4 header is present as there is no
Identification field in the IPv6 header. The CID size for If there are more than one
IPv4 header present, only the Identification field of the IPv4 header
closest to the TCP packet streams header is always 8 bits. delta encoded, other Identification
fields are RANDOM. The initial flag byte is followed by an 8-bit CID if delta of the C flag Identification field is
set, after which placed
among the DELTA and RANDOM fields follow in at the same
order as they occur in position corresponding to the original uncompressed IPv4
header.

If the I flag is set, the delta of the IPv4 Identifier value is
placed at the position that corresponds to the place of the IPv4
subheader in the uncompressed header. The TCP Checksum

See section 7.12 and the optional values
associated with the SAWU flags are placed in the order prescribed
by [RFC-1144] at the position corresponding for further information about how to the place of the
compress TCP subheader in the original uncompressed header. headers.

Degermark, Nordgren, Pink [Page 19]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |0 1| CID |
|0| Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |1 0| Res | CID | Generation
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

d) RANDOM fields, if any (see section 7)
- - - - - - - - - - - -

c) Compressed non-TCP header, 24 bit CID:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |1 1| Res
|1| Generation | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation |
+-+-+-+-+-+-+-+-+

The Res field of formats c) and d) is not used and is initialized to
zero by the compressor and ignored by the decompressor. RANDOM fields, if any (see section 7)
- - - - - - - - - - - -

Compressed non-TCP headers are followed by relevant RANDOM fields
(see section 7) placed in the same order as they occur in the origi-
nal
original uncompressed header, followed by the payload.

Degermark, Nordgren, Pink [Page 20]

INTERNET-DRAFT Header Compression for IPv6 February 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 February 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 compres-
sion
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. RAN-
DOM RANDOM fields are sent "as-is" in the compressed
header. DELTA and RAN-
DOM 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 the packets they belong
to different packet streams. Moreover, if a DEF field is present in
one packet but not in another, the packets belong to dif-
ferent different packet
streams. The words DEF IFZERO means that the field is
DEF if the closest preceding IP header is an IPv4 header or an IPv6
header with a zero Flow Label.

Degermark, Nordgren, Pink [Page 22]

INTERNET-DRAFT Header Compression for IPv6 February 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, if Flow Label is zero
and a corresponding Routing
Header is exhausted) (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 February 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 February 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 questionable if any packet ever
sent over usually a low-speed link will carry this option! bad idea to send such
large packets over low- and medium-speed links.

Degermark, Nordgren, Pink [Page 25]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

7.5. Routing Header [IPv6, section 4.4]

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 Desti-
nation
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,
the only Routing Type currently defined.

The fields of 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 February 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] may be the final Destination
address. It is DEF IFZERO when
Segments if (Segments Left > 0 ) 0))

This classification allows Routing Headers of type 0 to be compressed
away completely. This is a big win as the maximum size of the Routing
Header is 392 octets.

Degermark, Nordgren, Pink [Page 27]

INTERNET-DRAFT Header Compression for IPv6 February 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 sub-
headers
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 sub-
headers
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 an exponential backoff one compression slow-start per packet.

Degermark, Nordgren, Pink [Page 28]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

Grouping of fragments according to the guidelines in section 4.1

If the Flow Label of the closest preceding IPv6 base header is
nonzero,

Fragments and unfragmented packets should not be grouped together.

Port numbers cannot be used to identify the packet stream is defined by the combination of Flow
Label and Source Address. However, fragments and unfragmented
packets should not be grouped together.

Port numbers cannot be used to identify the packet stream when the
Flow Label of the closest preceding IP header is zero, 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
(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 initial exponential
backoff. compression slow-start.
We hope that the unfragmentable part of the headers will not
change too frequently, if it does thrashing may occur.

NOTE: These rules imply that a packet stream never contains
both fragmented and unfragmented packets. A good grouping
algorithm should always separate fragmented from unfrag-
mented packets to avoid compression state changes and the
associated exponential backoffs.

Degermark, Nordgren, Pink [Page 29]

INTERNET-DRAFT Header Compression for IPv6 February 1996

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 30] 29]

INTERNET-DRAFT Header Compression for IPv6 February 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 IFZERO) (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 the
compressed header by 16 octets.

As this This is typically more than a 300%
increase in the size of the compressed header, authentication should be used with care over low-
speed links. It is a bad idea to authenticate all packets if one is
primarily concerned with bandwidth efficiency and/or low delay. header.

Degermark, Nordgren, Pink [Page 31] 30]

INTERNET-DRAFT Header Compression for IPv6 February 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 subse-
quent
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. Note
that this type of compression can The
mechanisms for dealing with reordering described in section 11 should
be done only when it is guaranteed
that used, as packets will not are likely to be reordered in the tunnel, as the compression
mechanisms specified in this document assume that the packet order is
preserved between the compressor and decompressor. a tunnel.

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

SPI NOCHANGE (DEF IFZERO) (DEF)
Opaque Transform Data RANDOM

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

Degermark, Nordgren, Pink [Page 32]

INTERNET-DRAFT Header Compression for IPv6 February 1996

7.11. UDP Header

The UDP header is described in [RFC-768].

The Next Header field (IPv6) or Protocol field (IPv4) in the preced-
ing
preceding subheader is DEF IFZERO. DEF.

Source Port NOCHANGE (DEF IFZERO) (DEF)
Destination Port NOCHANGE (DEF IFZERO) (DEF)
Length INFERRED
Checksum RANDOM

The UDP header is compressed down to 2 octets, the UDP checksum. The
Length field of the UDP header must correspond to the Length field(s)
of preceding subheaders.

Degermark, Nordgren, Pink [Page 33] 31]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

7.12. TCP Header

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

The Next Header field (IPv6) (IbPv6) or Protocol field (IPv4) in the preced-
ing
preceding subheader is DEF IFZERO. DEF.

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

There are two ways to compress the TCP header. One uses the
differential encoding techniques of Jacobsson, described in [RFC-
1144], the only difference being the placement of the compressed TCP
header fields (see section 6).

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

The other method classifies the Source Port and Destination Port as
NOCHANGE and the rest of the TCP header fields as RANDOM. This is a
simple way to deal with links that reorder. The packet stream is
considered to be a non-TCP packet stream (!), so a non-TCP CID should
be used and format b), c), or d) must be used for the compressed as described by Jacobson
header. The rules for sending full headers in [RFC-1144].
For placement of compressed TCP header fields, see section 6. 3.2.3 apply.

Section 11 describes a method to deal with reordering that only adds
two bytes to compressed headers.

Degermark, Nordgren, Pink [Page 34] 32]

INTERNET-DRAFT Header Compression for IPv6 February 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 (for non-TCP)

Flags NOCHANGE (MF bit 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 35] 33]

INTERNET-DRAFT Header Compression for IPv6 February 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 frag-
ment fragment it does not
end the compressible chain of subheaders, so sub-
sequent subsequent subheaders are
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 fact, but not the size of the
options)
options, together with the Version, Source Address, and Destination
Address to determine the packet stream.

Degermark, Nordgren, Pink [Page 36] 34]

INTERNET-DRAFT Header Compression for IPv6 February 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
CID to a new packet stream involves paying the cost of at least one
exponential backoff, so it should not be done too frequently.

Each non-TCP CID is associated with a compression state with a gen-
eration
generation value. To avoid too rapid generation wrap-around and poten-
tial
potential incorrect decompression, an implementation must avoid wrap-
around
wrap-around of the generation value in less than MIN_WRAP seconds
(see section 12).

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

An implementation must not reset the generation value when changing allocating
a CID to a new packet stream.

Degermark, Nordgren, Pink [Page 37] 35]

INTERNET-DRAFT Header Compression for IPv6 February 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

a) when the compression state for C is has
not initialized. been initialized by a full header.

When a decompressor receives a packet with a compressed non-TCP
header with CID C and generation G, it the header must not be discarded

b)
decompressed using the current compression state when

a) the decompressor has been disconnected from the compressor for
more than MIN_WRAP seconds (see section 12),

c) when seconds, because the compression state for C is not initialized,

d) when the might
be obsolete even if it has generation of G.

b) the compression state for C is neither G
nor G-1 (modulo 256).

When a decompressor receives a packet with has a compressed non-TCP
header with CID C and generation G, other than G.

In case a) and b) the compression state for C
has generation G-1 (modulo 256),

e) the header must not be decompressed using the current compres-
sion state. 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 according to ii) 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 immediately succeeding other than the generation of
its compression state. Rule e) ii) allows the decompressor to store
such headers until they can be decompressed using the correct compression
state.

Degermark, Nordgren, Pink [Page 38] 36]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

10. More aggressive Low-loss header compression

[RFC-1144] allows the CID to be compressed away for TCP

Since fewer bits are transmitted per packet
streams under certain circumstances. This typically reduces the size
of with header compression,
the compressed TCP packet loss rate is lower with header from 4 to 3 bytes.

In a similar vein, compressed non-TCP headers can be reduced to compression than without,
for a
single octet by substituting CID and generation 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 4-bit
value after lost TCP segment can ruin an association has formed between a 4-bit identifier
called entire TCP sending
window because the CGID, and compression state is not incremented properly at
the CID and generation. The format of such
compressed decompressor. Subsequent headers is

+-+-+-+-+-+-+-+-+
| |0 0| CGID |
+-+-+-+-+-+-+-+-+

The association between CGID will therefore be decompressed
to be different than before compression and CID plus generation is established discarded by placing the CGID TCP
receiver. A TCP connection in the Res field in compressed non-TCP headers of
format c) or d). The CGID wide area where the last hop is subsequently treated as an alias
over a medium-speed lossy link, for the
CID and generation in that compressed non-TCP header. The compressor
should send example a few compressed headers wireless LAN, can have
poor performance with format c) or d) before
switching to header compression because the one octet format to increase sending window
is relatively large and the chance that bit-error rate high.

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 has established can compute the association. The value zero is used TCP checksum to signal absence of a GCID in formats c) and d), and neither estab-
lishes nor deletes an association.

To avoid incorrect decompression when the CGID determine if its
compression state is used, only one CGID
value not updated properly. If the checksum fails, the
error is valid at any given time. When assumed to caused by a new association is desired lost segment that did not update the
compression state properly. The delta of the current CGID value segment is incremented by 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
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. 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, and the TCP transfer
can continue without backing off.

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 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. 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 16), skipping
over zero.
128). The compressor 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 reordering in TCP
streams. It requires using the methods from 11.1 for dealing with
reordering in non-TCP streams. Compressed headers will typically be
18 bytes with that method, which is significantly larger than the
usual 4-6 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 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 wrap-around 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. 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 CGID value MTU
of the link. Therefore only the least significant byte of the packet
sequence number can be placed in
less than MIN_WRAP seconds. A CGID association must such full headers. We believe that
such full headers can be refreshed at positioned correctly frequently enough with
only the least once every MIN_WRAP seconds. These rules allow significant byte of the decompres-
sor packet sequence number
available. Experiments are needed to avoid incorrect decompression 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
packet sequence numbers to compressed headers by discarding packets with CGIDs placing a value
other than zero in a full header.

Avoiding zero also takes care of a problem that can occur when the one it believes is current.

It is questionable whether this more aggressive compression technique
TCP window scale option is defensible as used to enlarge the risk TCP window. When
exactly 2^16 bytes of incorrect compression and discarded
packets increases. It also increases TCP data is lost, a compressed header will be
decompressed incorrectly without being detected by the complexity TCP checksum.
TCP segments are usually a power of two. So by using a packet
sequence number space that is not a power of two either the protocol.
When sequence
number or the link has a low error rate and there packet sequence number will differ when 2^16 bytes are few streams, say
lost. When a
single voice flow, compressor sees the window scale option on a SYN
segment, it may 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 a win. omitted when
packet sequence numbers are used. See section 5.3 for placement of
packet sequence numbers in full headers.

Degermark, Nordgren, Pink [Page 39] 40]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

11.

12. 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.

The decision to use a distinct ethertype (or equivalent) for IPv6 has
already been taken, so this takes care of distinguishing packets with
regular IPv4 and IPv6 headers.

Four different which means that link-layers must be able to
indicate that a packet types remain. Our suggestion is to use one
additional ethertype (or equivalent) for full and compressed headers
and encode the first four bits of the full and compressed headers as
follows

First bits of header Type of header
-------------------- --------------

0100 full IPv4 header (with CID and generation)
0110 full an IPv6 packet.

IPv6 header (with CID and generation)

1*** compressed TCP header (format a)
00** compressed non-TCP header (formats b c or d),
or compression requires that the one byte link-layer implementation
can indicate two new kinds of packets: COMPRESSED_TCP for format from a)
in section 10.

If a new ethertype cannot be obtained we suggest that the IPv6 ether-
type is used 6, and the following encoding COMPRESSED_NON_TCP for formats b) and c) in section
6.

Full headers and header requests are indicated by special encodings
of the first four bits is
used

First bits of header (Version field) in a packet indicated to be an
IPv6 packet.

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

0100 regular IPv4 header (own ethertype)

0110 regular IPv6 header

0111

1100 full IPv4 packet (with CID and generation)
0101 header
1101 full IPv4 header, requests full header

1110 full IPv6 packet (with CID and generation)

1*** compressed TCP header (format a)
00** compressed non-TCP
1111 full IPv6 header, requests full header (formats b c or d)

Here, care has been taken to use the same encoding as suggested by
Jacobson in [RFC-1144] whenever applicable. This latter encoding
could also be used for links where

If the link-layer does not provide cannot indicate these packet types, all packets
with compressed headers must start with a
way to encode payload type. However, ST-2 already uses 0101 so this
will not work on links where ST-2 traffic is present. byte indicating the packet
type, followed by the compressed header.

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

00000000 compressed TCP header (format a)
00000001 compressed non-TCP header (formats b or c)

Degermark, Nordgren, Pink [Page 40] 41]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

12.

13. 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 headers that may be
sent without a header refresh.

DEFAULT is 256

F_MAX_TIME - Compressed headers may not be sent more than
F_MAX_TIME seconds after sending last full header.

DEFAULT is 5 seconds

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 octets), which covers

IPv6 Base Header
Routing Header with two addresses
Keyed MD5 Authentication Header
Minimum TCP Header

Degermark, Nordgren, Pink [Page 41]

INTERNET-DRAFT Header Compression for IPv6 February 1996

TCP_SPACE - Size of allowed CID space for TCP streams.

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

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

TCP_SPACE must be at least 2 and at most 8.

Degermark, Nordgren, Pink [Page 42]

INTERNET-DRAFT Header Compression for IPv6 June 13, 1996

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

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

DEFAULT is 7, 4, giving a maximum non-TCP CID of 2^7-1 2^4-1 = 127 15

NON_TCP_SPACE must be at least 2 and at most 24.

ENABLE_CID_COMPRESSION - may TCP CIDs be compressed away?

DEFAULT no.

ENABLE_ONE_OCTET

EXPECT_REORDERING - may one octet non-TCP format be used? The mechanisms in section 11 are used.

DEFAULT no.

Degermark, Nordgren, Pink [Page 42] 43]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

13.

14. Implementation Status

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

15. 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. Security Considerations

We advise against identifying packet streams with the aid of informa-
tion
information that is encrypted even if such information happens to be avail-
able
available to the compressor. Doing so would expose traffic patterns.

We advise against using authentication on all packets sent over a
low-speed link as doing so will increase the size of the average
compressed header significantly. Almost as good security may be
achievable by carefully selecting what packets to authenticate.

14.

17. Author's Addresses

Mikael Degermark Bjorn Nordgren Tel: +46 920 91188
CDT/Dept of Computer Science CDT/Telia Research AB Fax: +46 920 72191
Lulea University Aurorum 6 EMail: micke@sm.luth.se
S-971 87 Lulea, Sweden S-977 75 Lulea, Sweden
Tel: +46 920 91188

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

Stephen Pink
CDT/Swedish Institute of Computer Science
PO Box 1263
S-164 28 Kista, Sweden 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 43] 44]

INTERNET-DRAFT Header Compression for IPv6 February June 13, 1996

15.

18. 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, Sep-
tember
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.

This draft expires August December 18, 1996

Degermark, Nordgren, Pink [Page 44] 45]

----