Date: Thu, 16 Nov 2000 11:00:29 +0200 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: Charles Mott <cmott@scientech.com>, Archie Cobbs <archie@dellroad.org>, net@FreeBSD.ORG, Ari Suutari <ari@suutari.iki.fi>, jdp@FreeBSD.ORG Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001116110029.A38288@sunbay.com> In-Reply-To: <200011152043.eAFKhMG68318@whizzo.transsys.com>; from louie@TransSys.COM on Wed, Nov 15, 2000 at 03:43:22PM -0500 References: <Pine.BSF.4.21.0011130015100.50906-100000@carcassonne.scientech.com> <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> <200011151436.eAFEaHG65417@whizzo.transsys.com> <20001115172435.A9724@sunbay.com> <200011151548.eAFFmJG66031@whizzo.transsys.com> <20001115180842.A11913@sunbay.com> <200011152043.eAFKhMG68318@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 15, 2000 at 03:43:22PM -0500, Louis A. Mamakos wrote: > > > If the above would be true that would mean that almost all implementations > > of computing the checksum are wrong, i.e. they produce the value of 0x0000 > > as a checksum when it should actually be 0xffff. That would also mean all > > three RFCs: 1071, 1141 and 1624 are wrong. I can't believe that! > > But the thing is, both 0xffff and 0x0000 are the same value == 0. (One is > negative zero, other other a positive zero.) I think the authors make > an error when they conclude that the result of an addition can only be > a negative zero rather than a positive zero, but in the end it doesn't > really matter which representation of zero you use, because they are > arithmetically equal. > > I think the authors of those RFCs probably had 2's complement CPUs in > mind, and were thinking about commonly used emulations of 1's complement > arithemetic operations. > > > My understanding of the one's complement sum is as follows: > > > > This is the sum (or an algorithm to compute such a sum), which produces > > the RIGHT results for items represented in one's complement form, the form > > in which negative numbers are represented by one's complements of a > > positive number. > > > > You mentioned the books... Can you citate from one of these books that > > states that 0xFFFF + 0x0001 in one's complement arithmetic is 0x0000 > > rather than 0xFFFF? > > The correct result is 0x0001, since 0xffff is -0, and -0 + 1 == 1. > 0xFFFE + 0x0001 == 0, because 0xFFFE is -1 and -1 + 1 == 0. > Damn, of course I meant the (0xFFFE +' 0x0001) above. You said this will produce the value of 0x0000, while I think it should be 0xFFFF. Read this carefully, word by word: RFC768> If the computed checksum is zero, it is transmitted as all ones RFC768> (the equivalent in one's complement arithmetic). An all zero RFC768> transmitted checksum value means that the transmitter generated RFC768> no checksum. "If the computed checksum is zero" above means that CHECKSUM can be 0x0000, i.e. the one's complement SUM could have a value of 0xFFFF. And if this is the case, the CHECKSUM IS TRANSMITTED as all ones. This also means that the one's complement SUM (for IP purposes) can not have a value of 0x0000, because if there was such a case, then computed checksum value would be all ones by itself, and the UDP receiver would not be able to distinguish this "normal" case from the "no checksum" case above. So, to make a conclusion: 1. The ONE'S COMPLEMENT SUM CAN NEVER HAVE A VALUE OF ALL ZEROES, unless all words are zeroes, which is not the case for IP family protocols, because at least Protocol field is guaranteed to be non-zero, and is participating in all known checksums (e.g. IP, UDP, TCP, ICMP). Hereby, the CHECKSUM value, which is the one's complement of the sum, CAN NEVER HAVE A VALUE OF ALL ONES. 2. UDP uses all zero value in the checksum field to indicate that no checksum have been computed. For this to work, it does the following substituion. If the computed checksum is all zeroes (the could happen only if the one's complement sum is all ones), it is transmitted as all ones. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001116110029.A38288>