> The reasons that the IP options used in RFC 1323 cause problems are generally
> twofold:
> 
> - Some boxes have "less than optimal" IP implementations, and just can't
>   deal with them.  For example, some older Annexes would crash upon getting
>   packets with IP options set.

If we have demonstrable cases of current or widespread implementations
that crash or otherwise misbehave in the presence of timestamps, we
should at least investigate as to whether this condition can be
detected and worked around. Have demonstrable cases and packet traces
would be nice.

> - IP options interact badly with some versions of PPP when VJ header
>   compression is enabled.  For example, Telebit Netblazers will eat packets
>   that have IP options set if you use PPP and VJ header compression.

I was aware that in some cases RFC1323 destroyed the optimality
of VJ compression; I was not aware that it caused Netblazers to
_eat_ packets. Is this demonstable and reproducible? Do we have
packet traces of what happens? Has someone yelled at Telebit?

> I would try two things:
> 
> - Turn off VJ header compression on the PPP connection
> - Turn off rfc1323 via sysctl.

The reverse order is probably preferrable. While dialup PPP links
may be "long", they are very rarely "fat", and as such RFC1323
should be rarely necessary. VJ "compression", on the other hand, is
quite often useful.

--jhawk
  John Hawkinson