> From: Joe Touch <touch(_at_)ISI(_dot_)EDU>
>> our interpretation of Robustness Principle applied to this problem
>> dictated that we .. had to accept either ~(+0) or ~(-0) in received
>> segments.
>> Strictly speaking, either zero state is completely legal,
> as per RFC1624 section 3, only one state (0x0000) is legal as the
> complement of the checksum of non-zero data. ...
> ..
> The receiver is entirely justified in considering 0xffff as an error.
I would tend to disagree strongly with this last line, and agree with the
original statement above.
The TCP (and IP) checksum is defined as "the one's complement of the
one's-complement sum of the packet contents" precisely to allow the following
behaviour: one adds up the incoming packet, *including the checksum as it
sits* (i.e. without having to zero out that field), and then checks to see
that the result is all 1's - which is, as you point out, the only valid zero
value that a one's-complement summation process *of a packet* can compute.
(The only way to get all 0's as a sum of a one's-complement addition
process is to to sum a series of zero's - which a real packet will never
contain.)
Note that if the packet's check sum (i.e. the sum with the checksum field set
to zero) happens to come out to zero (i.e. all one's, before the complement),
then *either* value of zero in the checksum field of the packet will result in
an all-1's sum when the packet is checksummed.
I honestly don't understand why anyone's code even bothers to look at the
actual value in the checksum field of the incoming packet; just do the
checksum of the whole packet, and look at the result.
Noel
PS: One does have to look at the incoming value for UDP, but that's different.