Discovering Path MTU black holes on the Internet using RIPE Atlas
Maikel De Boer, Jeff Bosma, Benno J. Overeinder, Willem Toorop · 2012
The Internet as we know it today is a complex system that works because of the many different protocols standardized by the Internet Engineering Task Force (IETF) defined in Request for Comments (RFC). If people intentionally or unintentionally do not comply with these standards problems are inevitable. Due to some network administrators that have configured their firewalls to filter Internet Control Message Protocol (ICMP) Packet Too Big (PTB) packets and Internet Protocol (IP) fragments and some Customerpremises equipment (CPE) devices which does this by default, several of the protocols on the Internet do not work as they are supposed to do. By filtering ICMP PTB packets and IP fragments, Path MTU (PMTU) black holes can occur. The effect of these particular black holes in a networked path is that packets, that are larger than the smallest link can assimilate, are forever lost because of the Maximum Transmission Unit (MTU) of this link. Such an event results in a situation where a typical end user thinks is caused by outage of their application, the remote service, or the connection in between. To determine the scale of the problem and where it occurs we have build an experimental setup and in our experiments use RIPE Atlas as a worldwide measurement. We have conducted several different experiments for nine periods of four hours using an average of between 1134 and 1365 Internet Protocol version 4 (IPV4) vantage points and an average of between 397 and 502 Internet Protocol version 6 (IPV6) vantage points. We observed that for IPV4 between 4% and 6% of the paths between the vantage points and our experimental setup filter ICMP PTB packets. For IPV6 this was between 0.77% and 1.07%. Furthermore, we found that when IPV4 Domain Name System (DNS) servers do not act on the receipt of ICMP PTB packets, between 11% and 14% of the answers from these DNS servers are lost. For IPV6 DNS servers this was between 40% and 42%. Lastly, we found that for IPV4 approximately 6% of the paths between the vantage points and our experimental setup filter IP fragments. For IPV6 this was approximately 10%. Both ICMP PTB packet and IP fragment filtering seems to be happening close to the end users and not in or near the core of the Internet. The amount of ICMP PTB packet filtering is larger in IPV4 than in IPV6, although it is not likely many users will notice any problems because of this. The results for IP fragment filtering in IPV6 are more troublesome since it is likely that protocols like Domain Name System Security Extensions (DNSSEC) are not going to work as smoothly on the Internet as it exists today. Luckily it looks like the problems do not occur in or near the core of the Internet. This means that there is a high probability that everyone would be able to fix their own networks if these are not configured correctly.