GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4413

Network Working Group M. West 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.

West & McCann Informational [Page 1] RFC 4413 TCP/IP Field Behavior March 2006

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

West & McCann Informational [Page 2] RFC 4413 TCP/IP Field Behavior March 2006

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.

West & McCann Informational [Page 3] RFC 4413 TCP/IP Field Behavior March 2006

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.

West & McCann Informational [Page 4] RFC 4413 TCP/IP Field Behavior March 2006

 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.

West & McCann Informational [Page 5] RFC 4413 TCP/IP Field Behavior March 2006

 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

West & McCann Informational [Page 6] RFC 4413 TCP/IP Field Behavior March 2006

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.

West & McCann Informational [Page 7] RFC 4413 TCP/IP Field Behavior March 2006

 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.

West & McCann Informational [Page 8] RFC 4413 TCP/IP Field Behavior March 2006

       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

West & McCann Informational [Page 9] RFC 4413 TCP/IP Field Behavior March 2006

2.2. TCP Header Fields

        +---------------------+-------------+----------------+
        | Field               | Size (bits) |      Class     |
        +---------------------+-------------+----------------+
        | Source Port         |     16      |    STATIC-DEF  |
        | Destination Port    |     16      |    STATIC-DEF  |
        | Sequence Number     |     32      |     CHANGING   |
        | Acknowledgement Num |     32      |     CHANGING   |
        | Data Offset         |      4      |     INFERRED   |
        | Reserved            |      4      |     CHANGING   |
        | CWR flag            |      1      |     CHANGING   |
        | ECE flag            |      1      |     CHANGING   |
        | URG flag            |      1      |     CHANGING   |
        | ACK flag            |      1      |     CHANGING   |
        | PSH flag            |      1      |     CHANGING   |
        | RST flag            |      1      |     CHANGING   |
        | SYN flag            |      1      |     CHANGING   |
        | FIN flag            |      1      |     CHANGING   |
        | Window              |     16      |     CHANGING   |
        | Checksum            |     16      |     CHANGING   |
        | Urgent Pointer      |     16      |     CHANGING   |
        | Options             |   0(-352)   |     CHANGING   |
        +---------------------+-------------+----------------+
                      Figure 5: TCP header fields
 o  Source and Destination ports
    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.
 o  Data Offset
    The number of 4 octet words in the TCP header, indicating the
    start of the data.  It is always a multiple of 4 octets.  It can
    be re-constructed from the length of any options, and thus it is
    not necessary to carry this explicitly.  The field is therefore
    classified as INFERRED.

West & McCann Informational [Page 10] RFC 4413 TCP/IP Field Behavior March 2006

2.3. Summary for IP/TCP

 Summarizing this for IP/TCP, one obtains the following:
        +----------------+----------------+----------------+
        | Class \ IP ver | IPv6 (octets)  | IPv4 (octets)  |
        +----------------+----------------+----------------+
        | INFERRED       |   2 + 4 bits   |   4 + 4 bits   |
        | STATIC         |   1 + 4 bits   |   1 + 4 bits   |
        | STATIC-DEF     |  38 + 4 bits   |      12        |
        | STATIC-KNOWN   |       -        |   2 + 2 bits   |
        | CHANGING       |  17 + 4 bits   |  19 + 6 bits   |
        +----------------+----------------+----------------+
        | Totals         |     60         |     40         |
        +----------------+----------------+----------------+
        (Excludes options, which are all classified as CHANGING).
                    Figure 6.  Overall field sizes

3. Classification of Replicable Header Fields

 Where multiple flows either overlap in time or occur sequentially
 within a short space of time, there can be a great deal of similarity
 in header field values.  Such commonality of field values is
 reflected in the compression context.  Thus, it should be possible to
 utilise commonality between fields across different flows to improve
 the compression ratio.  In order to do this, it is important to
 understand the 'replicable' characteristics of the various header
 fields.
 The key concept is that of 'replication': an existing context is used
 as a baseline and replicated to initialise a new context.  Those
 fields that are the same are then automatically initialised in the
 new context.  Those that have changed will be updated or overwritten
 with values from the initialisation packet that triggered the
 replication.  This section considers the commonality between fields
 in different flows.
 Note, however, that replication is based on contexts (rather than on
 just field values), so compressor-created fields that are part of the
 context may also be included.  These, of course, are dependent upon
 the nature of the compression protocol (ROHC profile) being applied.

West & McCann Informational [Page 11] RFC 4413 TCP/IP Field Behavior March 2006

 A brief analysis of the relationship of TCP/IP fields among
 'replicable' packet streams follows.
    'N/A': The field need not be considered in the replication
          process, as it is inferred or known 'a priori' (and,
          therefore, does not appear in the context).
    'No': The field cannot be replicated since its change pattern
          between two packet flows is uncorrelated.
    'Yes': The field may be replicated.  This does not guarantee that
          the field value will be the same across two candidate
          streams, only that it might be possible to exploit
          replication to increase the compression ratio.  Specific
          encoding methods can be used to improve the compression
          efficiency.

3.1. IPv4 Header (Inner and/or Outer)

        +-----------------------+---------------+------------+
        | Field                 | Class         | Replicable |
        +-----------------------+---------------+------------+
        | Version               | STATIC        | N/A        |
        | Header Length         | STATIC-KNOWN  | N/A        |
        | DSCP                  | ALTERNATING   | No  (1)    |
        | ECT flag              | CHANGING      | No  (2)    |
        | CE flag               | CHANGING      | No  (2)    |
        | Packet Length         | INFERRED      | N/A        |
        | Identification        | CHANGING      | Yes (3)    |
        | Reserved flag         | CHANGING      | No  (4)    |
        | Don't Fragment flag   | CHANGING      | Yes (5)    |
        | More Fragments flag   | STATIC-KNOWN  | N/A        |
        | Fragment Offset       | STATIC-KNOWN  | N/A        |
        | Time To Live          | CHANGING      | Yes        |
        | Protocol              | STATIC        | N/A        |
        | Header Checksum       | INFERRED      | N/A        |
        | Source Address        | STATIC-DEF    | Yes        |
        | Destination Address   | STATIC-DEF    | Yes        |
        +-----------------------+---------------+------------+
                         Figure 7: IPv4 header
 (1) The DSCP is marked according to the application's requirements.
     If it can be assumed that replicable connections belong to the
     same diffserv class, then it is likely that the DSCP will be
     replicable.  The DSCP can be set not only by the sender but by
     any packet marker.  Thus, a flow may have a number of DSCP values
     at different points in the network.  However, header compression

West & McCann Informational [Page 12] RFC 4413 TCP/IP Field Behavior March 2006

     operates on a point-to-point link and so would expect to see a
     relatively stable value.  If re-marking is being done based on
     the state of a meter, then the value may change mid-flow.
     Overall, though, we expect supporting replication of the DSCP to
     be useful for header compression.
 (2) It is not possible for the ECN bits to be replicated (note that
     use of the ECN nonce scheme [19] is anticipated).  However, it
     seems likely that all TCP flows between ECN-capable hosts will
     use ECN, the use (or not) of ECN for flows between the same end-
     points might be considered replicable.  See also note (4).
 (3) The replicable context for this field includes the IP-ID, NBO,
     and RND flags (as described in ROHC RTP).  This highlights that
     the replication is of the context, rather than just the header
     field values and, as such, needs to be considered based on the
     exact nature of compression applied to each field.
 (4) Since the possible future behavior of the 'Reserved Flag' cannot
     be predicted, it is not considered as replicable.  However, it
     might be expected that the behavior of the reserved flag between
     the same end-points will be similar.  In this case, any selection
     of packet formats (for example) based on this behavior might
     carry across to the new flow.  In the case of packet formats,
     this can probably be considered as a compressor-local decision.
 (5) In theory, the DF bit may be replicable.  However, this is not
     guaranteed and, in practice, it is unlikely to be useful to do
     this.  From the perspective of header compression, having to
     indicate whether or not a 1-bit flag should be replicated or
     specified explicitly is likely to require more bits than simply
     conveying the value of the flag.  We do not rule out DF
     replication.

West & McCann Informational [Page 13] RFC 4413 TCP/IP Field Behavior March 2006

