Section 7. Sequence Numbers

DCCP uses sequence numbers to arrange packets into sequence, to
   detect losses and network duplicates, and to protect against
   attackers, half-open connections, and the delivery of very old
   packets.  Every packet carries a Sequence Number; most packet types
   carry an Acknowledgement Number as well.
   DCCP sequence numbers are packet based.  That is, Sequence Numbers
   generated by each endpoint increase by one, modulo 2^48, per packet.
   Even DCCP-Ack and DCCP-Sync packets, and other packets that don't
   carry user data, increment the Sequence Number.  Since DCCP is an
   unreliable protocol, there are no true retransmissions, but effective
   retransmissions, such as retransmissions of DCCP-Request packets,
   also increment the Sequence Number.  This lets DCCP implementations
   detect network duplication, retransmissions, and acknowledgement
   loss; it is a significant departure from TCP practice.
7.1.  Variables
   DCCP endpoints maintain a set of sequence number variables for each
   connection.
   ISS     The Initial Sequence Number Sent by this endpoint.  This
           equals the Sequence Number of the first DCCP-Request or
           DCCP-Response sent.
   ISR     The Initial Sequence Number Received from the other endpoint.
           This equals the Sequence Number of the first DCCP-Request or
           DCCP-Response received.
   GSS     The Greatest Sequence Number Sent by this endpoint.  Here,
           and elsewhere, "greatest" is measured in circular sequence
           space.
   GSR     The Greatest Sequence Number Received from the other endpoint
           on an acknowledgeable packet.  (Section 7.4 defines this
           term.)
   GAR     The Greatest Acknowledgement Number Received from the other
           endpoint on an acknowledgeable packet that was not a DCCP-
           Sync.
   Some other variables are derived from these primitives.
   SWL and SWH
           (Sequence Number Window Low and High)  The extremes of the
           validity window for received packets' Sequence Numbers.
   AWL and AWH
           (Acknowledgement Number Window Low and High)  The extremes of
           the validity window for received packets' Acknowledgement
           Numbers.
7.2.  Initial Sequence Numbers
   The endpoints' initial sequence numbers are set by the first DCCP-
   Request and DCCP-Response packets sent.  Initial sequence numbers
   MUST be chosen to avoid two problems:
   o  delivery of old packets, where packets lingering in the network
      from an old connection are delivered to a new connection with the
      same addresses and port numbers; and
   o  sequence number attacks, where an attacker can guess the sequence
      numbers that a future connection would use [M85].
   These problems are the same as those faced by TCP, and DCCP
   implementations SHOULD use TCP's strategies to avoid them [RFC793,
   RFC1948].  The rest of this section explains these strategies in more
   detail.
   To address the first problem, an implementation MUST ensure that the
   initial sequence number for a given <source address, source port,
   destination address, destination port> 4-tuple doesn't overlap with
   recent sequence numbers on previous connections with the same
   4-tuple.  ("Recent" means sent within 2 maximum segment lifetimes, or
   4 minutes.)  The implementation MUST additionally ensure that the
   lower 24 bits of the initial sequence number don't overlap with the
   lower 24 bits of recent sequence numbers (unless the implementation
   plans to avoid short sequence numbers; see Section 7.6).  An
   implementation that has state for a recent connection with the same
   4-tuple can pick a good initial sequence number explicitly.
   Otherwise, it could tie initial sequence number selection to some
   clock, such as the 4-microsecond clock used by TCP [RFC793].  Two
   separate clocks may be required, one for the upper 24 bits and one
   for the lower 24 bits.
   To address the second problem, an implementation MUST provide each
   4-tuple with an independent initial sequence number space.  Then,
   opening a connection doesn't provide any information about initial
   sequence numbers on other connections to the same host.  [RFC1948]
   achieves this by adding a cryptographic hash of the 4-tuple and a
   secret to each initial sequence number.  For the secret, [RFC1948]
   recommends a combination of some truly random data [RFC4086], an
   administratively installed passphrase, the endpoint's IP address, and
   the endpoint's boot time, but truly random data is sufficient.  Care
   should be taken when the secret is changed; such a change alters all
   initial sequence number spaces, which might make an initial sequence
   number for some 4-tuple equal a recently sent sequence number for the
   same 4-tuple.  To avoid this problem, the endpoint might remember
   dead connection state for each 4-tuple or stay quiet for 2 maximum
   segment lifetimes around such a change.
