# IP Checksum calculation question - TCP-IP

This is a discussion on IP Checksum calculation question - TCP-IP ; In the following URL http://www.netfor2.com/checksum.html The author cites the following for using one's complement "Probably the most important is that it is endian independent. Little Endian computers store hex numbers with the LSB last (Intel processors for example). Big Endian ...

# Thread: IP Checksum calculation question

1. ## IP Checksum calculation question

In the following URL

http://www.netfor2.com/checksum.html

The author cites the following for using one's complement

"Probably the most important is that it is endian independent. Little
Endian computers store hex numbers with the LSB last (Intel processors
for example). Big Endian computers put the LSB first (IBM mainframes
for example). When carry is added to the LSB to form the 1's
complement sum (see the example) it doesn't matter if we add 03 + 01
or 01 + 03. The result is the same."

How woud this be different if someone would use two's complement? I
don't see how a person could get different results.

2. ## Re: IP Checksum calculation question

On Apr 13, 1:29*pm, grocery_stocker wrote:
> In the following URL
>
> http://www.netfor2.com/checksum.html
>
> The author cites the following for using one's complement
>
> "Probably the most important is that it is endian independent. Little
> Endian computers store hex numbers with the LSB last (Intel processors
> for example). Big Endian computers put the LSB first (IBM mainframes
> for example). When carry is added to the LSB to form the 1's
> complement sum (see the example) it doesn't matter if we add 03 + 01
> or 01 + 03. The result is the same."
>
> How woud this be different if someone would use two's complement? I
> don't see how a person could get different results.

You have to read that in the context of RFC 1072, which explains IP
checksums.

As all other discussions about endianness, the word length matters. In
this case, the IP checksum is computed assuming that bytes of the
packets are paired up, to form 16-bit words.

Now normally, if you added up numbers represented as 16-bit words, you
would definitely expect the byte order of those words (numbers) to
matter, right? Just in general, you would not expect that adding up
two 16-bit values such as

AB + CD,

where AB and CD each represent a particular 16-bit number, would be

BA + DC. Swapping bytes changes the numerical value of the 16-bit word
in potentially huge ways.

And yet, if you use the one's complement sum, the result IS the same,
as long as you use the same byte order in the computed 16-bit sum as
you assumed for each 16-bit word.

Bert

3. ## Re: IP Checksum calculation question

On Apr 13, 4:46*pm, Albert Manfredi wrote:
> On Apr 13, 1:29*pm, grocery_stocker wrote:
>
> > In the following URL

>
> >http://www.netfor2.com/checksum.html

>
> > The author cites the following for using one's complement

>
> > "Probably the most important is that it is endian independent. Little
> > Endian computers store hex numbers with the LSB last (Intel processors
> > for example). Big Endian computers put the LSB first (IBM mainframes
> > for example). When carry is added to the LSB to form the 1's
> > complement sum (see the example) it doesn't matter if we add 03 + 01
> > or 01 + 03. The result is the same."

>
> > How woud this be different if someone would use two's complement? I
> > don't see how a person could get different results.

>
> You have to read that in the context of RFC 1072, which explains IP
> checksums.
>
> As all other discussions about endianness, the word length matters. In
> this case, the IP checksum is computed assuming that bytes of the
> packets are paired up, to form 16-bit words.
>
> Now normally, if you added up numbers represented as 16-bit words, you
> would definitely expect the byte order of those words (numbers) to
> matter, right? Just in general, you would not expect that adding up
> two 16-bit values such as
>
> AB + CD,
>
> where AB and CD each represent a particular 16-bit number, would be
> the same as adding up
>
> BA + DC. Swapping bytes changes the numerical value of the 16-bit word
> in potentially huge ways.
>
> And yet, if you use the one's complement sum, the result IS the same,
> as long as you use the same byte order in the computed 16-bit sum as
> you assumed for each 16-bit word.
>
> Bert

I think I see this. When AB + CD got swapped, I was under the
impression that it was CD + AB, not BA + DC.

4. ## Re: IP Checksum calculation question

On Apr 13, 10:07*pm, grocery_stocker wrote:

> I think I see this. When AB + CD got swapped, I was under the
> impression that it was CD + AB, not BA + DC.

That's not changing the byte order in the 16-bit words. You've swapped
words without changing the byte ordering.

The scheme also works for any word length that's a multiple of 16
bits. So for example, if the machine uses 32-bit numbers, then ABCD +
DEFG could be byte-swapped to DCBA + GFED, and the result would be the
same. Or swapping the order of each two-byte component of each 32-bit
word, such as BADC + EDGF.

Bert

5. ## Re: IP Checksum calculation question

On Sun, 13 Apr 2008 10:29:10 -0700 (PDT), grocery_stocker wrote:
> In the following URL
>
> http://www.netfor2.com/checksum.html
>
> The author cites the following for using one's complement
>
> "Probably the most important is that it is endian independent. Little
> Endian computers store hex numbers with the LSB last (Intel processors

^^^^^^^^^^^
I distrust any text which uses the term "hex number" in this context.
Hexadecimal has nothing to do with it -- they might as well have
written "binary number", "octal number" or "decimal number".

/Jorgen

--
// Jorgen Grahn \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!