Section 9. Checksums

DCCP uses a header checksum to protect its header against corruption.
   Generally, this checksum also covers any application data.  DCCP
   applications can, however, request that the header checksum cover
   only part of the application data, or perhaps no application data at
   all.  Link layers may then reduce their protection on unprotected
   parts of DCCP packets.  For some noisy links, and for applications
   that can tolerate corruption, this can greatly improve delivery rates
   and perceived performance.
   Checksum coverage may eventually impact congestion control mechanisms
   as well.  A packet with corrupt application data and complete
   checksum coverage is treated as lost.  This incurs a heavy-duty loss
   response from the sender's congestion control mechanism, which can
   unfairly penalize connections on links with high background
   corruption.  The combination of reduced checksum coverage and Data
   Checksum options may let endpoints report packets as corrupt rather
   than dropped, using Data Dropped options and Drop Code 3 (see Section
   11.7).  This may eventually benefit applications.  However, further
   research is required to determine an appropriate response to
   corruption, which can sometimes correlate with congestion.  Corrupt
   packets currently incur a loss response.
   The Data Checksum option, which contains a strong CRC, lets endpoints
   detect application data corruption.  An API can then be used to avoid
   delivering corrupt data to the application, even if links deliver
   corrupt data to the endpoint due to reduced checksum coverage.
   However, the use of reduced checksum coverage for applications that
   demand correct data is currently considered experimental.  This is
   because the combined loss-plus-corruption rate for packets with
   reduced checksum coverage may be significantly higher than that for
   packets with full checksum coverage, although the loss rate will
   generally be lower.  Actual behavior will depend on link design;
   further research and experience is required.
   Reduced checksum coverage introduces some security considerations;
   see Section 18.1.  See Appendix B for further motivation and
   discussion.  DCCP's implementation of reduced checksum coverage was
   inspired by UDP-Lite [RFC3828].
9.1.  Header Checksum Field
   DCCP uses the TCP/IP checksum algorithm.  The Checksum field in the
   DCCP generic header (see Section 5.1) equals the 16-bit one's
   complement of the one's complement sum of all 16-bit words in the
   DCCP header, DCCP options, a pseudoheader taken from the network-
   layer header, and, depending on the value of the Checksum Coverage
   field, some or all of the application data.  When calculating the
   checksum, the Checksum field itself is treated as 0.  If a packet
   contains an odd number of header and payload bytes to be checksummed,
   8 zero bits are added on the right to form a 16-bit word for checksum
   purposes.  The pad byte is not transmitted as part of the packet.
   The pseudoheader is calculated as for TCP.  For IPv4, it is 96 bits
   long and consists of the IPv4 source and destination addresses, the
   IP protocol number for DCCP (padded on the left with 8 zero bits),
   and the DCCP length as a 16-bit quantity (the length of the DCCP
   header with options, plus the length of any data); see [RFC793],
   Section 3.1.  For IPv6, it is 320 bits long, and consists of the IPv6
   source and destination addresses, the DCCP length as a 32-bit
   quantity, and the IP protocol number for DCCP (padded on the left
   with 24 zero bits); see [RFC2460], Section 8.1.
   Packets with invalid header checksums MUST be ignored.  In
   particular, their options MUST NOT be processed.
9.2.  Header Checksum Coverage Field
   The Checksum Coverage field in the DCCP generic header (see Section
   5.1) specifies what parts of the packet are covered by the Checksum
   field, as follows:
   CsCov = 0      The Checksum field covers the DCCP header, DCCP
                  options, network-layer pseudoheader, and all
                  application data in the packet, possibly padded on the
                  right with zeros to an even number of bytes.
   CsCov = 1-15   The Checksum field covers the DCCP header, DCCP
                  options, network-layer pseudoheader, and the initial
                  (CsCov-1)*4 bytes of the packet's application data.
   Thus, if CsCov is 1, none of the application data is protected by the
   header checksum.  The value (CsCov-1)*4 MUST be less than or equal to
   the length of the application data.  Packets with invalid CsCov
   values MUST be ignored; in particular, their options MUST NOT be
   processed.  The meanings of values other than 0 and 1 should be
   considered experimental.
   Values other than 0 specify that corruption is acceptable in some or
   all of the DCCP packet's application data.  In fact, DCCP cannot even
   detect corruption in areas not covered by the header checksum, unless
   the Data Checksum option is used.  Applications should not make any
   assumptions about the correctness of received data not covered by the
   checksum and should, if necessary, introduce their own validity
   checks.
   A DCCP application interface should let sending applications suggest
   a value for CsCov for sent packets, defaulting to 0 (full coverage).
   The Minimum Checksum Coverage feature, described below, lets an
   endpoint refuse delivery of application data on packets with partial
   checksum coverage; by default, only fully covered application data is
   accepted.  Lower layers that support partial error detection MAY use
   the Checksum Coverage field as a hint of where errors do not need to
   be detected.  Lower layers MUST use a strong error detection
   mechanism to detect at least errors that occur in the sensitive part
   of the packet, and to discard damaged packets.  The sensitive part
   consists of the bytes between the first byte of the IP header and the
   last byte identified by Checksum Coverage.
   For more details on application and lower-layer interface issues
   relating to partial checksumming, see [RFC3828].
