Re: TCP Checksum Interoperability

[Ignacio Goyret <[e-mail]>]

At 12:05 PM 4/5/02 -0800, Joe Touch wrote:
>Rob Austein wrote:
>> The last time this came up for a TCP implementation I used to
>> maintain, our interpretation of Robustness Principle applied to this
>> problem dictated that we shouldn't send segments with checksum fields
>> set to all ones (that is, we shouldn't send ~(+0)), but that we had to
>> accept either ~(+0) or ~(-0) in received segments.
>> 
>> Strictly speaking, either zero state is completely legal, 
>
>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).
>
>The receiver is entirely justified in considering 0xffff as an error.

I agree. Both 0x0000 and 0xFFFF are distinct results from the checksum
calculation.

My guess is that this confusion radiates from UDP which allows not calculating
checksums. In the UDP case (and this case only), a calculated value of 0x0000
needs to be sent as something else, otherwise, the receiver wouldn't know if
the sender meant "no checksum sent" or "checksum sent is 0".

But this doesn't apply to TCP, where the checksum must always be calculated.