Section 5. Packet Formats

The DCCP header can be from 12 to 1020 bytes long.  The initial part
   of the header has the same semantics for all currently defined packet
   types.  Following this comes any additional fixed-length fields
   required by the packet type, and then a variable-length list of
   options.  The application data area follows the header.  In some
   packet types, this area contains data for the application; in other
   packet types, its contents are ignored.
      +---------------------------------------+  -.
      |            Generic Header             |   |
      +---------------------------------------+   |
      | Additional Fields (depending on type) |   +- DCCP Header
      +---------------------------------------+   |
      |          Options (optional)           |   |
      +=======================================+  -'
      |         Application Data Area         |
      +---------------------------------------+
5.1.  Generic Header
   The DCCP generic header takes different forms depending on the value
   of X, the Extended Sequence Numbers bit.  If X is one, the Sequence
   Number field is 48 bits long, and the generic header takes 16 bytes,
   as follows.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source Port          |           Dest Port           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Data Offset  | CCVal | CsCov |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     |       |X|               |                               .
      | Res | Type  |=|   Reserved    |  Sequence Number (high bits)  .
      |     |       |1|               |                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                  Sequence Number (low bits)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   If X is zero, only the low 24 bits of the Sequence Number are
   transmitted, and the generic header is 12 bytes long.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source Port          |           Dest Port           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Data Offset  | CCVal | CsCov |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     |       |X|                                               |
      | Res | Type  |=|          Sequence Number (low bits)           |
      |     |       |0|                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The generic header fields are defined as follows.
   Source and Destination Ports: 16 bits each
      These fields identify the connection, similar to the corresponding
      fields in TCP and UDP.  The Source Port represents the relevant
      port on the endpoint that sent this packet, and the Destination
      Port represents the relevant port on the other endpoint.  When
      initiating a connection, the client SHOULD choose its Source Port
      randomly to reduce the likelihood of attack.
      DCCP APIs should treat port numbers similarly to TCP and UDP port
      numbers.  For example, machines that distinguish between
      "privileged" and "unprivileged" ports for TCP and UDP should do
      the same for DCCP.
   Data Offset: 8 bits
      The offset from the start of the packet's DCCP header to the start
      of its application data area, in 32-bit words.  The receiver MUST
      ignore packets whose Data Offset is smaller than the minimum-sized
      header for the given Type or larger than the DCCP packet itself.
   CCVal: 4 bits
      Used by the HC-Sender CCID.  For example, the A-to-B CCID's
      sender, which is active at DCCP A, MAY send 4 bits of information
      per packet to its receiver by encoding that information in CCVal.
      The sender MUST set CCVal to zero unless its HC-Sender CCID
      specifies otherwise, and the receiver MUST ignore the CCVal field
      unless its HC-Receiver CCID specifies otherwise.
   Checksum Coverage (CsCov): 4 bits
      Checksum Coverage determines the parts of the packet that are
      covered by the Checksum field.  This always includes the DCCP
      header and options, but some or all of the application data may be
      excluded.  This can improve performance on noisy links for
      applications that can tolerate corruption.  See Section 9.
   Checksum: 16 bits
      The Internet checksum of the packet's DCCP header (including
      options), a network-layer pseudoheader, and, depending on Checksum
      Coverage, all, some, or none of the application data.  See Section
      9.
   Reserved (Res): 3 bits
      Senders MUST set this field to all zeroes on generated packets,
      and receivers MUST ignore its value.
   Type: 4 bits
      The Type field specifies the type of the packet.  The following
      values are defined:
                         Type   Meaning
                         ----   -------
                           0    DCCP-Request
                           1    DCCP-Response
                           2    DCCP-Data
                           3    DCCP-Ack
                           4    DCCP-DataAck
                           5    DCCP-CloseReq
                           6    DCCP-Close
                           7    DCCP-Reset
                           8    DCCP-Sync
                           9    DCCP-SyncAck
                         10-15  Reserved
                     Table 1: DCCP Packet Types
      Receivers MUST ignore any packets with reserved type.  That is,
      packets with reserved type MUST NOT be processed, and they MUST
      NOT be acknowledged as received.
   Extended Sequence Numbers (X): 1 bit
      Set to one to indicate the use of an extended generic header with
      48-bit Sequence and Acknowledgement Numbers.  DCCP-Data, DCCP-
      DataAck, and DCCP-Ack packets MAY set X to zero or one.  All
      DCCP-Request, DCCP-Response, DCCP-CloseReq, DCCP-Close, DCCP-
      Reset, DCCP-Sync, and DCCP-SyncAck packets MUST set X to one;
      endpoints MUST ignore any such packets with X set to zero.  High-
      rate connections SHOULD set X to one on all packets to gain
      increased protection against wrapped sequence numbers and attacks.
      See Section 7.6.
   Sequence Number: 48 or 24 bits
      Identifies the packet uniquely in the sequence of all packets the
      source sent on this connection.  Sequence Number increases by one
      with every packet sent, including packets such as DCCP-Ack that
      carry no application data.  See Section 7.
   All currently defined packet types except DCCP-Request and DCCP-Data
   carry an Acknowledgement Number Subheader in the four or eight bytes
   immediately following the generic header.  When X=1, its format is:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |    Acknowledgement Number     .
      |                               |          (high bits)          .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .               Acknowledgement Number (low bits)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   When X=0, only the low 24 bits of the Acknowledgement Number are
   transmitted, giving the Acknowledgement Number Subheader this format:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Reserved    |       Acknowledgement Number (low bits)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Reserved: 16 or 8 bits
      Senders MUST set this field to all zeroes on generated packets,
      and receivers MUST ignore its value.
   Acknowledgement Number: 48 or 24 bits
      Generally contains GSR, the Greatest Sequence Number Received on
      any acknowledgeable packet so far.  A packet is acknowledgeable
      if and only if its header was successfully processed by the
      receiver; Section 7.4 describes this further.  Options such as
      Ack Vector (Section 11.4) combine with the Acknowledgement
      Number to provide precise information about which packets have
      arrived.
      Acknowledgement Numbers on DCCP-Sync and DCCP-SyncAck packets
      need not equal GSR.  See Section 5.7.