3.2. IPv6 Header (inner and/or outer)

        +-----------------------+---------------+------------+
        | Field                 | Class         | Replicable |
        +-----------------------+---------------+------------+
        | Version               | STATIC        | N/A        |
        | Traffic Class         | CHANGING      | Yes (1)    |
        | ECT flag              | CHANGING      | No  (2)    |
        | CE flag               | CHANGING      | No  (2)    |
        | Flow Label            | STATIC-DEF    | N/A        |
        | Payload Length        | INFERRED      | N/A        |
        | Next Header           | STATIC        | N/A        |
        | Hop Limit             | CHANGING      | Yes        |
        | Source Address        | STATIC-DEF    | Yes        |
        | Destination Address   | STATIC-DEF    | Yes        |
        +-----------------------+---------------+------------+
          (1) See comment about DSCP field for IPv4, above.
          (2) See comment about ECT and CE flags for IPv4, above.
                        Figure 8.  IPv6 Header

3.3. TCP Header

        +-----------------------+---------------+------------+
        | Field                 | Class         | Replicable |
        +-----------------------+---------------+------------+
        | Source Port           | STATIC-DEF    |  Yes (1)   |
        | Destination Port      | STATIC-DEF    |  Yes (1)   |
        | Sequence Number       | CHANGING      |  No  (2)   |
        | Acknowledgement Number| CHANGING      |  No        |
        | Data Offset           | INFERRED      |  N/A       |
        | Reserved Bits         | CHANGING      |  No  (3)   |
        | Flags                 |               |            |
        |         CWR           | CHANGING      |  No  (4)   |
        |         ECE           | CHANGING      |  No  (4)   |
        |         URG           | CHANGING      |  No        |
        |         ACK           | CHANGING      |  No        |
        |         PSH           | CHANGING      |  No        |
        |         RST           | CHANGING      |  No        |
        |         SYN           | CHANGING      |  No        |
        |         FIN           | CHANGING      |  No        |
        | Window                | CHANGING      |  Yes       |
        | Checksum              | CHANGING      |  No        |
        | Urgent Pointer        | CHANGING      |  Yes (5)   |
        +-----------------------+---------------+------------+
                         Figure 9: TCP Header

West & McCann Informational [Page 14] RFC 4413 TCP/IP Field Behavior March 2006

 (1) On the server side, the port number is likely to be a well-known
     value.  On the client side, the port number is generally selected
     by the stack automatically.  Whether the port number is
     replicable depends upon how the stack chooses the port number.
     Whilst most implementations use a simple scheme that sequentially
     picks the next available port number, it may not be desirable to
     rely on this behavior.
 (2) With the recommendation (and expected deployment) of TCP Initial
     Sequence Number randomization, defined in RFC 1948 [10], it will
     be impossible to share the sequence number.  Thus, this field
     will not be regarded as replicable.
 (3) See comment (4) for the IPv4 header, above.
 (4) See comment (2) on ECN flags for the IPv4 header, above.
 (5) The urgent pointer is very rarely used.  This means that, in
     practice, the field may be considered replicable.

3.4. TCP Options

        +---------------------------+--------------+------------+
        | Option                    | SYN-only (1) | Replicable |
        +---------------------------+--------------+------------+
        | End of Option List        | No           | No   (2)   |
        | No-Operation              | No           | No   (2)   |
        | Maximum Segment Size      | Yes          | Yes        |
        | Window Scale              | Yes          | Yes        |
        | SACK-Permitted            | Yes          | Yes        |
        | SACK                      | No           | No         |
        | Timestamp                 | No           | No         |
        +---------------------------+--------------+------------+
                           Figure 10.  TCP Options
 (1) This indicates whether the option only appears in SYN packets.
     Options that are not 'SYN-only' may appear in any packet.  Many
     TCP options are used only in SYN packets.  Some options, such as
     MSS, Window Scale, and SACK-Permitted, will tend to have the same
     value among replicable packet streams.
     Thus, to support context sharing, the compressor should maintain
     such TCP options in the context (even though they only appear in
     the SYN segment).
 (2) Since these options have fixed values, they could be regarded as
     replicable.  However, the only interesting thing to convey about

West & McCann Informational [Page 15] RFC 4413 TCP/IP Field Behavior March 2006

     these options is their presence.  If it is known that such an
     option exists, its value is defined.

3.5. Summary of Replication

 From the above analysis, it can be seen that there are reasonable
 grounds for exploiting redundancy between flows as well as between
 packets within a flow.  Simply consider the advantage of being able
 to elide the source and destination addresses for a repeated
 connection between two IPv6 endpoints.  There will also be a cost (in
 terms of complexity and robustness) for replicating contexts, and
 this must be considered when one decides what constitutes an
 appropriate solution.
 Finally, note that the use of replication requires that the
 compressor have a suitable degree of confidence that the source data
 is present and correct at the decompressor.  This may place some
 restrictions on which of the 'changing' fields, in particular, can be
 utilised during replication.

4. Analysis of Change Patterns of Header Fields

 To design suitable mechanisms for efficient compression of all header
 fields, their change patterns must be analyzed.  For this reason, an
 extended classification is done based on the general classification
 in 2, considering the fields that were labeled CHANGING in that
 classification.
 The CHANGING fields are separated into five different subclasses:
 o  STATIC
    These are fields that were classified as CHANGING on a general
    basis, but that are classified as STATIC here due to certain
    additional assumptions.
 o  SEMISTATIC
    These fields are STATIC most of the time.  However, occasionally
    the value changes but reverts to its original value after a known
    number of packets.
 o  RARELY-CHANGING (RC)
    These are fields that change their values occasionally and then
    keep their new values.

West & McCann Informational [Page 16] RFC 4413 TCP/IP Field Behavior March 2006

 o  ALTERNATING
    These fields alternate between a small number of different values.
 o  IRREGULAR
    These, finally, are the fields for which no useful change pattern
    can be identified.
 To further expand the classification possibilities without increasing
 complexity, the classification can be done either according to the
 values of the field and/or according to the values of the deltas for
 the field.
 When the classification is done, other details are also stated
 regarding possible additional knowledge about the field values and/or
 field deltas, according to the classification.  For fields classified
 as STATIC or SEMISTATIC, the value of the field could be not only
 STATIC but also well-KNOWN a priori (two states for SEMISTATIC
 fields).  For fields with non-irregular change behavior, it could be
 known that changes are usually within a LIMITED range compared to the
 maximal change for the field.  For other fields, the values are
 completely UNKNOWN.
 Figure 11 classifies all the CHANGING fields on the basis of their
 expected change patterns. (4) refers to IPv4 fields and (6) refers to
 IPv6.

