TOS issues with non RFC compliant TCP stacks

Sean Donelan SEAN at SDG.DRA.COM
Wed Jun 9 09:40:31 UTC 1999

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.

>------------------------ = ------------------------
>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.]

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