5.2.  DCCP-Request Packets
   A client initiates a DCCP connection by sending a DCCP-Request
   packet.  These packets MAY contain application data and MUST use
   48-bit sequence numbers (X=1).
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /            Generic DCCP Header with X=1 (16 bytes)            /
      /                   with Type=0 (DCCP-Request)                  /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Service Code                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                      Options and Padding                      /
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      /                       Application Data                        /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Service Code: 32 bits
      Describes the application-level service to which the client
      application wants to connect.  Service Codes are intended to
      provide information about which application protocol a connection
      intends to use, thus aiding middleboxes and reducing reliance on
      globally well-known ports.  See Section 8.1.2.
5.3.  DCCP-Response Packets
   The server responds to valid DCCP-Request packets with DCCP-Response
   packets.  This is the second phase of the three-way handshake.
   DCCP-Response packets MAY contain application data and MUST use
   48-bit sequence numbers (X=1).
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /            Generic DCCP Header with X=1 (16 bytes)            /
      /                  with Type=1 (DCCP-Response)                  /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /          Acknowledgement Number Subheader (8 bytes)           /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Service Code                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                      Options and Padding                      /
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      /                       Application Data                        /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Acknowledgement Number: 48 bits
      Contains GSR.  Since DCCP-Responses are only sent during
      connection initiation, this will always equal the Sequence Number
      on a received DCCP-Request.
   Service Code: 32 bits
      MUST equal the Service Code on the corresponding DCCP-Request.
5.4.  DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets
   The central data transfer portion of every DCCP connection uses
   DCCP-Data, DCCP-Ack, and DCCP-DataAck packets.  These packets MAY use
   24-bit sequence numbers, depending on the value of the Allow Short
   Sequence Numbers feature (Section 7.6.1).  DCCP-Data packets carry
   application data without acknowledgements.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /              Generic DCCP Header (16 or 12 bytes)             /
      /                    with Type=2 (DCCP-Data)                    /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                      Options and Padding                      /
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      /                       Application Data                        /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   DCCP-Ack packets dispense with the data but contain an
   Acknowledgement Number.  They are used for pure acknowledgements.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /              Generic DCCP Header (16 or 12 bytes)             /
      /                    with Type=3 (DCCP-Ack)                     /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /        Acknowledgement Number Subheader (8 or 4 bytes)        /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                      Options and Padding                      /
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      /                Application Data Area (Ignored)                /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   DCCP-DataAck packets carry both application data and an
   Acknowledgement Number.  This piggybacks acknowledgement information
   on a data packet.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /              Generic DCCP Header (16 or 12 bytes)             /
      /                  with Type=4 (DCCP-DataAck)                   /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /        Acknowledgement Number Subheader (8 or 4 bytes)        /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                      Options and Padding                      /
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      /                       Application Data                        /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   A DCCP-Data or DCCP-DataAck packet may have a zero-length application
   data area, which indicates that the application sent a zero-length
   datagram.  This differs from DCCP-Request and DCCP-Response packets,
   where an empty application data area indicates the absence of
   application data (not the presence of zero-length application data).
   The API SHOULD report any received zero-length datagrams to the
   receiving application.
   A DCCP-Ack packet MAY have a non-zero-length application data area,
   which essentially pads the DCCP-Ack to a desired length.  Receivers
   MUST ignore the content of the application data area in DCCP-Ack
   packets.
   DCCP-Ack and DCCP-DataAck packets often include additional
   acknowledgement options, such as Ack Vector, as required by the
   congestion control mechanism in use.