West & McCann Informational [Page 17] RFC 4413 TCP/IP Field Behavior March 2006

 +------------------------+-------------+-------------+-------------+
 | Field                  | Value/Delta |    Class    |  Knowledge  |
 +========================+=============+=============+=============+
 | DSCP(4) / Tr.Class(6)  | Value       | ALTERNATING |   UNKNOWN   |
 +------------------------+-------------+-------------+-------------+
 | IP ECT flag(4)         | Value       |      RC     |   UNKNOWN   |
 +------------------------+-------------+-------------+-------------+
 | IP CE flag(4)          | Value       |      RC     |   UNKNOWN   |
 +------------------------+-------------+-------------+-------------+
 |             Sequential | Delta       |    STATIC   |    KNOWN    |
 |             -----------+-------------+-------------+-------------+
 | IP Id(4)     Seq. jump | Delta       |      RC     |   LIMITED   |
 |             -----------+-------------+-------------+-------------+
 |                 Random | Value       |  IRREGULAR  |   UNKNOWN   |
 +------------------------+-------------+-------------+-------------+
 | IP DF flag(4)          | Value       |      RC     |   UNKNOWN   |
 +------------------------+-------------+-------------+-------------+
 | IP TTL(4) / Hop Lim(6) | Value       | ALTERNATING |   LIMITED   |
 +------------------------+-------------+-------------+-------------+
 | TCP Sequence Number    | Delta       |  IRREGULAR  |   LIMITED   |
 +------------------------+-------------+-------------+-------------+
 | TCP Acknowledgement Num| Delta       |  IRREGULAR  |   LIMITED   |
 +------------------------+-------------+-------------+-------------+
 | TCP Reserved           | Value       |      RC     |   UNKNOWN   |
 +------------------------+-------------+-------------+-------------+
 | TCP flags              |             |             |             |
 |     ECN flags          | Value       |  IRREGULAR  |   UNKNOWN   |
 |     CWR flag           | Value       |  IRREGULAR  |   UNKNOWN   |
 |     ECE flag           | Value       |  IRREGULAR  |   UNKNOWN   |
 |     URG flag           | Value       |  IRREGULAR  |   UNKNOWN   |
 |     ACK flag           | Value       |  SEMISTATIC |    KNOWN    |
 |     PSH flag           | Value       |  IRREGULAR  |   UNKNOWN   |
 |     RST flag           | Value       |  IRREGULAR  |   UNKNOWN   |
 |     SYN flag           | Value       |  SEMISTATIC |    KNOWN    |
 |     FIN flag           | Value       |  SEMISTATIC |    KNOWN    |
 +------------------------+-------------+-------------+-------------+
 | TCP Window             | Value       | ALTERNATING |    KNOWN    |
 +------------------------+-------------+-------------+-------------+
 | TCP Checksum           | Value       |  IRREGULAR  |   UNKNOWN   |
 +------------------------+-------------+-------------+-------------+
 | TCP Urgent Pointer     | Value       |  IRREGULAR  |    KNOWN    |
 +------------------------+-------------+-------------+-------------+
 | TCP Options            | Value       |  IRREGULAR  |   UNKNOWN   |
 +------------------------+-------------+-------------+-------------+
             Figure 11.  Classification of CHANGING Fields

West & McCann Informational [Page 18] RFC 4413 TCP/IP Field Behavior March 2006

 The following subsections discuss the various header fields in
 detail.  Note that Table 1 and the discussion below do not consider
 changes caused by loss or reordering before the compression point.

4.1. IP Header

4.1.1. IP Traffic-Class / Type-Of-Service (TOS)

 The Traffic-Class (IPv6) or Type-Of-Service/DSCP (IPv4) field might
 be expected to change during the lifetime of a packet stream.  This
 analysis considers several RFCs that describe modifications to the
 original RFC 791 [1].
 The TOS byte was initially described in RFC 791 [1] as 3 bits of
 precedence followed by 3 bits of TOS and 2 reserved bits (defined to
 be zero).  RFC 1122 [21] extended this to specify 5 bits of TOS,
 although the meanings of the additional 2 bits were not defined.  RFC
 1349 [23] defined the 4th bit of TOS as 'minimize monetary cost'.
 The next significant change was in RFC 2474 [14] (obsoleting RFC 1349
 [23]).  RFC 2474 reworked the TOS octet as 6 bits of DSCP (DiffServ
 Code Point) plus 2 unused bits.  Most recently, RFC 2780 [30]
 identified the 2 reserved bits in the TOS or traffic class octet for
 experimental use with ECN.
 It is therefore proposed that the TOS (or traffic class) octet be
 classified as 6 bits for the DSCP and 2 additional bits.  These 2
 bits may be expected to be zero or to contain ECN data.  From a
 future-proofing perspective, it is preferable to assume the use of
 ECN, especially with respect to TCP.
 It is also considered important that the profile work with legacy
 stacks, since these will be in existence for some considerable time
 to come.  For simplicity, this will be considered as 6 bits of TOS
 information and 2 bits of ECN data, so the fields are always
 considered to be structured the same way.
 The DSCP (as for TOS in ROHC RTP) is not expected to change
 frequently (although it could change mid-flow, for example, as a
 result of a route change).

4.1.2. ECN Flags

 Initially, we describe the ECN flags as specified in RFC 2481 [15]
 and RFC 3168 [18].  Subsequently, a suggested update is described
 that would alter the behavior of the flags.
 In RFC 2481 [15] there are 2 separate flags, the ECT (ECN Capable
 Transport) flag and the CE (Congestion Experienced) flag.  The ECT

West & McCann Informational [Page 19] RFC 4413 TCP/IP Field Behavior March 2006

 flag, if negotiated by the TCP stack, will be '1' for all data
 packets and '0' for all 'pure acknowledgement' packets.  This means
 that the behavior of the ECT flag is linked to behavior in the TCP
 stack.  Whether this can be exploited for compression is not clear.
 The CE flag is only used if ECT is set to '1'.  It is set to '0' by
 the sender and can be set to '1' by an ECN-capable router in the
 network to indicate congestion.  Thus the CE flag is expected to be
 randomly set to '1' with a probability dependent on the congestion
 state of the network and the position of the compressor in the path.
 Therefore, a compressor located close to the receiver in a congested
 network will see the CE bit set frequently, but a compressor located
 close to a sender will rarely, if ever, see the CE bit set to '1'.
 A recent experimental proposal [19] suggests an alternative view of
 these 2 bits.  This considers the two bits together to have 4
 possible codepoints.  Meanings are then assigned to the codepoints:
    00 Not ECN capable
    01 ECN capable, no congestion (known as ECT(0))
    10 ECN capable, no congestion (known as ECT(1))
    11 Congestion experienced
 The use of 2 codepoints for signaling ECT allows the sender to detect
 when a receiver is not reliably echoing congestion information.
 For the purposes of compression, this update means that ECT(0) and
 ECT(1) are equally likely (for an ECN capable flow) and that '11'
 will be seen relatively rarely.  The probability of seeing a
 congestion indication is discussed above in the description of the CE
 flag.
 It is suggested that, for the purposes of compression, ECN with
 nonces be assumed as the baseline, although the compression scheme
 must be able to compress the original ECN scheme transparently.

4.1.3. IP Identification

 The Identification field (IP ID) of the IPv4 header identifies which
 fragments constitute a datagram, when fragmented datagrams are
 reassembled.  The IPv4 specification does not specify exactly how
 this field is to be assigned values, only that each packet should get
 an IP ID that is unique for the source-destination pair and protocol
 for the time during which the datagram (or any of its fragments)
 could be alive in the network.  This means that assignment of IP ID
 values can be done in various ways, which we have separated into
 three classes:

West & McCann Informational [Page 20] RFC 4413 TCP/IP Field Behavior March 2006

 o  Sequential jump
    This is the most common assignment policy in today's IP stacks.  A
    single IP ID counter is used for all packet streams.  When the
    sender is running more than one packet stream simultaneously, the
    IP ID can increase by more than one between packets in a stream.
    The IP ID values will be much more predictable and will require
    fewer bits to transfer than random values, and the packet-to-
    packet increment (determined by the number of active outgoing
    packet streams and sending frequencies) will usually be limited.
 o  Random
    Some IP stacks assign IP ID values by using a pseudo-random number
    generator.  There is thus no correlation between the ID values of
    subsequent datagrams.  Therefore, there is no way to predict the
    IP ID value for the next datagram.  For header compression
    purposes, this means that the IP ID field needs to be sent
    uncompressed with each datagram, resulting in two extra octets of
    header.  IP stacks in cellular terminals that need optimum header
    compression efficiency should not use this IP ID assignment
    policy.
 o  Sequential
    This assignment policy keeps a separate counter for each outgoing
    packet stream, and thus the IP ID value will increment by one for
    each packet in the stream, except at wrap around.  Therefore, the
    delta value of the field is constant and well known a priori.
    This assignment policy is the most desirable for header
    compression purposes.  However, its usage is not as common as it
    perhaps should be.
    In order to avoid violating RFC 791 [1], packets sharing the same
    IP address pair and IP protocol number cannot use the same IP ID
    values.  Therefore, implementations of sequential policies must
    make the ID number spaces disjoint for packet streams of the same
    IP protocol going between the same pair of nodes.  This can be
    done in a number of ways, all of which introduce occasional jumps
    and thus make the policy less than perfectly sequential.  For
    header compression purposes, less frequent jumps are preferred.
 Note that the ID is an IPv4 mechanism and is therefore not a problem
 for IPv6.  For IPv4, the ID could be handled in three different ways.
 First, we have the inefficient but reliable solution where the ID
 field is sent as-is in all packets, increasing the compressed headers
 by two octets.  This is the best way to handle the ID field if the
 sender uses random assignment of the ID field.  Second, there can be

