--------At Fri, 05 Apr 2002 12:05:33 -0800, Joe Touch wrote:
See my other post on this, as per RFC1624 section 3, only one state
(0x0000) is legal as the complement of the checksum of non-zero data.
TCP checksummed data must contain at least one nonzero word (the one
with the TCP header length, which must be >=20).
RFC 1624 is (a) Informational, and (b) wrong on this point. RFC 793
just says that it's a one's complement sum and does not dictate the
specific method by which it must be calculated. The implementation is
free to subtract zero from the sum at any point in the calculation to
prevent overflow (even if the particular value of zero chosen would
happen to look like a very large number when considered as an unsigned
value). An implementation whose native word size is larger than 16
bits is also free to first perform the summation then fold the results
down to 16 bits by applying mod 0xFFFF.
And yes, once upon a time, people wrote checksum code that worked this
way, at least on PDP-10s at MIT.
The point is not that I'd advise anyone to use these techniques in new
code, just that they're completely legal given what the standard
actually says, and that the robustness principle therefore suggests
that we should accept the checksums they generate.
The receiver is entirely justified in considering 0xffff as an error.
I disagree, for the reasons given above.