FYI, The 'offending' stacks are PC/TCP (reception) and in Open VMS
(transmission).
This is an age-old issue; the following dates from 1985(!):
http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8502.mm.www/0389.html
I think RFC 1624 is missing the UDP case, where +0 means "not calculated".
Indeed, RFC 768 asserts that the two values (+0 and -0) are equivalent.
Part of the problem is that there isn't an RFC standard that deals with the
issue of a zero checksum, apart from for UDP.
The protocol RFCs don't specify the details and the implementation RFCs
(1071, 1141, 1624) state explicitly that they are not standards, "It is not
a standard, but a set of useful implementation techniques".
They are a very good idea but not mandatory.
That's why I said I thought the receiver wasn't compliant: it rejects -0 as
invalid.
Chris
-----Original Message-----
From: Lloyd Wood [mailto:l(_dot_)wood(_at_)eim(_dot_)surrey(_dot_)ac(_dot_)uk]
Sent: 05 April 2002 21:45
To: Michael Smith
Cc: 'CTrobridge(_at_)baltimore(_dot_)com'; 'sra+ietf(_at_)hactrn(_dot_)net';
'ietf(_at_)IETF(_dot_)ORG';
'tcp-impl(_at_)grc(_dot_)nasa(_dot_)gov'
Subject: RE: TCP Checksum Interoperability
On Fri, 5 Apr 2002, Michael Smith 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
Not so. Please read RFC1624 sections 3-5.
L.
<L(_dot_)Wood(_at_)surrey(_dot_)ac(_dot_)uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com