West & McCann Informational [Page 21] RFC 4413 TCP/IP Field Behavior March 2006

 solutions with more flexible mechanisms that require fewer bits for
 the ID handling as long as sequential jump assignment is used.  Such
 solutions will probably require even more bits if random assignment
 is used by the sender.  Knowledge about the sender's assignment
 policy could therefore be useful when choosing between the two
 solutions above.  Finally, even for IPv4, header compression could be
 designed without any additional information for the ID field included
 in compressed headers.  To use such schemes, it must be known which
 assignment policy for the ID field is being used by the sender.  That
 might not be possible to know, which implies that the applicability
 of such solutions is very uncertain.  However, designers of IPv4
 stacks for cellular terminals should use an assignment policy close
 to sequential.
 With regard to TCP compression, the behavior of the IP ID field is
 essentially the same.  However, in RFC 3095 [31], the IP ID is
 generally inferred from the RTP Sequence Number.  There is no obvious
 candidate in the TCP case for a field to offer this 'master sequence
 number' role.
 Clearly, from a busy server, the observed behavior may well be quite
 erratic.  This is a case where the ability to share the IP
 compression context between a number of flows (between the same end-
 points) could offer potential benefits.  However, this would only
 have any real impact where there is a large number of flows between
 one machine and the server.  If context sharing is being considered,
 then it is preferable to share the IP part of the context.

4.1.4. Don't Fragment (DF) flag

 Path-MTU discovery (RFC 1191 for IPv4 [6] and RFC 1981 for IPv6 [11])
 is widely deployed for TCP, in contrast to little current use for UDP
 packet streams.  This employs the DF flag value of '1' to detect the
 need for fragmentation in the end-to-end path and to probe the
 minimum MTU along the network path.  End hosts using this technique
 may be expected to send all packets with DF set to '1', although a
 host may end PMTU discovery by clearing the DF bit to '0'.  Thus, for
 compression, we expect the field value to be stable.

4.1.5. IP Hop-Limit / Time-To-Live (TTL)

 The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be
 constant during the lifetime of a packet stream or to alternate
 between a limited number of values due to route changes.

West & McCann Informational [Page 22] RFC 4413 TCP/IP Field Behavior March 2006

4.2. TCP Header

 Any discussion of compressability of TCP fields borrows heavily from
 RFC 1144 [22].  However, the premise of how the compression is
 performed is slightly different, and the protocol has evolved
 slightly in the intervening time.

4.2.1. Sequence Number

 Understanding the sequence and acknowledgement number behavior is
 essential for a TCP compression scheme.
 At the simplest level, the behavior of the sequence number can be
 described relatively easily.  However, there are a number of
 complicating factors that also need to be considered.
 For transferring in-sequence data packets, the sequence number will
 increment for each packet by between 0 and an upper limit defined by
 the MSS (Maximum Segment Size) and, if it is being used, by Path-MTU
 discovery.
 There are common MSS values, but these can be quite variable and
 unpredictable for any given flow.  Given this variability and the
 range of window sizes, it is hard (compared with the RTP case, for
 example) to select a 'one size fits all' encoding for the sequence
 number.  (The same argument applies equally to the acknowledgement
 number).
 Note that the increment of the sequence number in a packet is the
 size of the data payload of that packet (including the SYN and FIN
 flags).  This is, of course, exactly the relationship that RFC 1144
 [22] exploits to compress the sequence number in the most efficient
 case.  This technique may not be directly applicable to a robust
 solution, but it may be a useful relationship to consider.
 However, at any point on the path (i.e., wherever a compressor might
 be deployed), the sequence number can be anywhere within a range
 defined by the TCP window.  This is a combination of a number of
 values (buffer space at the sender; advertised buffer size at the
 receiver; and TCP congestion control algorithms).  Missing packets or
 retransmissions can cause the TCP sequence number to fluctuate within
 the limits of this window.
 It is desirable to be able to predict the sequence number with some
 regularity.  However, this also appears to be difficult to do.  For
 example, during bulk data transfer, the sequence number will tend to
 go up by 1 MSS per packet (assuming no packet loss).  Higher layer
 values have been seen to have an impact as well, where sequence

West & McCann Informational [Page 23] RFC 4413 TCP/IP Field Behavior March 2006

 number behavior has been observed with an 8 kbyte repeating pattern
 -- 5 segments of 1460 bytes followed by 1 segment of 892 bytes.  The
 implementation of TCP and the management of buffers within a protocol
 stack can affect the behavior of the sequence number.
 It may be possible to track the TCP window by the compressor,
 allowing it to bound the size of these jumps.
 For interactive flows (for example, telnet), the sequence number will
 change by small, irregular amounts.  In this case, the Nagle
 algorithm [3] commonly applies, coalescing small packets where
 possible in order to reduce the basic header overhead.  This may also
 mean that predictable changes in the sequence number are less likely
 to occur.  The Nagle algorithm is an optimisation and is not required
 to be used (applications can disable its use).  However, it is turned
 on by default in all common TCP implementations.
 Note also that the SYN and FIN flags (which have to be acknowledged)
 each consume 1 byte of sequence space.

4.2.2. Acknowledgement Number

 Much of the information about the sequence number applies equally to
 the acknowledgement number.  However, there are some important
 differences.
 For bulk data transfers, there will tend to be 1 acknowledgement for
 every 2 data segments.  The algorithm is specified in RFC 2581 [16].
 An ACK need not always be sent immediately on receipt of a data
 segment, but it must be sent within 500ms and should be generated for
 at least every second full-size segment (MSS) of received data.  It
 may be seen from this that the delta for the acknowledgement number
 is roughly twice that of the sequence number.  This is not always the
 case, and the discussion about sequence number irregularity should be
 applied.
 As an aside, a common implementation bug is 'stretch ACKs' [33]
 (acknowledgements may be generated less frequently than every two
 full-size data segments).  This pattern can also occur following loss
 on the return path.
 Since the acknowledgement number is cumulative, dropped packets in
 the forward path will result in the acknowledgement number remaining
 constant for a time in the reverse direction.  Retransmission of a
 dropped segment can then cause a substantial jump in the
 acknowledgement number.  These jumps in acknowledgement number are
 bounded by the TCP window, just as for the jumps in sequence number.

West & McCann Informational [Page 24] RFC 4413 TCP/IP Field Behavior March 2006

 In the acknowledgement case, information about the advertised
 received window gives a bound to the size of any ACK jump.

4.2.3. Reserved

 This field is reserved, and it therefore might be expected to be
 zero.  This can no longer be assumed, due to future-proofing.  It is
 only a matter of time before a suggestion for using the flag is made.

4.2.4. Flags

 o  ECN-E (Explicit Congestion Notification)
    '1' to echo CE bit in IP header.  It will be set in several
    consecutive headers (until 'acknowledged' by CWR).  If ECN nonces
    are used, then there will be a 'nonce-sum' (NS) bit in the flags,
    as well.  Again, transparency of the reserved bits is crucial for
    future-proofing this compression scheme.  From an
    efficiency/compression standpoint, the NS bit will either be
    unused (always '0') or randomly changing.  The nonce sum is the
    1-bit sum of the ECT codepoints, as described in [19].
 o  CWR (Congestion Window Reduced)
    '1' to signal congestion window reduced on ECN.  It will generally
    be set in individual packets.  The flag will be set once per loss
    event.  Thus, the probability of its being set is proportional to
    the degree of congestion in the network, but it is less likely to
    be set than the CE flag.
 o  ECE (Echo Congestion Experience)
    If 'congestion experienced' is signaled in a received IP header,
    this is echoed through the ECE bit in segments sent by the
    receiver until acknowledged by seeing the CWR bit set.  Clearly,
    in periods of high congestion and/or long RTT, this flag will
    frequently be set to '1'.
    During connection open (SYN and SYN/ACK packets), the ECN bits
    have special meaning:
  • CWR and ECN-E are both set with SYN to indicate desire to use

ECN.