5.5.  DCCP-CloseReq and DCCP-Close Packets
   DCCP-CloseReq and DCCP-Close packets begin the handshake that
   normally terminates a connection.  Either client or server may send a
   DCCP-Close packet, which will elicit a DCCP-Reset packet.  Only the
   server can send a DCCP-CloseReq packet, which indicates that the
   server wants to close the connection but does not want to hold its
   TIMEWAIT state.  Both packet types MUST use 48-bit sequence numbers
   (X=1).
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /            Generic DCCP Header with X=1 (16 bytes)            /
      /         with Type=5 (DCCP-CloseReq) or 6 (DCCP-Close)         /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /          Acknowledgement Number Subheader (8 bytes)           /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                      Options and Padding                      /
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      /                Application Data Area (Ignored)                /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   As with DCCP-Ack packets, DCCP-CloseReq and DCCP-Close packets MAY
   have non-zero-length application data areas, whose contents receivers
   MUST ignore.
5.6.  DCCP-Reset Packets
   DCCP-Reset packets unconditionally shut down a connection.
   Connections normally terminate with a DCCP-Reset, but resets may be
   sent for other reasons, including bad port numbers, bad option
   behavior, incorrect ECN Nonce Echoes, and so forth.  DCCP-Resets MUST
   use 48-bit sequence numbers (X=1).
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /            Generic DCCP Header with X=1 (16 bytes)            /
      /                   with Type=7 (DCCP-Reset)                    /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /          Acknowledgement Number Subheader (8 bytes)           /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Reset Code   |    Data 1     |    Data 2     |    Data 3     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                      Options and Padding                      /
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      /              Application Data Area (Error Text)               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Reset Code: 8 bits
      Represents the reason that the sender reset the DCCP connection.
   Data 1, Data 2, and Data 3: 8 bits each
      The Data fields provide additional information about why the
      sender reset the DCCP connection.  The meanings of these fields
      depend on the value of Reset Code.
   Application Data Area: Error Text
      If present, Error Text is a human-readable text string encoded in
      Unicode UTF-8, and preferably in English, that describes the error
      in more detail.  For example, a DCCP-Reset with Reset Code 11,
      "Aggression Penalty", might contain Error Text such as "Aggression
      Penalty: Received 3 bad ECN Nonce Echoes, assuming misbehavior".
   The following Reset Codes are currently defined.  Unless otherwise
   specified, the Data 1, 2, and 3 fields MUST be set to 0 by the sender
   of the DCCP-Reset and ignored by its receiver.  Section references
   describe concrete situations that will cause each Reset Code to be
   generated; they are not meant to be exhaustive.
   0, "Unspecified"
      Indicates the absence of a meaningful Reset Code.  Use of Reset
      Code 0 is NOT RECOMMENDED: the sender should choose a Reset Code
      that more clearly defines why the connection is being reset.
   1, "Closed"
      Normal connection close.  See Section 8.3.
   2, "Aborted"
      The sending endpoint gave up on the connection because of lack of
      progress.  See Sections 8.1.1 and 8.1.5.
   3, "No Connection"
      No connection exists.  See Section 8.3.1.
   4, "Packet Error"
      A valid packet arrived with unexpected type.  For example, a
      DCCP-Data packet with valid header checksum and sequence numbers
      arrived at a connection in the REQUEST state.  See Section 8.3.1.
      The Data 1 field equals the offending packet type as an eight-bit
      number; thus, an offending packet with Type 2 will result in a
      Data 1 value of 2.
   5, "Option Error"
      An option was erroneous, and the error was serious enough to
      warrant resetting the connection.  See Sections 6.6.7, 6.6.8, and
      11.4.  The Data 1 field equals the offending option type; Data 2
      and Data 3 equal the first two bytes of option data (or zero if
      the option had less than two bytes of data).
   6, "Mandatory Error"
      The sending endpoint could not process an option O that was
      immediately preceded by Mandatory.  The Data fields report the
      option type and data of option O, using the format of Reset Code
      5, "Option Error".  See Section 5.8.2.
   7, "Connection Refused"
      The Destination Port didn't correspond to a port open for
      listening.  Sent only in response to DCCP-Requests.  See Section
      8.1.3.
   8, "Bad Service Code"
      The Service Code didn't equal the service code attached to the
      Destination Port.  Sent only in response to DCCP-Requests.  See
      Section 8.1.3.
   9, "Too Busy"
      The server is too busy to accept new connections.  Sent only in
      response to DCCP-Requests.  See Section 8.1.3.
   10, "Bad Init Cookie"
      The Init Cookie echoed by the client was incorrect or missing.
      See Section 8.1.4.
   11, "Aggression Penalty"
      This endpoint has detected congestion control-related misbehavior
      on the part of the other endpoint.  See Section 12.3.
   12-127, Reserved
      Receivers should treat these codes as they do Reset Code 0,
      "Unspecified".
   128-255, CCID-specific codes
      Semantics depend on the connection's CCIDs.  See Section 10.3.
      Receivers should treat unknown CCID-specific Reset Codes as they
      do Reset Code 0, "Unspecified".
   The following table summarizes this information.
          Reset
          Code   Name                    Data 1     Data 2 & 3
          -----  ----                    ------     ----------
            0    Unspecified               0            0
            1    Closed                    0            0
            2    Aborted                   0            0
            3    No Connection             0            0
            4    Packet Error           pkt type        0
            5    Option Error           option #   option data
            6    Mandatory Error        option #   option data
            7    Connection Refused        0            0
            8    Bad Service Code          0            0
            9    Too Busy                  0            0
           10    Bad Init Cookie           0            0
           11    Aggression Penalty        0            0
          12-127 Reserved
         128-255 CCID-specific codes
                        Table 2: DCCP Reset Codes
   Options on DCCP-Reset packets are processed before the connection is
   shut down.  This means that certain combinations of options,
   particularly involving Mandatory, may cause an endpoint to respond to
   a valid DCCP-Reset with another DCCP-Reset.  This cannot lead to a
   reset storm; since the first endpoint has already reset the
   connection, the second DCCP-Reset will be ignored.