7.3.  Quiet Time
   DCCP endpoints, like TCP endpoints, must take care before initiating
   connections when they boot.  In particular, they MUST NOT send
   packets whose sequence numbers are close to the sequence numbers of
   packets lingering in the network from before the boot.  The simplest
   way to enforce this rule is for DCCP endpoints to avoid sending any
   packets until one maximum segment lifetime (2 minutes) after boot.
   Other enforcement mechanisms include remembering recent sequence
   numbers across boots and reserving the upper 8 or so bits of initial
   sequence numbers for a persistent counter that decrements by two each
   boot.  (The latter mechanism would require disallowing packets with
   short sequence numbers; see Section 7.6.1.)
7.4.  Acknowledgement Numbers
   Cumulative acknowledgements are meaningless in an unreliable
   protocol.  Therefore, DCCP's Acknowledgement Number field has a
   different meaning from TCP's.
   A received packet is classified as acknowledgeable if and only if its
   header was successfully processed by the receiving DCCP.  In terms of
   the pseudocode in Section 8.5, a received packet becomes
   acknowledgeable when the receiving endpoint reaches Step 8.  This
   means, for example, that all acknowledgeable packets have valid
   header checksums and sequence numbers.  A sent packet's
   Acknowledgement Number MUST equal the sending endpoint's GSR, the
   Greatest Sequence Number Received on an acknowledgeable packet, for
   all packet types except DCCP-Sync and DCCP-SyncAck.
   "Acknowledgeable" does not refer to data processing.  Even
   acknowledgeable packets may have their application data dropped, due
   to receive buffer overflow or corruption, for instance.  Data Dropped
   options report these data losses when necessary, letting congestion
   control mechanisms distinguish between network losses and endpoint
   losses.  This issue is discussed further in Sections 11.4 and 11.7.
   DCCP-Sync and DCCP-SyncAck packets' Acknowledgement Numbers differ as
   follows: The Acknowledgement Number on a DCCP-Sync packet corresponds
   to a received packet, but not necessarily to an acknowledgeable
   packet; in particular, it might correspond to an out-of-sync packet
   whose options were not processed.  The Acknowledgement Number on a
   DCCP-SyncAck packet always corresponds to an acknowledgeable DCCP-
   Sync packet; it might be less than GSR in the presence of reordering.
7.5.  Validity and Synchronization
   Any DCCP endpoint might receive packets that are not actually part of
   the current connection.  For instance, the network might deliver an
   old packet, an attacker might attempt to hijack a connection, or the
   other endpoint might crash, causing a half-open connection.
   DCCP, like TCP, uses sequence number checks to detect these cases.
   Packets whose Sequence and/or Acknowledgement Numbers are out of
   range are called sequence-invalid and are not processed normally.
   Unlike TCP, DCCP requires a synchronization mechanism to recover from
   large bursts of loss.  One endpoint might send so many packets during
   a burst of loss that when one of its packets finally got through, the
   other endpoint would label its Sequence Number as invalid.  A
   handshake of DCCP-Sync and DCCP-SyncAck packets recovers from this
   case.
