TOS issues with non RFC compliant TCP stacks

Andrew R Frame aframe at
Wed Jun 9 17:39:55 UTC 1999

On Wed, 9 Jun 1999, Sean Donelan wrote:

> alan at globalcenter.NET (Alan Hannan) writes:
> >  We have learned of a problem with non RFC compliant users of
> >  the Internet.
> Although many network operators may want to apply RFC standards
> to non-compliant users; I think your problem is with protocol
> implementations instead of the users of those implementations :-)
> >  Certain versions of MacTCP send a RST when they receive SYN ACK
> >  packets of TOS!=0.
> >
> >  I assume there are other TCP implementations which also have
> >  this behaviour.
> MacTCP is pretty old.  But you're going to quickly discover a lot
> of other quirks in other old vendor's TOS handling.  I would hesitate
> to call some them non-RFC compliant, because sometimes the original
> RFCs left openings for different interpretations.  And the early
> 'reference' implementations had even more interpretations.  Later
> RFCs tried to clarify some of the practices, but it is an iterative
> process.  Because TOS is so rarely used (until now), I suspect there
> is still lots of buggy code which has never been tickled.
> Some IBM mainframes will RST a connection if the TOS changes after
> the SYN.  Several old implementations try to set to identical values
> in both directions, even though TOS is supposed to be independent
> between senders. And exactly how TOS interacts with MTU settings
> and fun stuff like fragmentation or path-MTU discovery is a mystery
> path through some stacks.

good call.

In newer versions of code the router sets the tos prec bits to 0C
(internetwork control) which will also break your mactcp and some
mainframe stacks. Specifically SPD (selective packet discard)

> >------------------------ = ------------------------
> >2.10.  Robustness Principle
> > 
> >  TCP implementations will follow a general principle of robustness:  be
> >  conservative in what you do, be liberal in what you accept from
> >  others.
> >------------------------ = ------------------------
> Like all great principles, it is a two-edged sword.  Please heed both
> parts.  Many implementors have justified their actions, on both sides,
> by saying it is too difficult for them to do, but trivial for the other
> guy to do.  If you believe in the robustness principle, it works best
> when both sides use it.
> >  Because of a hardware implementation limitation on most of
> >  routers, INbound TOS setting is efficient, while OUTbound TOS
> >  setting is inefficient.
> >
> >  So it is difficult for us to modify the TOS settings leaving
> >  our network.
> >
> >  It would be moderately trivial for most interconnection partners
> >  to modify the TOS settings on input.  This is a path we plan
> >  to pursue.
> With an end-to-end parameter, I think network operators are somewhat
> justified in telling the user: If it hurts don't set that parameter.
> But when the network operator sets/changes parameters in flight, I
> think it is up to that network operator to restore it/set-it-to-a-
> neutral-value when it hurts.  Saying the other guy must be liberal
> in what they accept only meets the robustness principle if you are
> conservative in what you send.
> If TOS is changing from an end-to-end parameter to a hop-by-hop
> parameter, it would be nice to have a simple way to clear it
> at a border router.  Do we need a "ip tos ignore/strip" interface
> command for the TOS field somewhat similar to the "ip security"
> interface configuration setting for IP options?  [naturally
> modified for other vendor configuration languages.]

See cisco bug id CSCdj36238

workaround to stop the router from setting the TOS bits:

pchacco(config)#ip telnet ?
  source-interface  Specify source interface
  tos               Specify type of service

pochacco(config)#ip telnet tos ?
  <0-FF>  TOS value
pochacco(config)#ip telnet tos 0

By default, TOS for telnet is 0xC0.


> Perhaps those providers with more pull with router vendors than me,
> and who are planning on using TOS for their internal network decisions,
> could encourage router vendors to add this feature.  It is unlikely
> every single end-system or intermediate network will do the right
> thing in every case with TOS, so a simple way to turn it off before
> it gets to the end-system would be a very useful addition to the
> network operator toolkit.  Trying to explain how to do packet surgery
> via complex router configurations over the phone to a customer is
> likely to result in as many ambiguities as the original RFCs.  Trying
> to explain it to an intermediate NSP/ISP; well you know how well
> inter-provider coordination works now.
> -- 
> Sean Donelan, Data Research Associates, Inc, St. Louis, MO
>   Affiliation given for identification not representation

More information about the NANOG mailing list