5.7.  DCCP-Sync and DCCP-SyncAck Packets
   DCCP-Sync packets help DCCP endpoints recover synchronization after
   bursts of loss and recover from half-open connections.  Each valid
   received DCCP-Sync immediately elicits a DCCP-SyncAck.  Both packet
   types MUST use 48-bit sequence numbers (X=1).
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /            Generic DCCP Header with X=1 (16 bytes)            /
      /          with Type=8 (DCCP-Sync) or 9 (DCCP-SyncAck)          /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /          Acknowledgement Number Subheader (8 bytes)           /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                      Options and Padding                      /
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      /                Application Data Area (Ignored)                /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The Acknowledgement Number field has special semantics for DCCP-Sync
   and DCCP-SyncAck packets.  First, the packet corresponding to a
   DCCP-Sync's Acknowledgement Number need not have been
   acknowledgeable.  Thus, receivers MUST NOT assume that a packet was
   processed simply because it appears in the Acknowledgement Number
   field of a DCCP-Sync packet.  This differs from all other packet
   types, where the Acknowledgement Number by definition corresponds to
   an acknowledgeable packet.  Second, the Acknowledgement Number on any
   DCCP-SyncAck packet MUST correspond to the Sequence Number on an
   acknowledgeable DCCP-Sync packet.  In the presence of reordering,
   this might not equal GSR.
   As with DCCP-Ack packets, DCCP-Sync and DCCP-SyncAck packets MAY have
   non-zero-length application data areas, whose contents receivers MUST
   ignore.  Padded DCCP-Sync packets may be useful when performing Path
   MTU discovery; see Section 14.
