On 29 Dec 2004, at 18:48, Tony Rall wrote:
On Wednesday, 2004-12-29 at 17:04 EST, Joe Abley <[EMAIL PROTECTED]> wrote:
Are there any common examples of the DF bit being set on non-TCP packets?
Common? It depends on what you're doing. To some people, the only common
application is 80/tcp.
Sure. However, path MTU discovery is a tweakable knob in the TCP stack on the server operating systems of my acquaintance. Turning it on (and it's on by default most of the time, as we know, hence this thread) on those platforms has no impact on any other protocols.
Remember that the DF bit is in the IP header - it can be on in any protocol. I know that AIX and my old RH Linux (at least) defaults to PMTUD enabled for tcp and udp. You can even see it in dns lookups.
I am not unappreciative of the layering violations involved. I am also happy to report that I have no recent experience of AIX or Red Hat Linux, though, and so my observations above may well be atypical. It'd be interesting to sample some representative traffic on some substantial peering link somewhere and see how many non-TCP-bearing, non-traceroute-looking datagrams have it set.
My reading of RFC 1191 suggests that the MSS tweak solution for TCP ought to be automatic on well-implemented clients attached to a sub-1500-byte MTU link. I guess the problem is either the number of residential gateways that people are using which shift the MTU-depressed link one hop away from the client, or a prevalence of poorly implemented 1191 in clients (or both).
It's tempting to look at the amount of residential DSL that continues to be sold and supported with sub-1500-byte MTUs and conclude that TCP must be all we have to worry about; however, for most of those users the only protocol on the Internet is probably 80/tcp, as you mentioned, and so their perceived happiness probably means nothing.
The better solution is to ensure that PMTUD works correctly for your network, and get on the case of any correspondent or provider for which it doesn't.
Making sure that pMTUd works in your own network doesn't solve the
problem. You need to make sure it works properly in every other network
with which you ever might want to exchange a 1500-byte packet.
I thought that's what I just said.
So you did. Sorry about that.
The "phone everybody in the world with a broken firewall" solution is better if you are viewing it from a context in which it is possible to execute in non-infinite time. For more general applications (e.g. those with customers) an MSS tweak on the client that avoids the broken bits of the remote-end firewalls from being exercised most of the time is probably a more practical route.
Joe
