RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Reported (3)

RFC 1624, "Computation of the Internet Checksum via Incremental Update", May 1994

Source of RFC: Legacy
Area Assignment: art

Errata ID: 4782
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ihsan Ulla Sharief
Date Reported: 2016-08-18

Section 3 says:

   The problem is avoided by not assuming this property.  The correct
   equation is given below:

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

It should say:

   The problem is avoided by not assuming this property.  The correct
   equation is given below:

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

Notes:

The RFC is for computing incremental checksum and ensuring the computed checksum does not result in 0xFFFF (representing -0). However, when in cases where the original value (m) has not changed, and original header checksum (HC) is 0, it will change the fianl checksum value to 0xFFFF (against the intent of this RFC).

Example:
m = 0x5555
~m = 0xAAAA
m' = 0x5555
Checksum (HC) = 0x0000
Checksum compliment (~HC) = 0xFFFF
incremental checksum = ~(~HC + ~m + m') ~(0xFFFF + 0xAAAA + 0x5555) = ~(0x0000) = 0xFFFF

Solution:
Need to explicitly mention that the incremental checksum computation should be done only when there is change in value (ie, m != m').

Errata ID: 5864
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: J.A. Bezemer
Date Reported: 2019-09-25

Section 3 says:

(end of section 3 Discussion)

It should say:

(Add text at end of section 3 Discussion:)

Where "+" denotes 1's complement addition, in which carry bits are added
to the low-order bits of the sum. For machines employing e.g. 32-bit
arithmetic, the 1's complement addition of three 16-bit words A and B
and C is accomplished as follows:

        sum = A + B + C
        while (sum > 0xFFFF) {
            sum = (sum & 0xFFFF) + (sum >> 16)
        }

Notes:

The existing Errata ID: 4782 does not appear to correctly implement 1's complement addition.

Its example should read as follows:

~(~HC + ~m + m')
~(~0x0000 + ~0x5555 + 0x5555)
~(0xFFFF + 0xAAAA + 0x5555)
~(0x1FFFE) -- 32bit
~(0xFFFE + 0x1) -- carry foldaround
~(0xFFFF)
0x0000

A different example showing multiple carry foldaround is replacing a 0x5555 value by 0x5556 where the original header checksum was 0x0000:

~(~HC + ~m + m')
~(~0x0000 + ~0x5555 + 0x5556)
~(0xFFFF + 0xAAAA + 0x5556)
~(0x1FFFF) -- 32bit
~(0xFFFF + 0x1) -- carry foldaround
~(0x10000) -- 32bit
~(0x0000 + 0x1) -- carry foldaround
~(0x0001)
0xFFFE

Errata ID: 5865
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: J.A. Bezemer
Date Reported: 2019-09-25

Section 3 says:

(end of section 3 Discussion)

It should say:

(Add text after end of section 3 Discussion:)

3.1 Considerations for larger-bitsize machines

In above equations, "+" denotes 1's complement addition, in which any
high-order carry bits are added to the low-order bits of the sum, when
executed in 16-bit arithmetic.

When implementing on machines with larger bitsize words, the 1's complement
addition can be accomplished by explicity folding back the carry bits.
For this to work, all negation operations must be limited to the relevant
16 bits only, for example by means of exclusive-or by 0xFFFF. The following
routine can be used:

        HCnew = (HCorig xor 0xFFFF) + (valueorig xor 0xFFFF) + valuenew
        while (HCnew > 0xFFFF) {
                HCnew = (HCnew & 0xFFFF) + (HCnew >> 16)
        }
        HCnew = (HCnew xor 0xFFFF)

where valueorig and valuenew contain the original and new 16-bit (aligned)
payload values, and HCorig and HCnew are the 16-bit header checksum values,
all as least-significant 16 bits inside a larger-bitsize word using
corresponding arithmetic. As long as the bitsize is large enough that the
summations do not overflow, no negative values will be generated and any
binary arithmetic can be used.

Notes:

This updates the previous Errata ID: 5864 by including details on the bit-limited negation, which was probably a(nother) cause of the failing result in Errata ID: 4782.

Report New Errata



Advanced Search