--------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.