This page is no longer being maintained
Sites With Broken Path MTU Discovery
Sites running servers should either permit packet fragmentation
or use path MTU discovery (PMTUD) to
handle packets too large for a given path. PMTUD is the default
for almost all modern systems, but a surprising number of sites have
broken PMTUD. This prevents a growing number of users from
communicating with the sites' servers.
Some sites have multiple servers, with PMTUD working for some but not
others. In some cases it's the site's secure transaction server
for which PMTUD does not work. While it's certainly reasonable
to shelter such servers more than others, it is not reasonable to
continue attempting PMTUD when the PMTUD return ICMPs are
blocked. When the return ICMPs are blocked, PMTUD should be
turned off and fragmentation enabled. The fragmentation is of
packets outbound from the server and poses no risk to the server.
Below is a list of servers found trying and failing to do PMTUD,
meaning they ask for ICMP notification when fragmentation is need and
then either ignore or refuse to accept the notifications. These
are only the servers that have come to our attention, and this list is
by no means complete.
If your server is listed but the problem has been fixed, send email to
have your server removed from our list.
- firstusa.com - secure server but not main site
- nationsbank.com - secure server but not main site
Sites With Working Path MTU Discovery
Because most sites have working PMTUD, finding sites for this list is
easy. This is only a small sampling of some significant sites.
- yahoo.com main site and finance.yahoo.com site
Sites Choosing Fragmentation
A few sites allow their packets to be fragmented rather than using PMTUD.
(cnn.com uses PMTUD for some of their other servers referenced by
their main servers. This PMTUD works.)
- cnn.com main servers (noted by Martijn Lievaart)
Site With an Alternative Path MTU Approach
One site uses its own approach to the Path MTU problem.
The microsoft.com servers begin by sending full-size packets with the
DF bit set, as if they were doing path MTU discovery, but any return
"fragmentation needed" ICMPs are either blocked or ignored.
Instead, if after several retries no acks of the full-size packets are
received, the servers switch to sending small (524-byte) packets
without the DF bit set.
This works, but we have to wonder what is the point of setting the DF
bit on the initial full-size packets. Overall, this procedure
introduces a delay of about 10 seconds in the download, compared to no
delay for simply turning off the DF bit and delays typically around
one or two tenths of a second for PMTUD.
This behavior appears to be a custom modification for Microsoft's own
use. We haven't seen any of Microsoft's customers' servers do