7.5.1.  Sequence and Acknowledgement Number Windows
   Each DCCP endpoint defines sequence validity windows that are subsets
   of the Sequence and Acknowledgement Number spaces.  These windows
   correspond to packets the endpoint expects to receive in the next few
   round-trip times.  The Sequence and Acknowledgement Number windows
   always contain GSR and GSS, respectively.  The window widths are
   controlled by Sequence Window features for the two half-connections.
   The Sequence Number validity window for packets from DCCP B is [SWL,
   SWH].  This window always contains GSR, the Greatest Sequence Number
   Received on a sequence-valid packet from DCCP B.  It is W packets
   wide, where W is the value of the Sequence Window/B feature.  One-
   fourth of the sequence window, rounded down, is less than or equal to
   GSR, and three-fourths is greater than GSR.  (This asymmetric
   placement assumes that bursts of loss are more common in the network
   than significant reorderings.)
     invalid  |       valid Sequence Numbers        |  invalid
   <---------*|*===========*=======================*|*--------->
         GSR -|GSR + 1 -   GSR                 GSR +|GSR + 1 +
    floor(W/4)|floor(W/4)                 ceil(3W/4)|ceil(3W/4)
               = SWL                           = SWH
   The Acknowledgement Number validity window for packets from DCCP B is
   [AWL, AWH].  The high end of the window, AWH, equals GSS, the
   Greatest Sequence Number Sent by DCCP A; the window is W' packets
   wide, where W' is the value of the Sequence Window/A feature.
     invalid  |    valid Acknowledgement Numbers    |  invalid
   <---------*|*===================================*|*--------->
      GSS - W'|GSS + 1 - W'                      GSS|GSS + 1
               = AWL                           = AWH
   SWL and AWL are initially adjusted so that they are not less than the
   initial Sequence Numbers received and sent, respectively:
         SWL := max(GSR + 1 - floor(W/4), ISR),
         AWL := max(GSS + 1 - W', ISS).
   These adjustments MUST be applied only at the beginning of the
   connection.  (Long-lived connections may wrap sequence numbers so
   that they appear to be less than ISR or ISS; the adjustments MUST NOT
   be applied in that case.)
7.5.2.  Sequence Window Feature
   The Sequence Window/A feature determines the width of the Sequence
   Number validity window used by DCCP B and the width of the
   Acknowledgement Number validity window used by DCCP A.  DCCP A sends
   a "Change L(Sequence Window, W)" option to notify DCCP B that the
   Sequence Window/A value is W.
   Sequence Window has feature number 3 and is non-negotiable.  It takes
   48-bit (6-byte) integer values, like DCCP sequence numbers.  Change
   and Confirm options for Sequence Window are therefore 9 bytes long.
   New connections start with Sequence Window 100 for both endpoints.
   The minimum valid Sequence Window value is Wmin = 32.  The maximum
   valid Sequence Window value is Wmax = 2^46 - 1 = 70368744177663.
   Change options suggesting Sequence Window values out of this range
   are invalid and MUST be handled accordingly.
   A proper Sequence Window/A value must reflect the number of packets
   DCCP A expects to be in flight.  Only DCCP A can anticipate this
   number.  Values that are too small increase the risk of the endpoints
   getting out sync after bursts of loss, and values that are much too
   small can prevent productive communication whether or not there is
   loss.  On the other hand, too-large values increase the risk of
   connection hijacking; Section 7.5.5 quantifies this risk.  One good
   guideline is for each endpoint to set Sequence Window to about five
   times the maximum number of packets it expects to send in a round-
   trip time.  Endpoints SHOULD send Change L(Sequence Window) options,
   as necessary, as the connection progresses.  Also, an endpoint MUST
   NOT persistently send more than its Sequence Window number of packets
   per round-trip time; that is, DCCP A MUST NOT persistently send more
   than Sequence Window/A packets per RTT.
7.5.3.  Sequence-Validity Rules
   Sequence-validity depends on the received packet's type.  This table
   shows the sequence and acknowledgement number checks applied to each
   packet; a packet is sequence-valid if it passes both tests, and
   sequence-invalid if it does not.  Many of the checks refer to the
   sequence and acknowledgement number validity windows [SWL, SWH] and
   [AWL, AWH] defined in Section 7.5.1.
                                             Acknowledgement Number
   Packet Type      Sequence Number Check    Check
   -----------      ---------------------    ----------------------
   DCCP-Request     SWL <= seqno <= SWH (*)  N/A
   DCCP-Response    SWL <= seqno <= SWH (*)  AWL <= ackno <= AWH
   DCCP-Data        SWL <= seqno <= SWH      N/A
   DCCP-Ack         SWL <= seqno <= SWH      AWL <= ackno <= AWH
   DCCP-DataAck     SWL <= seqno <= SWH      AWL <= ackno <= AWH
   DCCP-CloseReq    GSR <  seqno <= SWH      GAR <= ackno <= AWH
   DCCP-Close       GSR <  seqno <= SWH      GAR <= ackno <= AWH
   DCCP-Reset       GSR <  seqno <= SWH      GAR <= ackno <= AWH
   DCCP-Sync        SWL <= seqno             AWL <= ackno <= AWH
   DCCP-SyncAck     SWL <= seqno             AWL <= ackno <= AWH
   (*) Check not applied if connection is in LISTEN or REQUEST state.
   In general, packets are sequence-valid if their Sequence and
   Acknowledgement Numbers lie within the corresponding valid windows,
   [SWL, SWH] and [AWL, AWH].  The exceptions to this rule are as
   follows:
   o  Since DCCP-CloseReq, DCCP-Close, and DCCP-Reset packets end a
      connection, they cannot have Sequence Numbers less than or equal
      to GSR, or Acknowledgement Numbers less than GAR.
   o  DCCP-Sync and DCCP-SyncAck Sequence Numbers are not strongly
      checked.  These packet types exist specifically to get the
      endpoints back into sync; checking their Sequence Numbers would
      eliminate their usefulness.
   The lenient checks on DCCP-Sync and DCCP-SyncAck packets allow
   continued operation after unusual events, such as endpoint crashes
   and large bursts of loss, but there's no need for leniency in the
   absence of unusual events -- that is, during ongoing successful
   communication.  Therefore, DCCP implementations SHOULD use the
   following, more stringent checks for active connections, where a
   connection is considered active if it has received valid packets from
   the other endpoint within the last three round-trip times.
                                             Acknowledgement Number
   Packet Type      Sequence Number Check    Check
   -----------      ---------------------    ----------------------
   DCCP-Sync        SWL <= seqno <= SWH      AWL <= ackno <= AWH
   DCCP-SyncAck     SWL <= seqno <= SWH      AWL <= ackno <= AWH
   Finally, an endpoint MAY apply the following more stringent checks to
   DCCP-CloseReq, DCCP-Close, and DCCP-Reset packets, further lowering
   the probability of successful blind attacks using those packet types.
   Since these checks can cause extra synchronization overhead and delay
   connection closing when packets are lost, they should be considered
   experimental.
                                             Acknowledgement Number
   Packet Type      Sequence Number Check    Check
   -----------      ---------------------    ----------------------
   DCCP-CloseReq    seqno == GSR + 1         GAR <= ackno <= AWH
   DCCP-Close       seqno == GSR + 1         GAR <= ackno <= AWH
   DCCP-Reset       seqno == GSR + 1         GAR <= ackno <= AWH
   Note that sequence-validity is only one of the validity checks
   applied to received packets.
7.5.4.  Handling Sequence-Invalid Packets
   Endpoints respond to received sequence-invalid packets as follows.
   o  Any sequence-invalid DCCP-Sync or DCCP-SyncAck packet MUST be
      ignored.
   o  A sequence-invalid DCCP-Reset packet MUST elicit a DCCP-Sync
      packet in response (subject to a possible rate limit).  This
      response packet MUST use a new Sequence Number, and thus will
      increase GSS; GSR will not change, however, since the received
      packet was sequence-invalid.  The response packet's
      Acknowledgement Number MUST equal GSR.
   o  Any other sequence-invalid packet MUST elicit a similar DCCP-Sync
      packet, except that the response packet's Acknowledgement Number
      MUST equal the sequence-invalid packet's Sequence Number.
   On receiving a sequence-valid DCCP-Sync packet, the peer endpoint
   (say, DCCP B) MUST update its GSR variable and reply with a DCCP-
   SyncAck packet.  The DCCP-SyncAck packet's Acknowledgement Number
   will equal the DCCP-Sync's Sequence Number, which is not necessarily
   GSR.  Upon receiving this DCCP-SyncAck, which will be sequence-valid
   since it acknowledges the DCCP-Sync, DCCP A will update its GSR
   variable, and the endpoints will be back in sync.  As an exception,
   if the peer endpoint is in the REQUEST state, it MUST respond with a
   DCCP-Reset instead of a DCCP-SyncAck.  This serves to clean up DCCP
   A's half-open connection.
   To protect against denial-of-service attacks, DCCP implementations
   SHOULD impose a rate limit on DCCP-Syncs sent in response to
   sequence-invalid packets, such as not more than eight DCCP-Syncs per
   second.
   DCCP endpoints MUST NOT process sequence-invalid packets except,
   perhaps, by generating a DCCP-Sync.  For instance, options MUST NOT
   be processed.  An endpoint MAY temporarily preserve sequence-invalid
   packets in case they become valid later, however; this can reduce the
   impact of bursts of loss by delivering more packets to the
   application.  In particular, an endpoint MAY preserve sequence-
   invalid packets for up to 2 round-trip times.  If, within that time,
   the relevant sequence windows change so that the packets become
   sequence-valid, the endpoint MAY process them again.
   Note that sequence-invalid DCCP-Reset packets cause DCCP-Syncs to be
   generated.  This is because endpoints in an unsynchronized state
   (CLOSED, REQUEST, and LISTEN) might not have enough information to
   generate a proper DCCP-Reset on the first try.  For example, if a
   peer endpoint is in CLOSED state and receives a DCCP-Data packet, it
   cannot guess the right Sequence Number to use on the DCCP-Reset it
   generates (since the DCCP-Data packet has no Acknowledgement Number).
   The DCCP-Sync generated in response to this bad reset serves as a
   challenge, and contains enough information for the peer to generate a
   proper DCCP-Reset.  However, the new DCCP-Reset may carry a different
   Reset Code than the original DCCP-Reset; probably the new Reset Code
   will be 3, "No Connection".  The endpoint SHOULD use information from
   the original DCCP-Reset when possible.
7.5.5.  Sequence Number Attacks
   Sequence and Acknowledgement Numbers form DCCP's main line of defense
   against attackers.  An attacker that cannot guess sequence numbers
   cannot easily manipulate or hijack a DCCP connection, and
   requirements like careful initial sequence number choice eliminate
   the most serious attacks.
   An attacker might still send many packets with randomly chosen
   Sequence and Acknowledgement Numbers, however.  If one of those
   probes ends up sequence-valid, it may shut down the connection or
   otherwise cause problems.  The easiest such attacks to execute are as
   follows:
   o  Send DCCP-Data packets with random Sequence Numbers.  If one of
      these packets hits the valid sequence number window, the attack
      packet's application data may be inserted into the data stream.
   o  Send DCCP-Sync packets with random Sequence and Acknowledgement
      Numbers.  If one of these packets hits the valid acknowledgement
      number window, the receiver will shift its sequence number window
      accordingly, getting out of sync with the correct endpoint --
      perhaps permanently.
   The attacker has to guess both Source and Destination Ports for any
   of these attacks to succeed.  Additionally, the connection would have
   to be inactive for the DCCP-Sync attack to succeed, assuming the
   victim implemented the more stringent checks for active connections
   recommended in Section 7.5.3.
   To quantify the probability of success, let N be the number of attack
   packets the attacker is willing to send, W be the relevant sequence
   window width, and L be the length of sequence numbers (24 or 48).
   The attacker's best strategy is to space the attack packets evenly
   over sequence space.  Then the probability of hitting one sequence
   number window is P = WN/2^L.
   The success probability for a DCCP-Data attack using short sequence
   numbers thus equals P = WN/2^24.  For W = 100, then, the attacker
   must send more than 83,000 packets to achieve a 50% chance of
   success.  For reference, the easiest TCP attack -- sending a SYN with
   a random sequence number, which will cause a connection reset if it
   falls within the window -- with W = 8760 (a common default) and
   L = 32 requires more than 245,000 packets to achieve a 50% chance of
   success.
   A fast connection's W will generally be high, increasing the attack
   success probability for fixed N.  If this probability gets
   uncomfortably high with L = 24, the endpoint SHOULD prevent the use
   of short sequence numbers by manipulating the Allow Short Sequence
   Numbers feature (see Section 7.6.1).  The probability limit depends
   on the application, however.  Some applications, such as those
   already designed to handle corruption, are quite resilient to data
   injection attacks.
   The DCCP-Sync attack has L = 48, since DCCP-Sync packets use long
   sequence numbers exclusively; in addition, the success probability is
   halved, since only half the Sequence Number space is valid.  Attacks
   have a correspondingly smaller probability of success.  For a large W
   of 2000 packets, then, the attacker must send more than 10^11 packets
   to achieve a 50% chance of success.
   Attacks involving DCCP-Ack, DCCP-DataAck, DCCP-CloseReq, DCCP-Close,
   and DCCP-Reset packets are more difficult, since Sequence and
   Acknowledgement Numbers must both be guessed.  The probability of
   attack success for these packet types equals P = WXN/2^(2L), where W
   is the Sequence Number window, X is the Acknowledgement Number
   window, and N and L are as before.
   Since DCCP-Data attacks with short sequence numbers are relatively
   easy for attackers to execute, DCCP has been engineered to prevent
   these attacks from escalating to connection resets or other serious
   consequences.  In particular, any options whose processing might
   cause the connection to be reset are ignored when they appear on
   DCCP-Data packets.
7.5.6.  Sequence Number Handling Examples
   In the following example, DCCP A and DCCP B recover from a large
   burst of loss that runs DCCP A's sequence numbers out of DCCP B's
   appropriate sequence number window.
   DCCP A                                           DCCP B
   (GSS=1,GSR=10)                                   (GSS=10,GSR=1)
               -->   DCCP-Data(seq 2)     XXX
                         ...
               -->   DCCP-Data(seq 100)   XXX
               -->   DCCP-Data(seq 101)           -->  ???
                                                    seqno out of range;
                                                    send Sync
      OK       <--   DCCP-Sync(seq 11, ack 101)   <--
                                                    (GSS=11,GSR=1)
               -->   DCCP-SyncAck(seq 102, ack 11)   -->   OK
   (GSS=102,GSR=11)                                 (GSS=11,GSR=102)
   In the next example, a DCCP connection recovers from a simple blind
   attack.
   DCCP A                                           DCCP B
   (GSS=1,GSR=10)                                   (GSS=10,GSR=1)
                *ATTACKER*  -->  DCCP-Data(seq 10^6)  -->  ???
                                                    seqno out of range;
                                                    send Sync
      ???      <--   DCCP-Sync(seq 11, ack 10^6)  <--
   ackno out of range; ignore
   (GSS=1,GSR=10)                                   (GSS=11,GSR=1)
   The final example demonstrates recovery from a half-open connection.
   DCCP A                                           DCCP B
   (GSS=1,GSR=10)                                   (GSS=10,GSR=1)
   (Crash)
   CLOSED                                               OPEN
   REQUEST     -->   DCCP-Request(seq 400)        -->   ???
   !!          <--   DCCP-Sync(seq 11, ack 400)   <--   OPEN
   REQUEST     -->   DCCP-Reset(seq 401, ack 11)  -->   (Abort)
   REQUEST                                              CLOSED
   REQUEST     -->   DCCP-Request(seq 402)        -->   ...
7.6.  Short Sequence Numbers
   DCCP sequence numbers are 48 bits long.  This large sequence space
   protects DCCP connections against some blind attacks, such as the
   injection of DCCP-Resets into the connection.  However, DCCP-Data,
   DCCP-Ack, and DCCP-DataAck packets, which make up the body of any
   DCCP connection, may reduce header space by transmitting only the
   lower 24 bits of the relevant Sequence and Acknowledgement Numbers.
   The receiving endpoint will extend these numbers to 48 bits using the
   following pseudocode:
   procedure Extend_Sequence_Number(S, REF)
      /* S is a 24-bit sequence number from the packet header.
         REF is the relevant 48-bit reference sequence number:
         GSS if S is an Acknowledgement Number, and GSR if S is a
         Sequence Number. */
      Set REF_low := low 24 bits of REF
      Set REF_hi := high 24 bits of REF
      If REF_low (<) S           /* circular comparison mod 2^24 */
            and S |<| REF_low,   /* conventional, non-circular
                                    comparison */
         Return (((REF_hi + 1) mod 2^24) << 24) | S
      Otherwise, if S (<) REF_low and REF_low |<| S,
         Return (((REF_hi - 1) mod 2^24) << 24) | S
      Otherwise,
         Return (REF_hi << 24) | S
   The two different kinds of comparison in the if statements detect
   when the low-order bits of the sequence space have wrapped.  (The
   circular comparison "REF_low (<) S" returns true if and only if
   (S - REF_low), calculated using two's-complement arithmetic and then
   represented as an unsigned number, is less than or equal to 2^23
   (mod 2^24).)  When this happens, the high-order bits are incremented
   or decremented, as appropriate.
7.6.1.  Allow Short Sequence Numbers Feature
   Endpoints can require that all packets use long sequence numbers by
   leaving the Allow Short Sequence Numbers feature value at its default
   of zero.  This can reduce the risk that data will be inappropriately
   injected into the connection.  DCCP A sends a "Change L(Allow Short
   Seqnos, 1)" option to indicate its desire to send packets with short
   sequence numbers.
   Allow Short Sequence Numbers has feature number 2 and is server-
   priority.  It takes one-byte Boolean values.  When Allow Short
   Seqnos/B is zero, DCCP B MUST NOT send packets with short sequence
   numbers and DCCP A MUST ignore any packets with short sequence
   numbers that are received.  Values of two or more are reserved.  New
   connections start with Allow Short Sequence Numbers 0 for both
   endpoints.