West & McCann Informational [Page 25] RFC 4413 TCP/IP Field Behavior March 2006

  • CWR only is set in SYN-ACK, to agree to ECN.
      (The difference in bit-patterns for the negotiation is such that
      it will work with broken stacks that reflect the value of
      reserved bits).
 o  URG (Urgent Flag)
    '1' to indicate urgent data (which is unlikely with any flag other
    than ACK).
 o  ACK (Acknowledgement)
    '1' for all except the initial 'SYN' packet.
 o  PSH (Push Function Field)
    Generally accepted to be randomly '0' or '1'.  However, it may be
    biased more to one value than the other (this is largely caused by
    the implementation of the stack).
 o  RST (Reset Connection)
    '1' to reset a connection (unlikely with any flag other than ACK).
 o  SYN (Synchronize Sequence Number)
    '1' for the SYN/SYN-ACK, only at the start of a connection.
 o  FIN (End of Data: FINished)
    '1' to indicate 'no more data' (unlikely with any flag other than
    ACK).

4.2.5. Checksum

 Carried as the end-to-end check for the TCP data.  See RFC 1144 [22]
 for a discussion of why this should be carried.  A header compression
 scheme should not rely upon the TCP checksum for robustness, though,
 and should apply appropriate error-detection mechanisms of its own.
 The TCP checksum has to be considered to be randomly changing.

4.2.6. Window

 This may oscillate randomly between 0 and the receiver's window limit
 (for the connection).

West & McCann Informational [Page 26] RFC 4413 TCP/IP Field Behavior March 2006

 In practice, the window will either not change or alternate between a
 relatively small number of values.  Particularly when the window is
 closing (its value is getting smaller), the change in window is
 likely to be related to the segment size, but it is not clear that
 this necessarily offers any compression advantage.  When the window
 is opening, the effect of 'Silly-Window Syndrome' avoidance should be
 remembered.  This prevents the window from opening by small amounts
 that would encourage the sender to clock out small segments.
 When thinking about what fields might change in a sequence of TCP
 segments, one should note that the receiver can generate 'window
 update' segments in which only the window advertisement changes.

4.2.7. Urgent Pointer

 From a compression point of view, the Urgent Pointer is interesting
 because it offers an example where 'semantically identical'
 compression is not the same as 'bitwise identical'.  This is because
 the value of the Urgent Pointer is only valid if the URG flag is set.
 However, the TCP checksum must be passed transparently, in order to
 maintain its end-to-end integrity checking property.  Since the TCP
 checksum includes the Urgent Pointer in its coverage, this enforces
 bitwise transparency of the Urgent Pointer.  Thus, the issue of
 'semantic' vs. 'bitwise' identity is presented as a note: the Urgent
 Pointer must be compressed in a way that preserves its value.
 If the URG flag is set, then the Urgent Pointer indicates the end of
 the urgent data and thus can point anywhere in the window.  It may be
 set (and changing) over several segments.  Note that urgent data is
 rarely used, since it is not a particularly clean way of managing
 out-of-band data.

4.3. Options

 Options occupy space at the end of the TCP header.  All options are
 included in the checksum.  An option may begin on any byte boundary.
 The TCP header must be padded with zeros to make the header length a
 multiple of 32 bits.
 Optional header fields are identified by an option kind field.
 Options 0 and 1 are exactly one octet, which is their kind field.
 All other options have their one-octet kind field, followed by a
 one-octet length field, followed by length-2 octets of option data.

West & McCann Informational [Page 27] RFC 4413 TCP/IP Field Behavior March 2006

4.3.1. Options Overview

 The IANA provides the authoritative list of TCP options.  Figure 12
 describes the current allocations at the time of publication.  Any
 new option would have a 'kind' value assigned by IANA.  The list is
 available at [20].  Where applicable, the associated RFC is also
 cited.
 +----+-------+------------------------------------+----------+-----+
 |Kind|Length |               Meaning              |    RFC   | Use |
 |    |octets |                                    |          |     |
 +----+-------+------------------------------------+----------+-----+
 |  0 |   -   | End of Option List                 | RFC 793  |  *  |
 |  1 |   -   | No-Operation                       | RFC 793  |  *  |
 |  2 |   4   | Maximum Segment Size               | RFC 793  |  *  |
 |  3 |   3   | WSopt - Window Scale               | RFC 1323 |  *  |
 |  4 |   2   | SACK Permitted                     | RFC 2018 |  *  |
 |  5 |   N   | SACK                               | RFC 2018 |  *  |
 |  6 |   6   | Echo (obsoleted by option 8)       | RFC 1072 |     |
 |  7 |   6   | Echo Reply (obsoleted by option 8) | RFC 1072 |     |
 |  8 |  10   | TSopt - Time Stamp Option          | RFC 1323 |  *  |
 |  9 |   2   | Partial Order Connection Permitted | RFC 1693 |     |
 | 10 |   3   | Partial Order Service Profile      | RFC 1693 |     |
 | 11 |   6   | CC                                 | RFC 1644 |     |
 | 12 |   6   | CC.NEW                             | RFC 1644 |     |
 | 13 |   6   | CC.ECHO                            | RFC 1644 |     |
 | 14 |   3   | Alternate Checksum Request         | RFC 1146 |     |
 | 15 |   N   | Alternate Checksum Data            | RFC 1146 |     |
 | 16 |       | Skeeter                            |          |     |
 | 17 |       | Bubba                              |          |     |
 | 18 |   3   | Trailer Checksum Option            |          |     |
 | 19 |  18   | MD5 Signature Option               | RFC 2385 |     |
 | 20 |       | SCPS Capabilities                  |          |     |
 | 21 |       | Selective Negative Acks            |          |     |
 | 22 |       | Record Boundaries                  |          |     |
 | 23 |       | Corruption experienced             |          |     |
 | 24 |       | SNAP                               |          |     |
 | 25 |       | Unassigned (released 12/18/00)     |          |     |
 | 26 |       | TCP Compression Filter             |          |     |
 +----+-------+------------------------------------+----------+-----+
                    Figure 12.  Common TCP Options
 The 'use' column is marked with '*' to indicate options that are most
 likely to be seen in TCP flows.  Also note that RFC 1072 [4] has been
 obsoleted by RFC 1323 [7], although the original bit usage is defined
 only in RFC 1072.

West & McCann Informational [Page 28] RFC 4413 TCP/IP Field Behavior March 2006

4.3.2. Option Field Behavior

 Generally speaking, all option fields have been classified as
 changing.  This section describes the behavior of each option
 referenced within an RFC, listed by 'kind' indicator.
    0: End of Option List
       This option code indicates the end of the option list.  This
       might not coincide with the end of the TCP header according to
       the Data Offset field.  This is used at the end of all options,
       not at the end of each option, and it need only be used if the
       end of the options would not otherwise coincide with the end of
       the TCP header.  Defined in RFC 793 [2].
       There is no data associated with this option, so a compression
       scheme must simply be able to encode its presence.  However,
       note that since this option marks the end of the list and the
       TCP options are 4-octet aligned, there may be octets of padding
       (defined to be '0' in [2]) after this option.
    1: No-Operation
       This option code may be used between options, for example, to
       align the beginning of a subsequent option on a word boundary.
       There is no guarantee that senders will use this option, so
       receivers must be prepared to process options even if they do
       not begin on a word boundary RFC 793 [2].  There is no data
       associated with this option, so a compression scheme must
       simply be able to encode its presence.  This may be done by
       noting that the option simply maintains a certain alignment and
       that compression need only convey this alignment.  In this way,
       padding can just be removed.
    2: Maximum Segment Size
       If this option is present, then it communicates the maximum
       segment size that may be used to send a packet to this end-
       host.  This field must only be sent in the initial connection
       request (i.e., in segments with the SYN control bit set).  If
       this option is not used, any segment size is allowed RFC 793
       [2].
       This option is very common.  The segment size is a 16-bit
       quantity.  Theoretically, this could take any value; however
       there are a number of values that are common.  For example,
       1460 bytes is very common for TCP/IPv4 over Ethernet (though
       with the increased prevalence of tunnels, for example, smaller

West & McCann Informational [Page 29] RFC 4413 TCP/IP Field Behavior March 2006

       values such as 1400 have become more popular). 536 bytes is the
       default MSS value.  This may allow for common values to be
       encoded more efficiently.
    3: Window Scale Option (WSopt)
       This option may be sent in a SYN segment by the TCP end-host
       (1) to indicate that the sending TCP end-host is prepared to
           perform both send and receive window scaling, and
       (2) to communicate a scale factor to be applied to its receive
           window.
       The scale factor is encoded logarithmically as a power of 2
       (presumably to be implemented by binary shifts).  Note that the
       window in the SYN segment itself is never scaled (RFC 1072
       [4]).  This option may be sent in an initial segment (i.e., in
       a segment with the SYN bit on and the ACK bit off).  It may
       also be sent in later segments, but only if a Window Scale
       option was received in the initial segment.  A Window Scale
       option in a segment without a SYN bit should be ignored.  The
       Window field in a SYN segment itself is never scaled (RFC 1323
       [7]).
       The use of window scaling does not affect the encoding of any
       other field during the lifetime of the flow.  Only the encoding
       of the window scaling option itself is important.  The window
       scale must be between 0 and 14 (inclusive).  Generally, smaller
       values would be expected (a window scale of 14 allows for a
       1Gbyte window, which is extremely large).
    4: SACK-Permitted
       This option may be sent in a SYN by a TCP that has been
       extended to receive (and presumably to process) the SACK option
       once the connection has opened RFC 2018 [12].  There is no data
       in this option all that is required is for the presence of the
       option to be encoded.
    5: SACK
       This option is to be used to convey extended acknowledgment
       information over an established connection.  Specifically, it
       is to be sent by a data receiver to inform the data transmitter
       of non-contiguous blocks of data that have been received and
       queued.  The data receiver awaits the receipt of data in later
       retransmissions to fill the gaps in sequence space between
       these blocks.  At that time, the data receiver acknowledges the
       data, normally by advancing the left window edge in the