5.8.  Options
   Any DCCP packet may contain options, which occupy space at the end of
   the DCCP header.  Each option is a multiple of 8 bits in length.
   Individual options are not padded to multiples of 32 bits, and any
   option may begin on any byte boundary.  However, the combination of
   all options MUST add up to a multiple of 32 bits; Padding options
   MUST be added as necessary to fill out option space to a word
   boundary.  Any options present are included in the header checksum.
   The first byte of an option is the option type.  Options with types 0
   through 31 are single-byte options.  Other options are followed by a
   byte indicating the option's length.  This length value includes the
   two bytes of option-type and option-length as well as any option-data
   bytes; it must therefore be greater than or equal to two.
   Options MUST be processed sequentially, starting with the first
   option in the packet header.  Options with unknown types MUST be
   ignored.  Also, options with nonsensical lengths (length byte less
   than two or more than the remaining space in the options portion of
   the header) MUST be ignored, and any option space following an option
   with nonsensical length MUST likewise be ignored.  Unless otherwise
   specified, multiple occurrences of the same option MUST be processed
   independently; for some options, this will mean in practice that the
   last valid occurrence of an option takes precedence.
   The following options are currently defined:
               Option                           DCCP-  Section
       Type    Length     Meaning               Data?  Reference
       ----    ------     -------               -----  ---------
         0        1       Padding                 Y      5.8.1
         1        1       Mandatory               N      5.8.2
         2        1       Slow Receiver           Y      11.6
       3-31       1       Reserved
        32     variable   Change L                N      6.1
        33     variable   Confirm L               N      6.2
        34     variable   Change R                N      6.1
        35     variable   Confirm R               N      6.2
        36     variable   Init Cookie             N      8.1.4
        37       3-8      NDP Count               Y      7.7
        38     variable   Ack Vector [Nonce 0]    N      11.4
        39     variable   Ack Vector [Nonce 1]    N      11.4
        40     variable   Data Dropped            N      11.7
        41        6       Timestamp               Y      13.1
        42      6/8/10    Timestamp Echo          Y      13.3
        43       4/6      Elapsed Time            N      13.2
        44        6       Data Checksum           Y      9.3
       45-127  variable   Reserved
      128-255  variable   CCID-specific options   -      10.3
                        Table 3: DCCP Options
   Not all options are suitable for all packet types.  For example,
   since the Ack Vector option is interpreted relative to the
   Acknowledgement Number, it isn't suitable on DCCP-Request and DCCP-
   Data packets, which have no Acknowledgement Number.  If an option
   occurs on an unexpected packet type, it MUST generally be ignored;
   any such restrictions are mentioned in each option's description.
   The table summarizes the most common restriction: when the DCCP-
   Data? column value is N, the corresponding option MUST be ignored
   when received on a DCCP-Data packet.  (Section 7.5.5 describes why
   such options are ignored as opposed to, say, causing a reset.)
   Options with invalid values MUST be ignored unless otherwise
   specified.  For example, any Data Checksum option with option length
   4 MUST be ignored, since all valid Data Checksum options have option
   length 6.
   This section describes two generic options, Padding and Mandatory.
   Other options are described later.
5.8.1.  Padding Option
   +--------+
   |00000000|
   +--------+
     Type=0
   Padding is a single-byte "no-operation" option used to pad between or
   after options.  If the length of a packet's other options is not a
   multiple of 32 bits, then Padding options are REQUIRED to pad out the
   options area to the length implied by Data Offset.  Padding may also
   be used between options; for example, to align the beginning of a
   subsequent option on a 32-bit 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.
5.8.2.  Mandatory Option
   +--------+
   |00000001|
   +--------+
     Type=1
   Mandatory is a single-byte option that marks the immediately
   following option as mandatory.  Say that the immediately following
   option is O.  Then the Mandatory option has no effect if the
   receiving DCCP endpoint understands and processes O.  If the endpoint
   does not understand or process O, however, then it MUST reset the
   connection using Reset Code 6, "Mandatory Failure".  For instance,
   the endpoint would reset the connection if it did not understand O's
   type; if it understood O's type, but not O's data; if O's data was
   invalid for O's type; if O was a feature negotiation option, and the
   endpoint did not understand the enclosed feature number; or if the
   endpoint understood O, but chose not to perform the action O implies.
   This list is not exhaustive and, in particular, individual option
   specifications may describe additional situations in which the
   endpoint should reset the connection and situations in which it
   should not.
   Mandatory options MUST NOT be sent on DCCP-Data packets, and any
   Mandatory options received on DCCP-Data packets MUST be ignored.
   The connection is in error and should be reset with Reset Code 5,
   "Option Error", if option O is absent (Mandatory was the last byte of
   the option list), or if option O equals Mandatory.  However, the
   combination "Mandatory Padding" is valid, and MUST behave like two
   bytes of Padding.
   Section 6.6.9 describes the behavior of Mandatory feature negotiation
   options in more detail.