7.6.2.  When to Avoid Short Sequence Numbers
   Short sequence numbers reduce the rate DCCP connections can safely
   achieve and increase the risks of certain kinds of attacks, including
   blind data injection.  Very-high-rate DCCP connections, and
   connections with large sequence windows (Section 7.5.2), SHOULD NOT
   use short sequence numbers on their data packets.  The attack risk
   issues have been discussed in Section 7.5.5; we discuss the rate
   limitation issue here.
   The sequence-validity mechanism assumes that the network does not
   deliver extremely old data.  In particular, it assumes that the
   network must have dropped any packet by the time the connection wraps
   around and uses its sequence number again.  This constraint limits
   the maximum connection rate that can be safely achieved.  Let MSL
   equal the maximum segment lifetime, P equal the average DCCP packet
   size in bits, and L equal the length of sequence numbers (24 or 48
   bits).  Then the maximum safe rate, in bits per second, is
   R = P*(2^L)/2MSL.
   For the default MSL of 2 minutes, 1500-byte DCCP packets, and short
   sequence numbers, the safe rate is therefore approximately 800 Mb/s.
   Although 2 minutes is a very large MSL for any networks that could
   sustain that rate with such small packets, long sequence numbers
   allow much higher rates under the same constraints: up to 14 petabits
   a second for 1500-byte packets and the default MSL.