9.2.1.  Minimum Checksum Coverage Feature
   The Minimum Checksum Coverage feature lets a DCCP endpoint determine
   whether its peer is willing to accept packets with reduced Checksum
   Coverage.  For example, DCCP A sends a "Change R(Minimum Checksum
   Coverage, 1)" option to DCCP B to check whether B is willing to
   accept packets with Checksum Coverage set to 1.
   Minimum Checksum Coverage has feature number 8 and is server-
   priority.  It takes one-byte integer values between 0 and 15; values
   of 16 or more are reserved.  Minimum Checksum Coverage/B reflects
   values of Checksum Coverage that DCCP B finds unacceptable.  Say that
   the value of Minimum Checksum Coverage/B is MinCsCov.  Then:
   o  If MinCsCov = 0, then DCCP B only finds packets with CsCov = 0
      acceptable.
   o  If MinCsCov > 0, then DCCP B additionally finds packets with
      CsCov >= MinCsCov acceptable.
   DCCP B MAY refuse to process application data from packets with
   unacceptable Checksum Coverage.  Such packets SHOULD be reported
   using Data Dropped options (Section 11.7) with Drop Code 0, Protocol
   Constraints.  New connections start with Minimum Checksum Coverage 0
   for both endpoints.
9.3.  Data Checksum Option
   The Data Checksum option holds a 32-bit CRC-32c cyclic redundancy-
   check code of a DCCP packet's application data.
   +--------+--------+--------+--------+--------+--------+
   |00101100|00000110|              CRC-32c              |
   +--------+--------+--------+--------+--------+--------+
    Type=44  Length=6
   The sending DCCP computes the CRC of the bytes comprising the
   application data area and stores it in the option data.  The CRC-32c
   algorithm used for Data Checksum is the same as that used for SCTP
   [RFC3309]; note that the CRC-32c of zero bytes of data equals zero.
   The DCCP header checksum will cover the Data Checksum option, so the
   data checksum must be computed before the header checksum.
   A DCCP endpoint receiving a packet with a Data Checksum option either
   MUST or MAY check the Data Checksum; the choice depends on the value
   of the Check Data Checksum feature described below.  If it checks the
   checksum, it computes the received application data's CRC-32c using
   the same algorithm as the sender and compares the result with the
   Data Checksum value.  If the CRCs differ, the endpoint reacts in one
   of two ways:
   o  The receiving application may have requested delivery of known-
      corrupt data via some optional API.  In this case, the packet's
      data MUST be delivered to the application, with a note that it is
      known to be corrupt.  Furthermore, the receiving endpoint MUST
      report the packet as delivered corrupt using a Data Dropped option
      (Drop Code 7, Delivered Corrupt).
   o  Otherwise, the receiving endpoint MUST drop the application data
      and report that data as dropped due to corruption using a Data
      Dropped option (Drop Code 3, Corrupt).
   In either case, the packet is considered acknowledgeable (since its
   header was processed) and will therefore be acknowledged using the
   equivalent of Ack Vector's Received or Received ECN Marked states.
   Although Data Checksum is intended for packets containing application
   data, it may be included on other packets, such as DCCP-Ack, DCCP-
   Sync, and DCCP-SyncAck.  The receiver SHOULD calculate the
   application data area's CRC-32c on such packets, just as it does for
   DCCP-Data and similar packets.  If the CRCs differ, the packets
   similarly MUST be reported using Data Dropped options (Drop Code 3),
   although their application data areas would not be delivered to the
   application in any case.
9.3.1.  Check Data Checksum Feature
   The Check Data Checksum feature lets a DCCP endpoint determine
   whether its peer will definitely check Data Checksum options.  DCCP A
   sends a Mandatory "Change R(Check Data Checksum, 1)" option to DCCP B
   to require it to check Data Checksum options (the connection will be
   reset if it cannot).
   Check Data Checksum has feature number 9 and is server-priority.  It
   takes one-byte Boolean values.  DCCP B MUST check any received Data
   Checksum options when Check Data Checksum/B is one, although it MAY
   check them even when Check Data Checksum/B is zero.  Values of two or
   more are reserved.  New connections start with Check Data Checksum 0
   for both endpoints.
9.3.2.  Checksum Usage Notes
   Internet links must normally apply strong integrity checks to the
   packets they transmit [RFC3828, RFC3819].  This is the default case
   when the DCCP header's Checksum Coverage value equals zero (full
   coverage).  However, the DCCP Checksum Coverage value might not be
   zero.  By setting partial Checksum Coverage, the application
   indicates that it can tolerate corruption in the unprotected part of
   the application data.  Recognizing this, link layers may reduce error
   detection and/or correction strength when transmitting this
   unprotected part.  This, in turn, can significantly increase the
   likelihood of the endpoint's receiving corrupt data; Data Checksum
   lets the receiver detect that corruption with very high probability.