TOS issues with non RFC compliant TCP stacks


  We have learned of a problem with non RFC compliant users of
  the Internet.

  We believe this problem will be of interest to NANOG and tcp-impl
  WG participants.

  We would like to involve a larger body so that:

  - more people are aware of this issue

  - ISPs can more quickly handle potential problems when
    they arise

  - we can learn about additional IP stacks that have this problem

  - alternate opinions can be presented that may argue this
    behaviour is appropriate, and RFC compliant

  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.

  I assume there are other TCP implementations which also have
  this behaviour.

  This concerns us, as we would like to see IP transport utilize
  TOS markings for the growth of the Internet.

  In discussions with several vendors, colleagues, and review of
  RFCs, the following phrase seems most applicable, from Postel in
  RFC 793:

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

  Open Transport (an alternate, Apple supported stack) follows
  this principle and works well. Additionally, a patch is available
  on the net for MacTCP (see below).

  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.

  We can quite simply work around our customer's problem by setting
  TOS=0 on all traffic to/from the customer interface.

  However, any traffic towards nonFGC customer's [ie, from our
  interconnection partners] will not be modified. Therefore, they
  are also vulnerable to this problem.

  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.

  As it turns out, this is an archaically (sp) known problem, with
  a pre-existing patch.

  Information about this patch for MacTCP exists at:

  At this time we do not modify TCP TOS bits. Once we have more
  information we intend to move forward with the TOS modifications,
  after notifying our InterConnection partners and customers of
  potential impact.

  Thank you for your consideration.


Alan Hannan wrote:

  Certain versions of MacTCP send a RST when they receive SYN ACK
  packets of TOS!=0.

MacTCP is *old*, and has many more problems than this. Please tell your
help desks that if they run across users still using MacTCP, that they
advise them to upgrade to at least MacOS 7.5.3 (preferably 7.5.5), which
is free, and includes Open Transport. 68k macs are the most likely
candidates, as you would have to go through contortions to even make
MacTCP *work* on a PPC mac, although it can be done (for reasons passing understanding).

You actually do not need to upgrade the OS OT will install over 7.1 and up