Subject: Re: TCP Checksum Interoperability

From: Bob Braden <[email-masked]>
Date: Fri, 5 Apr 2002 22:37:24 GMT

*> From [email-masked]  Fri Apr  5 11:50:30 2002
  *> X-Authentication-Warning: ietf.org: majordom set sender to [email-masked] using -f
  *> Date: Fri, 05 Apr 2002 14:29:44 -0500
  *> From: Rob Austein <[email-masked]>
  *> To: [email-masked]
  *> Subject: Re: TCP Checksum Interoperability
  *> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN)
  *> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
  *> X-Loop: [email-masked]
  *> X-AntiVirus: scanned by AMaViS 0.2.1
  *> 
  *> 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, but one is
  *> (apparently) more surprising to most implementors than the other, due
  *> to the implementation techniques that suggest themselves on most
  *> modern processors.
  *> 

We thought we had laid these issues to rest in 1988, in RFC 1071.

Bob Braden

---

From: Rob Austein <[email-masked]>
Date: Sat, 06 Apr 2002 02:03:34 -0500

> We thought we had laid these issues to rest in 1988, in RFC 1071.

I think you came close.  I disagree with one minor point in RFC 1071,
but code based on RFC 1071 would have the behavior that I think is
correct: it wouldn't generate TCP segments with 0xFFFF in the checksum
field, but it would accept such segments if it received them.