Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!decwrl!ucbvax!su-pescadero.arpa!mann From: mann@SU-PESCADERO.ARPA (Tim Mann) Newsgroups: mod.protocols.tcp-ip Subject: Re: IP, ICMP, TCP, and UDP checksumming. Message-ID: <8510240212.AA27126@UCB-VAX> Date: Wed, 23-Oct-85 21:39:00 EDT Article-I.D.: UCB-VAX.8510240212.AA27126 Posted: Wed Oct 23 21:39:00 1985 Date-Received: Thu, 24-Oct-85 11:34:25 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@ucb-vax.arpa The problem with your analysis is that it depends on a particular way of doing ones-complement arithmetic on a non-ones-complement machine. (Unsigned addition followed by end-around carry, with no normalization step.) If I have a true ones-complement machine, it would be perfectly legitimate for it to automatically normalize ~0 to +0 after every addition, in which case the property "you can never get 0 in a sum unless both addends are 0" does not hold. Also, treating ~0 and +0 as different makes it much more confusing to analyze the arithmetic, since if they are treated as identical, we have modulo (2^n) - 1 arithmetic, whose properties are well-known, but if they are treated as different, the system is not even a group. Nonetheless, I think your analysis is correct. The upshot is that IF you are checking a checksum on a twos-complement machine and doing end-around carry in software, you will never get ~0 after complementing if the checksum is correct. HOWEVER, you will not be robust, since another implementation may put +0 in the checksum field when it meant ~0, in a packet with zeroes in all other fields, in which case you WILL get ~0. (This is the only case in which you will get ~0.) This problem is a common one since it isn't absolutely clear to people who read the IP spec that "the ones complement of the ones-complement sum..." can never be +0. In fact, if one uses the above checksum-checking code to generate checksums as well, it is easy to make that mistake. This is a problem we actually ran into at Stanford a while back. In short, avoid headaches by normalizing. --Tim