On Thu, 10 Oct 2002, Richard A Steenbergen wrote:
Even Windows 2000+ includes blackhole detection which will eventually remove the DF bit if packets aren't getting through and ICMP messages aren't coming back, something many unixes lack.
Wow, now I'm impressed. And what about the 1999 other versions of Windows? This is hardly a new problem. Still, it's good that some people at least make progress, even if very slowly.
But the heart of the problem is that people still push packets like every one must include the maximum data the MTU can support.
And why not?
Do we have any idea how much "network suffering" is being caused by that damn 1500 number right now? Aside from the fact that it is one of the worst numbers possible for the data, it throws a major monkey wrench in the use of tunnels, pppoe, etc.
So don't use those.
Eventually we will realize the way to go is something like "4096 data octets, plus some room for headers", on a 4470 MTU link.
So what then if someone runs a secure tunnel over wireless over a PPPoE over ADSL using mobile IPv6 that runs over a tunnel or two ad nauseum until the headers get bigger than 374 bytes? Then you'll have your problem right back. Might as well really solve it the first try. One of the problems is that there is no generally agreed on and widely available set of rules for this stuff. Setting the DF bit on all packets isn't good, but it works. Using RFC1918 space to number your tunnel routers isn't good, but it works. Filtering validating source addresses on ingress is good, but hey, it doesn't work! Making a good list of best practices (and then have people widely implement them) might also go a long way towards showing concerned parties such as the US administration that the network community consists of responsible people that can work together for the common good.
But if the best reason we can come up with is ISIS, the IEEE will just keep laughing.
Why is the IEEE laughing?