Request for Comments: 4413 S. McCann
Category: Informational Siemens/Roke Manor Research
March 2006
TCP/IP Field Behavior
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo describes TCP/IP field behavior in the context of header
compression. Header compression is possible because most header
fields do not vary randomly from packet to packet. Many of the
fields exhibit static behavior or change in a more or less
predictable way. When a header compression scheme is designed, it is
of fundamental importance to understand the behavior of the fields in
detail. An example of this analysis can be seen in RFC 3095. This
memo performs a similar role for the compression of TCP/IP headers.
Table of Contents
1. Introduction ....................................................3
2. General classification ..........................................4
2.1. IP Header Fields ...........................................5
2.1.1. IPv6 Header Fields ....................................5
2.1.2. IPv4 Header Fields ....................................7
2.2. TCP Header Fields .........................................10
2.3. Summary for IP/TCP ........................................11
3. Classification of Replicable Header Fields .....................11
3.1. IPv4 Header (Inner and/or Outer) ..........................12
3.2. IPv6 Header (inner and/or outer) ..........................14
3.3. TCP Header ................................................14
3.4. TCP Options ...............................................15
3.5. Summary of Replication ....................................16
4. Analysis of Change Patterns of Header Fields ...................16
4.1. IP Header .................................................19
4.1.1. IP Traffic-Class / Type-Of-Service (TOS) .............19
4.1.2. ECN Flags ............................................19
4.1.3. IP Identification ....................................20
4.1.4. Don’t Fragment (DF) flag .............................22
4.1.5. IP Hop-Limit / Time-To-Live (TTL) ....................22
4.2. TCP Header ................................................23
4.2.1. Sequence Number ......................................23
4.2.2. Acknowledgement Number ...............................24
4.2.3. Reserved .............................................25
4.2.4. Flags ................................................25
4.2.5. Checksum .............................................26
4.2.6. Window ...............................................26
4.2.7. Urgent Pointer .......................................27
4.3. Options ...................................................27
4.3.1. Options Overview .....................................28
4.3.2. Option Field Behavior ................................29
5. Other Observations .............................................36
5.1. Implicit Acknowledgements .................................36
5.2. Shared Data ...............................................36
5.3. TCP Header Overhead .......................................37
5.4. Field Independence and Packet Behavior ....................37
5.5. Short-Lived Flows .........................................37
5.6. Master Sequence Number ....................................38
5.7. Size Constraint for TCP Options ...........................38
6. Security Considerations ........................................39
7. Acknowledgements ...............................................39
8. References .....................................................40
8.1. Normative References ......................................40
8.2. Informative References ....................................41
1. Introduction
This document describes the format of the TCP/IP header and the
header field behavior, i.e., how fields vary within a TCP flow. The
description is presented in the context of header compression.
Since the IP header does exhibit slightly different behavior from
that previously presented in RFC 3095 [31] for UDP and RTP, it is
also included in this document.
This document borrows much of the classification text from RFC 3095
[31], rather than inserting many references to that document.
According to the format presented in RFC 3095 [31], TCP/IP header
fields are classified and analyzed in two steps. First, we have a
general classification in Section 2, where the fields are classified
on the basis of stable knowledge and assumptions. This general
classification does not take into account the change characteristics
of changing fields, as those will vary more or less depending on the
implementation and on the application used. Section 3 considers how
field values can be used to optimize short-lived flows. A more
detailed analysis of the change characteristics is then done in
Section 4. Finally, Section 5 summarizes with conclusions about how
the various header fields should be handled by the header compression
scheme to optimize compression.
A general question raised by this analysis is: what ’baseline’
definition of all possible TCP/IP implementations is to be
considered? This review is based on an analysis of currently
deployed TCP implementations supporting mechanisms standardised by
the IETF.
The general requirement for transparency is also interesting. A
number of recent proposals for extensions to TCP use some of the
previously ’reserved’ bits in the TCP packet header. Therefore, a
’reserved’ bit cannot be taken to have a guaranteed zero value; it
may change. Ideally, this should be accommodated by the compression
profile.
A number of reserved bits are available for future expansion. A
treatment of field behavior cannot predict the future use of such
bits, but we expect that they will be used at some point. Given
this, a compression scheme can optimise for the current situation but
should be capable of supporting any arbitrary usage of the reserved
bits. However, it is impossible to optimise for usage patterns that
have yet to be defined.
2. General classification
The following definitions (and some text) are copied from RFC 3095
[31], Appendix A. Differences of IP field behavior between RFC 3095
[31] (i.e., IP/UDP/RTP behavior for audio and video applications) and
this document have been identified.
For the following, we define "session" as a TCP packet stream, being
a series of packets with the same IP addresses and port numbers. A
packet flow is defined by certain fields (see STATIC-DEF, below) and
may be considered a subset of a session. See [31] for a fuller
discussion of separation of sessions into streams of packets for
header compression.
At a general level, the header fields are separated into 5 classes:
o INFERRED
These fields contain values that can be inferred from other
values (for example, the size of the frame carrying the packet)
and thus do not have to be handled at all by the compression
scheme.
o STATIC
These fields are expected to be constant throughout the
lifetime of the packet stream. Static information must in some
way be communicated once.
o STATIC-DEF
STATIC fields whose values define a packet stream. They are in
general handled as STATIC.
o STATIC-KNOWN
These STATIC fields are expected to have well-known values and
therefore do not need to be communicated at all.
o CHANGING
These fields are expected to vary randomly within a limited
value set or range or in some other manner.
In this section, each of the IP and TCP header fields is assigned to
one of these classes. For all fields except those classified as
CHANGING, the motives for the classification are also stated. In
section 4, CHANGING fields are further examined and classified on the
basis of their expected change behavior.
2.1. IP Header Fields
2.1.1. IPv6 Header Fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| DSCP* | 6 | ALTERNATING |
| ECT flag* | 1 | CHANGING |
| CE flag* | 1 | CHANGING |
| Flow Label | 20 | STATIC-DEF |
| Payload Length | 16 | INFERRED |
| Next Header | 8 | STATIC |
| Hop Limit | 8 | CHANGING |
| Source Address | 128 | STATIC-DEF |
| Destination Address | 128 | STATIC-DEF |
+---------------------+-------------+----------------+
* Differs from RFC 3095 [31]. (The DSCP, ECT,
and CE flags were amalgamated into the Traffic
Class octet in RFC 3095).
Figure 1. IPv6 Header Fields
o Version
The version field states which IP version is used. Packets
with different values in this field must be handled by
different IP stacks. All packets of a packet stream must
therefore be of the same IP version. Accordingly, the field is
classified as STATIC.
o Flow Label
This field may be used to identify packets belonging to a
specific packet stream. If the field is not used, its value
should be zero. Otherwise, all packets belonging to the same
stream must have the same value in this field, it being one of
the fields that define the stream. The field is therefore
classified as STATIC-DEF.
o Payload Length
Information about packet length (and, consequently, payload
length) is expected to be provided by the link layer. The
field is therefore classified as INFERRED.
o Next Header
This field will usually have the same value in all packets of a
packet stream. It encodes the type of the subsequent header.
Only when extension headers are sometimes absent will the field
change its value during the lifetime of the stream. The field
is therefore classified as STATIC. The classification of
STATIC is inherited from RFC 3095 [31]. However, note that the
next header field is actually determined by the type of the
following header. Thus, it might be more appropriate to view
this as an inference, although this depends upon the specific
implementation of the compression scheme.
o Source and Destination Addresses
These fields are part of the definition of a stream and
therefore must be constant for all packets in the stream. The
fields are therefore classified as STATIC-DEF.
This might be considered as a slightly simplistic view. In
this document, the IP addresses are associated with the
transport layer connection and assumed to be part of the
definition of a flow. More complex flow-separation could, of
course, be considered (see also RFC 3095 [31] for more
discussion of this issue). Where tunneling is being performed,
the use of the IP addresses in outer tunnel headers is also
assumed to be STATIC-DEF.
The total size of the fields in each class is as follows:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 2 |
| STATIC | 1.5 |
| STATIC-DEF | 34.5 |
| STATIC-KNOWN | 0 |
| CHANGING | 2 |
+--------------+--------------+
Figure 2: Field sizes
2.1.2. IPv4 Header Fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| Header Length | 4 | STATIC-KNOWN |
| DSCP* | 6 | ALTERNATING |
| ECT flag* | 1 | CHANGING |
| CE flag* | 1 | CHANGING |
| Packet Length | 16 | INFERRED |
| Identification | 16 | CHANGING |
| Reserved flag* | 1 | CHANGING |
| Don’t Fragment flag*| 1 | CHANGING |
| More Fragments flag | 1 | STATIC-KNOWN |
| Fragment Offset | 13 | STATIC-KNOWN |
| Time To Live | 8 | CHANGING |
| Protocol | 8 | STATIC |
| Header Checksum | 16 | INFERRED |
| Source Address | 32 | STATIC-DEF |
| Destination Address | 32 | STATIC-DEF |
+---------------------+-------------+----------------+
* Differs from RFC 3095 [31]. (The DSCP, ECT
and CE flags were amalgamated into the TOS
octet in RFC 3095; the DF flag behavior is
considered later; the reserved field is
discussed below).
Figure 3. IPv4 Header Fields
o Version
The version field states which IP version is used. Packets
with different values in this field must be handled by
different IP stacks. All packets of a packet stream must
therefore be of the same IP version. Accordingly, the field is
classified as STATIC.
o Header Length
As long as no options are present in the IP header, the header
length is constant and well known. If there are options, the
fields would be STATIC, but it is assumed here that there are
no options. The field is therefore classified as STATIC-KNOWN.
o Packet Length
Information about packet length is expected to be provided by
the link layer. The field is therefore classified as INFERRED.
o Flags
The Reserved flag must be set to zero, as defined in RFC 791
[1]. In RFC 3095 [31] the field is therefore classified as
STATIC-KNOWN. However, it is expected that reserved fields may
be used at some future point. It is undesirable to select an
encoding that would preclude the use of a compression profile
for a future change in the use of reserved fields. For this
reason, the alternative encoding of CHANGING is used. (A
compression profile can, of course, still optimise for the
current situation, where the field value is known to be 0).
The More Fragments (MF) flag is expected to be zero because
fragmentation is, ideally, not expected. However, it is also
understood that some scenarios (for example, some tunnelling
architectures) do cause fragmentation. In general, though,
fragmentation is not expected to be common in the Internet due
to a combination of initial MSS negotiation and subsequent use
of path-MTU discovery. RFC 3095 [31] points out that, for RTP,
only the first fragment will contain the transport layer
protocol header; subsequent fragments would have to be
compressed with a different profile. This is also obviously
the case for TCP. If fragmentation were to occur, the first
fragment, by definition, would be relatively large, minimizing
the header overhead. Subsequent fragments would be compressed
with another profile. It is therefore considered undesirable
to optimise for fragmentation in performing header compression.
The More Fragments flag is therefore classified as STATIC-
KNOWN.
o Fragment Offset
Under the assumption that no fragmentation occurs, the fragment
offset is always zero. The field is therefore classified as
STATIC-KNOWN. Even if fragmentation were to be further
considered, only the first fragment would contain the TCP
header, and the fragment offset of this packet would still be
zero.
o Protocol
This field will usually have the same value in all packets of a
packet stream. It encodes the type of the subsequent header.
Only where the sequence of headers changes (e.g., an extension
header is inserted or deleted or a tunnel header is added or
removed) will the field change its value. The field is
therefore classified as STATIC. Whether such a change would
cause the sequence of packets to be treated as a new flow (for
header compression) is an issue for profile design. ROHC
profiles must be able to cope with extension headers and
tunnelling, but the choice of strategy is outside the scope of
this document.
o Header Checksum
The header checksum protects individual hops from processing a
corrupted header. When almost all IP header information is
compressed away, there is no point in having this additional
checksum. Instead, it can be regenerated at the decompressor
side. The field is therefore classified as INFERRED.
Note that the TCP checksum does not protect the whole TCP/IP
header, but only the TCP pseudo-header (and the payload).
Compare this with ROHC [31], which uses a CRC to verify the
uncompressed header. Given the need to validate the complete
TCP/IP header, the cost of computing the TCP checksum over the
entire payload, and known weaknesses in the TCP checksum [37],
an additional check is necessary. Therefore, it is highly
desirable that some additional checksum (such as a CRC) will be
used to validate correct decompression.
o Source and Destination Addresses
These fields are part of the definition of a stream and must
thus be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF.
The total size of the fields in each class is as follows:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 4 |
| STATIC* | 1.5 |
| STATIC-DEF | 8 |
| STATIC-KNOWN*| 2.25 |
| CHANGING* | 4.25 |
+--------------+--------------+
* Differs from RFC 3095 [31]
Figure 4. Field sizes
2.2. TCP Header Fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |