Subject: Re: TCP Checksum Interoperability

From: Joe Touch <[email-masked]>
Date: Fri, 05 Apr 2002 12:05:33 -0800

Rob Austein wrote:
> The last time this came up for a TCP implementation I used to
> maintain, our interpretation of Robustness Principle applied to this
> problem dictated that we shouldn't send segments with checksum fields
> set to all ones (that is, we shouldn't send ~(+0)), but that we had to
> accept either ~(+0) or ~(-0) in received segments.
> 
> Strictly speaking, either zero state is completely legal, 

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

The receiver is entirely justified in considering 0xffff as an error.

Jeo

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 05 Apr 2002 12:27:53 -0800

>The receiver is entirely justified in considering 0xffff as an error.

I agree. Both 0x0000 and 0xFFFF are distinct results from the checksum
calculation.

My guess is that this confusion radiates from UDP which allows not calculating
checksums. In the UDP case (and this case only), a calculated value of 0x0000
needs to be sent as something else, otherwise, the receiver wouldn't know if
the sender meant "no checksum sent" or "checksum sent is 0".

But this doesn't apply to TCP, where the checksum must always be calculated.

---

From: Rob Austein <[email-masked]>
Date: Fri, 05 Apr 2002 16:30:23 -0500

> with the TCP header length, which must be >=20).

RFC 1624 is (a) Informational, 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.

> The receiver is entirely justified in considering 0xffff as an error.

I disagree, for the reasons given above.

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 5 Apr 2002 23:13:47 +0100 (BST)

On Fri, 5 Apr 2002, Rob Austein wrote:

> 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
> specific method by which it must be calculated.
>
> The implementation is

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.

> I disagree, for the reasons given above.

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

---

From: Rob Austein <[email-masked]>
Date: Fri, 05 Apr 2002 17:56:13 -0500

> ttl because I know my traffic is on paths less than a second

Covered by RFCs 1122 and 1812.

---

From: Matt Crawford <[email-masked]>
Date: Fri, 05 Apr 2002 17:13:57 -0600

> ttl because I know my traffic is on paths less than a second

You lose -- 791 says you have to subtract at least 1 from TTL even if.

However, I think that (A) most or all extant IPv4 routers violate 791
if they happen hold a packet more than a second, and (B) IPv6
invalidated TCP's correctness by defining the Hop Limit field to be a
hop limit and have no connection to time.  A TCP riding on IPv6 may
receive old segments an unbounded time later without any other
network element breaking a spec.

I said so at the time, but nobody cared.  No doubt Vint will take
care of multi-second hops for us.

---

From: Alan Cox <[email-masked]>
Date: Sat, 6 Apr 2002 00:44:06 +0100 (BST)

> network element breaking a spec.

This was true with IPv4. A satellite link or a store and forward physical
layer can have multi-second timings anyway. Take RFC1149 for an obvious extreme
example. In the experimental study the packet dispatch time was a relatively low
proportion and the flight time is not visible to the router nor was the
large amount of flapping.

But we know TCP is broken. The late Ian Heavans wrote a nice draft on the 
subject.

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 6 Apr 2002 00:37:35 +0100 (BST)

> Covered by RFCs 1122 and 1812.

gee, 1812 isn't a standards document, and is updated by 2644, which
isn't a standards document either.

as for 1122, it's requirements for internet hosts, not requirements
for internet gateways... but matt points out,

$ You lose -- 791 says you have to subtract at least 1 from TTL even if.

damn. should have picked an option case instead.

L.

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 6 Apr 2002 00:45:07 +0100 (BST)

> But we know TCP is broken. The late Ian Heavans wrote a nice draft on the

you mean RFC2525? Not all his work got lost...

http://watersprings.org/cgi-bin/namazu.cgi?query=heavens&idxname=id

L.

---

From: der Mouse <[email-masked]>
Date: Fri, 5 Apr 2002 19:28:33 -0500 (EST)

>> A TCP riding on IPv6 may receive old segments an unbounded time
>> later without any other network element breaking a spec.
> This was true with IPv4.

No; the TTL is specified in seconds, with the additional note that it
must be decremented by at least one per hop even if the hop takes less
than a second.  Hops that take multiple seconds but decrement the TTL
by only one are out of spec for IPv4.

That's not to say that they're nonexistent, uncommon, or even that they
break stuff in practice.  Heck, I've seen ping show me RTTs upwards of
40 seconds, without even having to resort to avian carriers.  But they
_are_ spec violations.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: vint cerf <[email-masked]>
Date: Fri, 05 Apr 2002 19:47:57 -0500

:-)

---

From: Fred Baker <[email-masked]>
Date: Fri, 05 Apr 2002 17:17:48 -0800

At 03:13 PM 4/5/2002, Matt Crawford wrote:
>I think that (A) most or all extant IPv4 routers violate 791

for the record, while IPv4 TTL remains theoretically a time in seconds, it 
effectively became a hop count a long time ago. Thus sayeth RFC 1812:

5.3.1 Time to Live (TTL)

    The Time-to-Live (TTL) field of the IP header is defined to be a
    timer limiting the lifetime of a datagram.  It is an 8-bit field and
    the units are seconds.  Each router (or other module) that handles a
    packet MUST decrement the TTL by at least one, even if the elapsed
    time was much less than a second.  Since this is very often the case,
    the TTL is effectively a hop count limit on how far a datagram can
    propagate through the Internet.

    When a router forwards a packet, it MUST reduce the TTL by at least
    one.  If it holds a packet for more than one second, it MAY decrement
    the TTL by one for each second.

In that it "MAY" decrement the value, it also may choose not to...