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 ...

+ Reply to Thread
Results 1 to 5 of 5

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
    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

  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!

+ Reply to Thread