RE: TCP Checksum Interoperability

2002-04-08 Thread Chris Trobridge
PROTECTED]] Sent: 05 April 2002 21:45 To: Michael Smith Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: TCP Checksum Interoperability On Fri, 5 Apr 2002, Michael Smith wrote: The last time this came up for a TCP implementation I used

TCP Checksum Interoperability

2002-04-05 Thread Chris Trobridge
I writing to this list because the TCP workgroup was shutdown a while ago. We have a compatibility problem between two third party implementations of the TCP checksum. The problem concerns the representation of zero, whichhas two 1-s complement representations ( and ). We

Re: TCP Checksum Interoperability

2002-04-05 Thread Rob Austein
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

Re: TCP Checksum Interoperability

2002-04-05 Thread Joe Touch
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

RE: TCP Checksum Interoperability

2002-04-05 Thread Michael Smith
Title: RE: TCP Checksum Interoperability I'm cross-posting this thread to [EMAIL PROTECTED] for archival purposes, we'll see if any further replies to the ietf list get posted at [EMAIL PROTECTED] too (for instructions to join tcp-impl, see below). My rationale here is just to try and keep

Re: TCP Checksum Interoperability

2002-04-05 Thread J. Noel Chiappa
From: Joe Touch [EMAIL PROTECTED] our interpretation of Robustness Principle applied to this problem dictated that we .. had to accept either ~(+0) or ~(-0) in received segments. Strictly speaking, either zero state is completely legal, as per RFC1624 section 3,

Re: TCP Checksum Interoperability

2002-04-05 Thread Bob Braden
* From [EMAIL PROTECTED] Fri Apr 5 11:50:30 2002 * X-Authentication-Warning: ietf.org: majordom set sender to [EMAIL PROTECTED] using -f * Date: Fri, 05 Apr 2002 14:29:44 -0500 * From: Rob Austein [EMAIL PROTECTED] * To: [EMAIL PROTECTED] * Subject: Re: TCP Checksum

Re: TCP Checksum Interoperability

2002-04-05 Thread Matt Crawford
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. 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

Re: TCP Checksum Interoperability

2002-04-05 Thread Fred Baker
At 03:13 PM 4/5/2002, Matt Crawford wrote: 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

Re: TCP Checksum Interoperability

2002-04-05 Thread Rob Austein
At Fri, 5 Apr 2002 22:37:24 GMT, Bob Braden wrote: 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