Howdy.
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
others.
------------------------ = ------------------------
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:
http://www.mactcp.org.nz/mactcp.html
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