Subject: RE: keep RST data nonstandardized for the future!

From: Bernie Volz <[email-masked]>
Date: Thu, 3 Aug 2000 10:09:01 -0400

However, there is one case where there is no ability to send the RST reason
code if we use this negotiation approach ... and that is when the TCP stack
receiving a packet has NO knowledge of the connection (such as if it has
just rebooted and connections were active when it crashed).

So, we might need to consider an exception in this case ... if a TCP
receives a packet for a connection it has no knowledge of, it MAY send a RST
reason code (in the "TCP Instrumentation Option").

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Bernie Volz [mailto:[email-masked]]
Sent: Thursday, August 03, 2000 9:38 AM
To: 'Eric A. Hall'
Cc: Ian Heavens; Jerry Toporek; [email-masked];
[email-masked]
Subject: RE: keep RST data nonstandardized for the future!

Eric:

You are wrong about that. Think about it.

If a SYN is RECEIVED with the option to enable this feature, then the RST
from the SYN can be set back with the option (since you know the sender of
the SYN is capable of supporting the option).

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Eric A. Hall [mailto:[email-masked]]
Sent: Wednesday, August 02, 2000 3:14 PM
To: Bernie Volz
Cc: Ian Heavens; Jerry Toporek; [email-masked];
[email-masked]
Subject: Re: keep RST data nonstandardized for the future!

> Likely, an option would be sent in a SYN to advertise the ability to
> support the instrumentation option. Lack of a reply with a similar
> option in the SYN/ACK would mean that the peer does not support the
> option and hence it would not be used. (This is similar to how other
> options, such as SACK, work.)

In the case of RST being issued in response to the SYN request, there
would be no successful negotiation.

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

---

From: Rick Jones <[email-masked]>
Date: Thu, 03 Aug 2000 10:33:56 -0700

I should probably do a bit more math and message/RFC re-reading before I
ask this but:

Do we have enough space left on the head of the pin for this angel to
dance upon along with the MSS, SACK, timestamp and window scale?

We want folks to negotiate an MSS; asking for SACK is the
current-big-thing (tm); and timestamps and window-scale are effectively
"required options" for anything that wants to run much above (if not at)
100 Mbit/s (to avoid sequence wrap within MSL). Or so it seems.

rick jones
-- 
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post, but please do NOT do BOTH...
my email address is raj in the cup.hp.com domain...

---

From: Craig Partridge <[email-masked]>
Date: Thu, 03 Aug 2000 15:02:26 -0400

Good question -- indeed, I've been wondering if some of these essentially
binary options could be reduced to a bit field -- offer the ones you
support, get a bitmap of the ones supported.

Craig

---

From: Greg Minshall <[email-masked]>
Date: Thu, 03 Aug 2000 16:33:56 -0700

historically, the reason for doing these SYN-attached options was because 
certain buggy TCP implementations (including my old TCP for the Mac) would die 
if they received unknown options anywhere *except* during SYN-time.

one could have an option (i've thought that one should have an option) that 
says "can you receive random options without core dumping your kernel?".  if 
*that* was negotiated, then you could just send the RST option thing, and the 
receiver would either drop it (if it was not understood) or "do the right 
thing" with it.

(whether we have room even for *this* i'm not sure, but if i were going to do 
anything, i'd do this.)

cheers,  Greg