RFC Errata
Found 3 records.
Status: Held for Document Update (3)
RFC 1624, "Computation of the Internet Checksum via Incremental Update", May 1994
Source of RFC: LegacyArea Assignment: art
Errata ID: 4782
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ihsan Ulla Sharief
Date Reported: 2016-08-18
Held for Document Update by: Orie Steele
Date Held: 2024-05-03
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: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: J.A. Bezemer
Date Reported: 2019-09-25
Held for Document Update by: Orie Steele
Date Held: 2024-05-03
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: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: J.A. Bezemer
Date Reported: 2019-09-25
Held for Document Update by: Orie Steele
Date Held: 2024-05-03
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.