West & McCann Informational [Page 30] RFC 4413 TCP/IP Field Behavior March 2006

       Acknowledgment Number field of the TCP header.  It is important
       to understand that the SACK option will not change the meaning
       of the Acknowledgment Number field, whose value will still
       specify the left window edge, i.e., one byte beyond the last
       sequence number of fully received data (RFC 2018 [12]).
       If SACK has been negotiated (through an exchange of SACK-
       Permitted options), then this option may occur when dropped
       segments are noticed by the receiver.  Because this identifies
       ranges of blocks within the receiver's window, it can be viewed
       as a base value with a number of offsets.  The base value (left
       edge of the first block) can be viewed as offset from the TCP
       acknowledgement number.  There can be up to 4 SACK blocks in a
       single option.  SACK blocks may occur in a number of segments
       (if there is more out-of-order data 'on the wire'), and this
       will typically extend the size of or add to the existing
       blocks.
       Alternative proposals such as DSACK RFC 2883 [17] do not
       fundamentally change the behavior of the SACK block, from the
       point of view of the information contained within it.
    6: Echo
       This option carries information that the receiving TCP may send
       back in a subsequent TCP Echo Reply option (see below).  A TCP
       may send the TCP Echo option in any segment, but only if a TCP
       Echo option was received in a SYN segment for the connection.
       When the TCP echo option is used for RTT measurement, it will
       be included in data segments, and the four information bytes
       will define the time at which the data segment was transmitted
       in any format convenient to the sender (see RFC 1072 [4]).
       The Echo option is generally not used in practice -- it is
       obsoleted by the Timestamp option.  However, for transparency
       it is desirable that a compression scheme be able to transport
       it.  (However, there is no benefit in attempting any treatment
       more sophisticated than viewing it as a generic 'option').
    7: Echo Reply
       A TCP that receives a TCP Echo option containing four
       information bytes will return these same bytes in a TCP Echo
       Reply option.  This TCP Echo Reply option must be returned in
       the next segment (e.g., an ACK segment) that is sent.  If more
       than one Echo option is received before a reply segment is
       sent, the TCP must choose only one of the options to echo,

West & McCann Informational [Page 31] RFC 4413 TCP/IP Field Behavior March 2006

       ignoring the others; specifically, it must choose the newest
       segment with the oldest sequence number (see RFC 1072 [4]).
       The Echo Reply option is generally not used in practice -- it
       is obsoleted by the Timestamp option.  However, for
       transparency it is desirable that a compression scheme be able
       to transport it.  (However, there is no benefit in attempting
       any more sophisticated treatment than viewing it as a generic
       'option').
    8: Timestamps
       This option carries two four-byte timestamp fields.  The
       Timestamp Value field (TSval) contains the current value of the
       timestamp clock of the TCP sending the option.  The Timestamp
       Echo Reply field (TSecr) is only valid if the ACK bit is set in
       the TCP header; if it is valid, it echoes a timestamp value
       that was sent by the remote TCP in the TSval field of a
       Timestamps option.  When TSecr is not valid, its value must be
       zero.  The TSecr value will generally be from the most recent
       Timestamp option that was received; however, there are
       exceptions that are explained below.  A TCP may send the
       Timestamps option (TSopt) in an initial segment (i.e., a
       segment containing a SYN bit and no ACK bit), and it may send a
       TSopt in other segments only if it received a TSopt in the
       initial segment for the connection (see RFC 1323 [7]).
       Timestamps are quite commonly used.  If timestamp options are
       exchanged in the connection set-up phase, then they are
       expected to appear on all subsequent segments.  If this
       exchange does not happen, then they will not appear for the
       remainder of the flow.
       Because the value being carried is a timestamp, it is logical
       to expect that the entire value need not be carried.  There is
       no obvious pattern of increments that might be expected,
       however.
       An important reason for using the timestamp option is to allow
       detection of sequence space wrap-around (Protection Against
       Wrapped Sequence-number, or PAWS, see RFC 1323 [7]).  It is not
       expected that this is a serious concern on the links on which
       TCP header compression would be deployed, but it is important
       that the integrity of this option be maintained.  This issue is
       discussed in, for example, RFC 3150 [32].  However, the
       proposed Eifel algorithm [35] makes use of timestamps, so it is
       currently recommended that timestamps be used for cellular-type
       links [34].

West & McCann Informational [Page 32] RFC 4413 TCP/IP Field Behavior March 2006

       With regard to compression, note that the range of resolutions
       for the timestamp suggested in RFC 1323 [7] is quite wide (1ms
       to 1s per 'tick').  This (along with the perhaps wide variation
       in RTT) makes it hard to select a set of encodings that will be
       optimal in all cases.
    9: Partial Order Connection (POC) permitted
       This option represents a simple indicator communicated between
       the two peer transport entities to establish the operation of
       the POC protocol.  See RFC 1693 [9].
       The Partial Order Connection option sees little (or no) use in
       the current Internet, so the only requirement is that the
       header compression scheme be able to encode it.
    10: POC service profile
       This option serves to communicate the information necessary to
       carry out the job of the protocol -- the type of information
       that is typically found in the header of a TCP segment.  The
       Partial Order Connection option sees little (or no) use in the
       current Internet, so the only requirement is that the header
       compression scheme be able to encode it.
    11: Connection Count (CC)
       This option is part of the implementation of TCP Accelerated
       Open (TAO) that effectively bypasses the TCP Three-Way
       Handshake (3WHS).  TAO introduces a 32-bit incarnation number,
       called a "connection count" (CC), that is carried in a TCP
       option in each segment.  A distinct CC value is assigned to
       each direction of an open connection.  The implementation
       assigns monotonically increasing CC values to successive
       connections that it opens actively or passively (see RFC 1644
       [8]).  This option sees little (or no) use in the current
       Internet, so the only requirement is that the header
       compression scheme be able to encode it.
    12: CC.NEW
       Correctness of the TAO mechanism requires that clients generate
       monotonically increasing CC values for successive connection
       initiations.  Receiving a CC.NEW causes the server to
       invalidate its cache entry and to do a 3WHS.  See RFC 1644 [8].
       This option sees little (or no) use in the current Internet, so
       the only requirement is that the header compression scheme be
       able to encode it.

