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. <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>