|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: TOS issues with non RFC compliant TCP stacks
[email protected] (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
|