West & McCann Informational [Page 33] RFC 4413 TCP/IP Field Behavior March 2006

    13: CC.ECHO
       When a server host sends a segment, it echoes the connection
       count from the initial in a CC.ECHO option, which is used by
       the client host to validate the segment (see RFC 1644 [8]).
       This option sees little (or no) use in the current Internet, so
       the only requirement is that the header compression scheme be
       able to encode it.
    14: Alternate Checksum Request
       This option may be sent in a SYN segment by a TCP to indicate
       that the TCP is prepared to both generate and receive checksums
       based on an alternate algorithm.  During communication, the
       alternate checksum replaces the regular TCP checksum in the
       checksum field of the TCP header.  Should the alternate
       checksum require more than 2 octets to transmit, either the
       checksum may be moved into a TCP Alternate Checksum Data Option
       and the checksum field of the TCP header be sent as zero, or
       the data may be split between the header field and the option.
       Alternate checksums are computed over the same data as the
       regular TCP checksum; see RFC 1146 [5].
       This option sees little (or no) use in the current Internet, so
       the only requirement is that the header compression scheme be
       able to encode it.  It would only occur in connection set-up
       (SYN) packets.  Even if this option were used, it would not
       affect the handling of the checksum, since this should be
       carried transparently in any case.
    15: Alternate Checksum Data
       This field is used only when the alternate checksum that is
       negotiated is longer than 16 bits.  These checksums will not
       fit in the checksum field of the TCP header and thus at least
       part of them must be put in an option.  Whether the checksum is
       split between the checksum field in the TCP header and the
       option or the entire checksum is placed in the option is
       determined on a checksum-by-checksum basis.  The length of this
       option will depend on the choice of alternate checksum
       algorithm for this connection; see RFC 1146 [5].
       If an alternative checksum was negotiated in the connection
       set-up, then this option may appear on all subsequent packets
       (if needed to carry the checksum data).  However, this option
       is in practice never seen, so the only requirement is that the
       header compression scheme be able to encode it.

West & McCann Informational [Page 34] RFC 4413 TCP/IP Field Behavior March 2006

    16 - 18:
       These non-RFC option types are not considered in this document.
    19: MD5 Digest
       Every segment sent on a TCP connection to be protected against
       spoofing will contain the 16-byte MD5 digest produced by
       applying the MD5 algorithm to a concatenated block of data
       [13].
       Upon receiving a signed segment, the receiver must validate it
       by calculating its own digest from the same data (using its own
       key) and comparing the two digests.  A failing comparison must
       result in the segment's being dropped and must not produce any
       response back to the sender.  Logging the failure is probably
       advisable.
       Unlike other TCP extensions (e.g., the Window Scale option
       [7]), the absence of the option in the SYN-ACK segment must not
       cause the sender to disable its sending of signatures.  This
       negotiation is typically done to prevent some TCP
       implementations from misbehaving upon receiving options in non-
       SYN segments.  This is not a problem for this option, since the
       SYN-ACK sent during connection negotiation will not be signed
       and will thus be ignored.  The connection will never be made,
       and non-SYN segments with options will never be sent.  More
       importantly, the sending of signatures must be under the
       complete control of the application, not at the mercy of a
       remote host not understanding the option.  MD5 digest
       information should, like any cryptographically secure data, be
       incompressible.  Therefore the compression scheme must simply
       transparently carry this option, if it occurs.
    20 - 26;
       Thse non-RFC option types are not considered in this document.
       This only means that their behavior is not described in detail,
       as a compression scheme is not expected to be optimised for
       these options.  However, any unrecognised option must be
       carried by a TCP compression scheme transparently, in order to
       work efficiently in the presence of new or rare options.
 The above list covers options known at the time of writing.  Other
 options are expected to be defined.  It is important that any future
 options can be handled by a header compression scheme.  The
 processing of as-yet undefined options cannot be optimised but, at
 the very least, unknown options should be carried transparently.

West & McCann Informational [Page 35] RFC 4413 TCP/IP Field Behavior March 2006

 The current model for TCP options is that an option is negotiated in
 the SYN exchange and used thereafter, if the negotiation succeeds.
 This leads to some assumptions about the presence of options (being
 only on packets with the SYN flag set, or appearing on every packet,
 for example).  Where such assumptions hold true, it may be possible
 to optimise compression of options slightly.  However, it is seen as
 undesirable to be so constrained, as there is no guarantee that
 option handling and negotiation will remain the same in the future.
 Also note that a compressor may not process the SYN packets of a flow
 and cannot, therefore, be assumed to know which options have been
 negotiated.

5. Other Observations

5.1. Implicit Acknowledgements

 There may be a small number of cues for 'implicit acknowledgements'
 in a TCP flow.  Even if the compressor only sees the data transfer
 direction, for example, seeing a packet without the SYN flag set
 implies that the SYN packet has been received.
 There is a clear requirement for the deployment of compression to be
 topologically independent.  This means that it is not actually
 possible to be sure that seeing a data packet at the compressor
 guarantees that the SYN packet has been correctly received by the
 decompressor (as the SYN packet may have taken an alternative path).
 However, there may be other such cues, which may be used in certain
 circumstances to improve compression efficiency.

5.2. Shared Data

 It can be seen that there are two distinct deployments (i) where the
 forward (data) and reverse (ACK) path are both carried over a common
 link, and (ii) where the forward (data) and reverse (ACK) path are
 carried over different paths, with a specific link carrying packets
 corresponding to only one direction of communication.
 In the former case, a compressor and decompressor could be colocated.
 It may then be possible for the compressor and decompressor at each
 end of the link to exchange information.  This could lead to possible
 optimizations.
 For example, acknowledgement numbers are generally taken from the
 sequence numbers in the opposite direction.  Since an acknowledgement
 cannot be generated for a packet that has not passed across the link,
 this offers an efficient way of encoding acknowledgements.

West & McCann Informational [Page 36] RFC 4413 TCP/IP Field Behavior March 2006

5.3. TCP Header Overhead

 For a TCP bulk data-transfer, the overhead of the TCP header does not
 form a large proportion of the data packet (e.g., < 3% for a 1460
 octet packet), particularly compared to the typical RTP voice case.
 Spectral efficiency is clearly an important goal.  However,
 extracting every last bit of compression gain offers only marginal
 benefit at a considerable cost in complexity.  This trade-off, of
 efficiency and complexity, must be addressed in the design of a TCP
 compression profile.
 However, in the acknowledgement direction (i.e., for 'pure'
 acknowledgement headers), the overhead could be said to be infinite
 (since there is no data being carried).  This is why optimizations
 for the acknowledgement path may be considered useful.
 There are a number of schemes for manipulating TCP acknowledgements
 to reduce the ACK bandwidth.  Many of these are documented in [33]
 and [32].  Most of these schemes are entirely compatible with header
 compression, without requiring any particular support.  While it is
 not expected that a compression scheme will be optimised for
 experimental options, it is useful to consider these when developing
 header compression schemes, and vice versa.  A header compression
 scheme must be able to support any option (including ones as yet
 undefined).

5.4. Field Independence and Packet Behavior

 It should be apparent that direct comparisons with the highly
 'packet'-based view of RTP compression are hard.  RTP header fields
 tend to change regularly per-packet, and many fields (IPv4 IP ID, RTP
 sequence number, and RTP timestamp, for example) typically change in
 a dependent manner.  However, TCP fields, such as sequence number
 tend to change more unpredictably, partly because of the influence of
 external factors (size of TCP windows, application behavior, etc.).
 Also, the field values tend to change independently.  Overall, this
 makes compression more challenging and makes it harder to select a
 set of encodings that can successfully trade off efficiency and
 robustness.

5.5. Short-Lived Flows

 It is hard to see what can be done to improve performance for a
 single, unpredictable, short-lived connection.  However, there are
 commonly cases where there will be multiple TCP connections between
 the same pair of hosts.  As a particular example, consider web
 browsing (this is more the case with HTTP/1.0 [25] than with HTTP/1.1
 [26]).

