Re: TCP Checksum Interoperability

[Lloyd Wood <[e-mail]>]

On Fri, 5 Apr 2002, Rob Austein wrote:

> --------At Fri, 05 Apr 2002 12:05:33 -0800, Joe Touch wrote:
> >
> > See my other post on this, as per RFC1624 section 3, only one state
> > (0x0000) is legal as the complement of the checksum of non-zero data.
> > TCP checksummed data must contain at least one nonzero word (the one
> > with the TCP header length, which must be >=20).
>
> RFC 1624 is (a) Informational,

It was written before BCP came into being with RFC1818. More accurate
to say that it's not standards-track... I imagine any update
today would be BCP.

> and (b) wrong on this point.  RFC 793
> just says that it's a one's complement sum and does not dictate the
> specific method by which it must be calculated.
>
> The implementation is
> free to subtract zero from the sum at any point in the calculation to
> prevent overflow (even if the particular value of zero chosen would
> happen to look like a very large number when considered as an unsigned
> value).  An implementation whose native word size is larger than 16
> bits is also free to first perform the summation then fold the results
> down to 16 bits by applying mod 0xFFFF.
>
> And yes, once upon a time, people wrote checksum code that worked this
> way, at least on PDP-10s at MIT.
>
> The point is not that I'd advise anyone to use these techniques in new
> code, just that they're completely legal given what the standard
> actually says, and that the robustness principle therefore suggests
> that we should accept the checksums they generate.

and RFC791 claims ttl is in seconds, ergo I don't have to decrement
ttl because I know my traffic is on paths less than a second
long.

Cool reasoning.

L.

> > The receiver is entirely justified in considering 0xffff as an error.
>
> I disagree, for the reasons given above.

<[e-mail]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>