North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: followup on TCP stuff.
> Bill, > > Can you forward my reply here, and > tell Nanog'ers to check TCPIMPL for > more info? > > Thanks, > > Joe > > > > >To: [email protected], [email protected], [email protected] > > >Subject: Re: TOS issues with non RFC compliant TCP stacks > > >Cc: [email protected] > > > > > >> From [email protected] Tue Jun 8 23:27:07 1999 > > >> Date: Tue, 8 Jun 1999 22:45:11 -0700 > > >> From: Alan Hannan <[email protected]> > > >> To: [email protected], [email protected] > > >> Subject: TOS issues with non RFC compliant TCP stacks > > >... > > >> It has come to our attention that a notable fraction of the > > >> internet client community uses a TCP stack which is not RFC > > >> compliant, as far as we can determine. > > >> > > >> Certain versions of MacTCP send a RST when they receive SYN ACK > > >> packets of TOS!=0. > > > > > >Far as I have found, the spec (STD7) says that TOS is a TCP > > >per-connection property (page 12). > > > > > >On page 36 it appears to clearly state that (case 2): > > > > > > terminated then). If our SYN has been acknowledged (perhaps in this > > > incoming segment) the precedence level of the incoming segment must > > > match the local precedence level exactly, if it does not a reset > > > must be sent. > > > > > >> So, the empirical part: We implemented TOS bit-setting for the > > >> purpose of tracking traffic flows and traffic levels. For an > > >> entirely arbitrary reason, we chose TOS=5 for the default of > > >> traffic. We found that MacTCP ceased functioning. The MacTCP > > >> stack would initiate an RST when receiving SYN ACK packets with > > >> a TOS=5, as the SYN packets had a TOS=0. Therefore, all TCP > > >> sessions would fail. > > > > > >Granted, this is a first cut read, but wouldn't this appear > > >to indicate that NOT sending the RST is the violation of the > > >spec? > > > > > >Can you clarify? > > > > > >Joe > > > --bill
|