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