Date: Wed, 15 Nov 2000 18:08:42 +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> Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001115180842.A11913@sunbay.com> In-Reply-To: <200011151548.eAFFmJG66031@whizzo.transsys.com>; from louie@TransSys.COM on Wed, Nov 15, 2000 at 10:48:19AM -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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 15, 2000 at 10:48:19AM -0500, Louis A. Mamakos wrote: > > > If I compute the sum on IP PACKET, then sum can't be zero, so checksum can > > never be a 0xffff. This is all explained in RFC 1624, BTW :-) > > I can see you you would think this, given the errornous statement > from the RFC: > > In one's complement, there are two representations of zero: the all > zero and the all one bit values, often referred to as +0 and -0. > One's complement addition of non-zero inputs can produce -0 as a > result, but never +0. Since there is guaranteed to be at least one > non-zero field in the IP header, and the checksum field in the > protocol header is the complement of the sum, the checksum field can > never contain ~(+0), which is -0 (0xFFFF). It can, however, contain > ~(-0), which is +0 (0x0000). > > However, having actually used 1's complement-based ALU's, I can assure > you that one's complement addition of non-zero inputs certainlly can > produce +0 as the result. I have the core plane from that machine in > my office as proof :-) > 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! 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? -- 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?20001115180842.A11913>