[ih] UDP checksums (Was: UDP Length Field?)

[Joseph Touch]

> On Nov 29, 2020, at 1:15 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
>> From: Joseph Touch
> 
>> Either 0 or -0 could come up as a valid 1's complement sum over the
>> words
> 
> Perhaps I'm confused, but I don't see how you could get 0 (i.e. all 0 bits) as
> a 1's complement sum from anything except a 'packet' containing nothing but
> 0's,

Yes, but...

> i.e. no valid packet (and from that observation, _if correct_, the rest
> of my prior comment flows).

No valid IP or UDP, but that’s not the case necessarily everywhere the IP checksum is used. That’s what I was considering. 

> Here's my thinking about 'no 0 sum'; if I've
> somehow blown it, I would appreciate having my error pointed out! (Truly! :-)

The one’s complement is a ring, but as you note, 0 is a special case.

Only 0 + 0 -> 0

All other additions and subtractions yeid -n..n or -0 only (including, strictly, 0 - 0).

The only way you get back to 0 is multiplication (n * 0 = 0).

And the sum over the data + inverted checksum is always -0 (never 0).

The trick is that we don’t insert the complement of the ones complement sum. We insert that ONLY if the ones complement sum is not -0; if it is, we insert -0. However, those instructions are never given in RFC791, RFC1071; they appear only in RFC768:
If the computed  checksum  is zero,  it is transmitted  as all ones (the
equivalent  in one's complement  arithmetic).   An all zero  transmitted
checksum  value means that the transmitter  generated  no checksum  (for
debugging or for higher level protocols that don't care).

So - technically - the IP checksum CAN be 0 (when the ones complement sum is computed as -0, which can easily happen). That’s what I was thinking about.

Joe