7.7.  NDP Count and Detecting Application Loss
   DCCP's sequence numbers increment by one on every packet, including
   non-data packets (packets that don't carry application data).  This
   makes DCCP sequence numbers suitable for detecting any network loss,
   but not for detecting the loss of application data.  The NDP Count
   option reports the length of each burst of non-data packets.  This
   lets the receiving DCCP reliably determine when a burst of loss
   included application data.
   +--------+--------+-------- ... --------+
   |00100101| Length |      NDP Count      |
   +--------+--------+-------- ... --------+
    Type=37  Len=3-8       (1-6 bytes)
   If a DCCP endpoint's Send NDP Count feature is one (see below), then
   that endpoint MUST send an NDP Count option on every packet whose
   immediate predecessor was a non-data packet.  Non-data packets
   consist of DCCP packet types DCCP-Ack, DCCP-Close, DCCP-CloseReq,
   DCCP-Reset, DCCP-Sync, and DCCP-SyncAck.  The other packet types,
   namely DCCP-Request, DCCP-Response, DCCP-Data, and DCCP-DataAck, are
   considered data packets, although not all DCCP-Request and DCCP-
   Response packets will actually carry application data.
   The value stored in NDP Count equals the number of consecutive non-
   data packets in the run immediately previous to the current packet.
   Packets with no NDP Count option are considered to have NDP Count
   zero.
   The NDP Count option can carry one to six bytes of data.  The
   smallest option format that can hold the NDP Count SHOULD be used.
   With NDP Count, the receiver can reliably tell only whether a burst
   of loss contained at least one data packet.  For example, the
   receiver cannot always tell whether a burst of loss contained a non-
   data packet.
7.7.1.  NDP Count Usage Notes
   Say that K consecutive sequence numbers are missing in some burst of
   loss, and that the Send NDP Count feature is on.  Then some
   application data was lost within those sequence numbers unless the
   packet following the hole contains an NDP Count option whose value is
   greater than or equal to K.
   For example, say that an endpoint sent the following sequence of
   non-data packets (Nx) and data packets (Dx).
      N0  N1  D2  N3  D4  D5  N6  D7  D8  D9  D10 N11 N12 D13
   Those packets would have NDP Counts as follows.
      N0  N1  D2  N3  D4  D5  N6  D7  D8  D9  D10 N11 N12 D13
      -   1   2   -   1   -   -   1   -   -   -   -   1   2
   NDP Count is not useful for applications that include their own
   sequence numbers with their packet headers.
7.7.2.  Send NDP Count Feature
   The Send NDP Count feature lets DCCP endpoints negotiate whether they
   should send NDP Count options on their packets.  DCCP A sends a
   "Change R(Send NDP Count, 1)" option to ask DCCP B to send NDP Count
   options.
   Send NDP Count has feature number 7 and is server-priority.  It takes
   one-byte Boolean values.  DCCP B MUST send NDP Count options as
   described above when Send NDP Count/B is one, although it MAY send
   NDP Count options even when Send NDP Count/B is zero.  Values of two
   or more are reserved.  New connections start with Send NDP Count 0
   for both endpoints.