West & McCann Informational [Page 37] RFC 4413 TCP/IP Field Behavior March 2006

 When a connection closes, either it is the last connection between
 that pair of hosts or it is likely that another connection will open
 within a relatively short space of time.  In this case, the IP header
 part of the context (i.e., those fields characterised in Section 2.1)
 will probably be almost identical.  Certain aspects of the TCP
 context may also be similar.
 Support for context replication is discussed in more detail in
 Section 3.  Overall, support for sub-context sharing or initializing
 one context from another offers useful optimizations for a sequence
 of short-lived connections.
 Note that, although TCP is connection oriented, it is hard for a
 compressor to tell whether a TCP flow has finished.  For example,
 even in the 'bi-directional' link case, seeing a FIN and the ACK of
 the FIN at the compressor/decompressor does not mean that the FIN
 cannot be retransmitted.  Thus, it may be more useful to think about
 initializing a new context from an existing one, rather than re-using
 an existing one.
 As mentioned previously in Section 4.1.3, the IP header can clearly
 be shared between any transport-layer flows between the same two
 end-points.  There may be limited scope for initialisation of a new
 TCP header from an existing one.  The port numbers are the most
 obvious starting point.

5.6. Master Sequence Number

 As pointed out earlier, in Section 4.1.3, there is no obvious
 candidate for a 'master sequence number' in TCP.  Moreover, it is
 noted that such a master sequence number is only required to allow a
 decompressor to acknowledge packets in bi-directional mode.  It can
 also be seen that such a sequence number would not be required for
 every packet.
 While the sequence number only needs to be 'sparse', it is clear that
 there is a requirement for an explicitly added sequence number.
 There are no obvious ways to guarantee the unique identity of a
 packet other than by adding such a sequence number (sequence and
 acknowledgement numbers can both remain the same, for example).

5.7. Size Constraint for TCP Options

 As can be seen from the above analysis, most TCP options, such as
 MSS, WSopt, or SACK-Permitted, may appear only on a SYN segment.
 Every implementation should (and we expect that most will) ignore
 unknown options on SYN segments.  TCP options will be sent on non-SYN
 segments only when an exchange of options on the SYN segments has

West & McCann Informational [Page 38] RFC 4413 TCP/IP Field Behavior March 2006

 indicated that both sides understand the extension.  Other TCP
 options, such as MD5 Digest or Timestamp, also tend to be sent when
 the connection is initiated (i.e., in the SYN packet).
 The total header size is also an issue.  The TCP header specifies
 where segment data starts with a 4-bit field that gives the total
 size of the header (including options) in 32-bit words.  This means
 that the total size of the header plus option must be less than or
 equal to 60 bytes.  This leaves 40 bytes for options.

6. Security Considerations

 Since this document only describes TCP field behavior, it raises no
 direct security concerns.
 This memo is intended to be used to aid the compression of TCP/IP
 headers.  Where authentication mechanisms such as IPsec AH [24] are
 used, it is important that compression be transparent.  Where
 encryption methods such as IPsec ESP [27] are used, the TCP fields
 may not be visible, preventing compression.

7. Acknowledgements

 Many IP and TCP RFCs (hopefully all of which have been collated
 below), together with header compression schemes from RFC 1144 [22],
 RFC 3544 [36], and RFC 3095 [31], and of course the detailed analysis
 of RTP/UDP/IP in RFC 3095, have been sources of ideas and knowledge.
 Further background information can also be found in [28] and [29].
 This document also benefited from discussion on the ROHC mailing list
 and in various corridors (virtual or otherwise) about many key
 issues; special thanks go to Qian Zhang, Carsten Bormann, and Gorry
 Fairhurst.
 Qian Zhang and Hongbin Liao contributed the extensive analysis of
 shareable header fields.
 Any remaining misrepresentation or misinterpretation of information
 is entirely the fault of the authors.

West & McCann Informational [Page 39] RFC 4413 TCP/IP Field Behavior March 2006

8. References

8.1. Normative References

 [1]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
       1981.
 [2]   Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
       September 1981.
 [3]   Nagle, J., "Congestion control in IP/TCP internetworks", RFC
       896, January 1984.
 [4]   Jacobson, V. and R. Braden, "TCP extensions for long-delay
       paths", RFC 1072, October 1988.
 [5]   Zweig, J. and C. Partridge, "TCP alternate checksum options",
       RFC 1146, March 1990.
 [6]   Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
       November 1990.
 [7]   Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for
       High Performance", RFC 1323, May 1992.
 [8]   Braden, B., "T/TCP -- TCP Extensions for Transactions
       Functional Specification", RFC 1644, July 1994.
 [9]   Connolly, T., Amer, P., and P. Conrad, "An Extension to TCP:
       Partial Order Service", RFC 1693, November 1994.
 [10]  Bellovin, S., "Defending Against Sequence Number Attacks", RFC
       1948, May 1996.
 [11]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for
       IP version 6", RFC 1981, August 1996.
 [12]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
       Selective Acknowledgment Options", RFC 2018, October 1996.
 [13]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
       Signature Option", RFC 2385, August 1998.
 [14]  Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
       the Differentiated Services Field (DS Field) in the IPv4 and
       IPv6 Headers", RFC 2474, December 1998.

West & McCann Informational [Page 40] RFC 4413 TCP/IP Field Behavior March 2006

 [15]  Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
       Congestion Notification (ECN) to IP", RFC 2481, January 1999.
 [16]  Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
       Control", RFC 2581, April 1999.
 [17]  Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
       Extension to the Selective Acknowledgement (SACK) Option for
       TCP", RFC 2883, July 2000.
 [18]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
       Explicit Congestion Notification (ECN) to IP", RFC 3168,
       September 2001.
 [19]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
       Congestion Notification (ECN)  Signaling with Nonces", RFC
       3540, June 2003.

8.2. Informative References

 [20]  IANA, "IANA", IANA TCP options, February 1998,
       <http://www.iana.org/assignments/tcp-parameters>.
 [21]  Braden, R., "Requirements for Internet Hosts - Communication
       Layers", STD 3, RFC 1122, October 1989.
 [22]  Jacobson, V., "Compressing TCP/IP headers for low-speed serial
       links", RFC 1144, February 1990.
 [23]  Almquist, P., "Type of Service in the Internet Protocol Suite",
       RFC 1349, July 1992.
 [24]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
       November 1998.
 [25]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
       Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
 [27]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
       (ESP)", RFC 2406, November 1998.
 [26]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
       Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
       2068, January 1997.
 [28]  Degermark, M., Nordgren, B., and S. Pink, "IP Header
       Compression", RFC 2507, February 1999.

West & McCann Informational [Page 41] RFC 4413 TCP/IP Field Behavior March 2006

 [29]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
       Low-Speed Serial Links", RFC 2508, February 1999.
 [30]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
       Values In the Internet Protocol and Related Headers", BCP 37,
       RFC 2780, March 2000.
 [31]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
       Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
       Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
       Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
       Framework and four profiles: RTP, UDP, ESP, and uncompressed",
       RFC 3095, July 2001.
 [32]  Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-
       end Performance Implications of Slow Links", BCP 48, RFC 3150,
       July 2001.
 [33]  Balakrishnan, Padmanabhan, V., Fairhurst, G., and M.
       Sooriyabandara, "TCP Performance Implications of Network Path
       Asymmetry", RFC 3449, December 2002.
 [34]  Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and F.
       Khafizov, "TCP over Second (2.5G) and Third (3G) Generation
       Wireless Networks", RFC 3481, February 2003.
 [35]  Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
       TCP", RFC 3522, April 2003.
 [36]  Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header
       Compression over PPP", RFC 3544, July 2003.
 [37]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R.,
       Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice
       for Internet Subnetwork Designers", BCP 89, RFC 3819, July
       2004.

West & McCann Informational [Page 42] RFC 4413 TCP/IP Field Behavior March 2006

Authors' Addresses

 Mark A. West
 Siemens/Roke Manor Research
 Roke Manor Research Ltd.
 Romsey, Hants  SO51 0ZN
 UK
 Phone: +44 (0)1794 833311
 EMail: mark.a.west@roke.co.uk
 URI:   http://www.roke.co.uk
 Stephen McCann
 Siemens/Roke Manor Research
 Roke Manor Research Ltd.
 Romsey, Hants  SO51 0ZN
 UK
 Phone: +44 (0)1794 833341
 EMail: stephen.mccann@roke.co.uk
 URI:   http://www.roke.co.uk

West & McCann Informational [Page 43] RFC 4413 TCP/IP Field Behavior March 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

West & McCann Informational [Page 44]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4413.txt · Last modified: 2006/03/09 18:48 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki