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
Date:Thu, 4 Apr 2002 09:50:01 -0800 (PST)
From:Gary E. Miller [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| Maybe it can, but that does not make it right.
|
| RFC 1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
|
| 2.3.1
If you actually go read
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
On Friday, April 5, 2002, at 08:42 AM, [EMAIL PROTECTED] wrote:
[I wrote:]
Also, I think it would be helpful to know how commonly twice-NAT is
deployed, but I don't have any data there.
I believe (at least) twice-NAT is fairly common. I have a NATting router
between by cable access
--On Friday, 05 April, 2002 22:53 +0700 Robert Elz
[EMAIL PROTECTED] wrote:
Date:Thu, 4 Apr 2002 09:50:01 -0800 (PST)
From:Gary E. Miller [EMAIL PROTECTED]
Message-ID:
[EMAIL PROTECTED]
| Maybe it can, but that does not make it right.
|
| RFC 1035
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
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
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,
On Friday, April 5, 2002, at 01:49 PM, Bill Strahm wrote:
[...] I believe AOL for one does this and it wouldn't surprise me if
most of the large cable providers do something silly like this at the
low end (You can always pay more for a real IP address)
I have also received several reports
* 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
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
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
On Thursday, April 4, 2002, at 05:53 PM, Keith Moore wrote:
[I wrote:]
[...]
I don't see how the presence of NA[P]T in a firewall substantially
alters these requirements.
[...]
but I think the IAB were trying to say that it's important to make
sure that measures used to circumvent NAT
On Friday, April 5, 2002, at 03:25 PM, james woodyatt wrote:
Another thing that springs to mind: the IAB should probably encourage--
in no uncertain terms-- that any UNSAF process specified for use with
IPv4 NAT should also be specified for use with RFC 2766 Network
Address Translation -
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
15 matches
Mail list logo
