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 support@netheaven.com to have your server removed from our list.

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.

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.)

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 this.