Date: Mon, 17 Jan 2000 11:39:14 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Charles Youse <cyouse@paradox.nexuslabs.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PR kern/15656 Message-ID: <200001171639.LAA18994@whizzo.transsys.com> In-Reply-To: Your message of "Mon, 17 Jan 2000 10:37:21 EST." <Pine.BSF.4.20.0001171035050.15159-100000@paradox.nexuslabs.com> References: <Pine.BSF.4.20.0001171035050.15159-100000@paradox.nexuslabs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> In this PR, regarding IP header checksums, it's stated that a checksum of
> 0 is specified by the standard to be transmitted as all-1s (0xFFFF). (A
> checksum of all 0s is taken to mean that the transmitting host did not
> calculate a checksum.)
>
> Can anyone find a reference to this in the official docs, or perhaps find
> an explanation why we do indeed send 0'ed checksums? I've replicated this
> behavior on both 3.4-STABLE and 4.0-CURRENT, i386 and alpha.
This behavior is certainly in RFC-791, which describes IP.
Note that since the checksum is computed using 1's complement
arithmetic, all-1's is a represetation of -0, which has the same
arithmetic properties as the encoding of +0. In this application, the
+0 encoding denotes "no checksump", which as far as I know, is only an
option for the UDP checksum.
An excerpt of RFC-791 says:
------------------------------------------------------------------------
Header Checksum: 16 bits
A checksum on the header only. Since some header fields change
(e.g., time to live), this is recomputed and verified at each point
that the internet header is processed.
The checksum algorithm is:
The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header. For purposes of
computing the checksum, the value of the checksum field is zero.
This is a simple to compute checksum and experimental evidence
indicates it is adequate, but it is provisional and may be replaced
by a CRC procedure, depending on further experience.
------------------------------------------------------------------------
So, if you implemented as it is described, computing a sum of the
packet contents who's result is 0x0000 would then be complemented to
0xFFFF for inclusion in the packet header.
A one's complement sum of values who's value is zero should always
produce a +0 (all zero bits) rather than a -0 (all one bits), At least
all right-thinking 1's complement hardware of the era (DEC, UNIVAC,
etc) worked that way.
louie
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001171639.LAA18994>