RFC 1624 (rfc1624) - Page 2 of 6


Computation of the Internet Checksum via Incremental Update



Alternative Format: Original Text Document



RFC 1624             Incremental Internet Checksum              May 1994


   from the one obtained from scratch (one's complement of one's
   complement sum of the original fields).

   For the sake of completeness, this memo briefly highlights key
   points from RFCs 1071 and 1141.  Based on these discussions,
   an updated procedure to incrementally compute the standard
   Internet checksum is developed and presented.

2.  Notation and Equations

   Given the following notation:

          HC  - old checksum in header
          C   - one's complement sum of old header
          HC' - new checksum in header
          C'  - one's complement sum of new header
          m   - old value of a 16-bit field
          m'  - new value of a 16-bit field

          RFC 1071 states that C' is:

          C' = C + (-m) + m'    --    [Eqn. 1]
             = C + (m' - m)

   As RFC 1141 points out, the equation above is not useful for direct
   use in incremental updates since C and C' do not refer to the actual
   checksum stored in the header.  In addition, it is pointed out that
   RFC 1071 did not specify that all arithmetic must be performed using
   one's complement arithmetic.

   Finally, complementing the above equation to get the actual checksum,
   RFC 1141 presents the following:

          HC' = ~(C + (-m) + m')
              = HC + (m - m')
              = HC + m + ~m'    --    [Eqn. 2]

3.  Discussion

   Although this equation appears to work, there are boundary conditions
   under which it produces a result which differs from the one obtained
   by checksum computation from scratch.  This is due to the way zero is
   handled in one's complement arithmetic.

   In one's complement, there are two representations of zero: the all
   zero and the all one bit values, often referred to as +0 and -0.
   One's complement addition of non-zero inputs can produce -0 as a
   result, but never +0.  Since there is guaranteed to be at least one



Rijsinghani