IP Fragmentation - Not reliable over the Internet?

Benno Overeinder benno at NLnetLabs.nl
Thu Aug 29 08:24:16 UTC 2013


On 8/27/13 4:04 PM, Leo Bicknell wrote:
> I'm pretty sure the failure rate is higher, and here's why.
> 
> The #1 cause of fragments being dropped is firewalls.  Too many
> admins configuring a firewall do not understand fragments or how to
> properly put them in the rules.
> 
> Where do firewalls exist?  Typically protecting things with public
> IP space, that is (some) corporate networks and banks of content
> servers in data centers.  This also includes on-box firewalls for
> Internet servers, ipfw or iptables on the server is just as likely
> to be part of the problem.

In a study using the RIPE Atlas probes, we have used a heuristic to
figure out where the fragments where dropped.  And from the Atlas
probes where IP fragments did not arrive, there is a high likelihood
the problem is with the last hop to the Atlas probe.  All other
situations are with the router just before the last hop.  We did not
find any problems in the core.  Of course this was rather limited
study using the RIPE Atlas probes in a certain setting.

See for the full report "Discovering Path MTU Black Holes on the
Internet Using the RIPE Atlas",
http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf.

> Now, where are RIPE probes?  Most RIPE probes are probably either
> with somewhat clueful ISP operators, or at Internet Clueful
> engineer's personal connectivity (home, or perhaps a box in a
> colo).  RIPE probes have already significantly self-selected for
> people who like non-broken connectivity.  What's more, the ping
> test was probably to some "known good" host(s), rather than a broad
> selection of Internet hosts, so effectively it was only testing the
> probe end, not both ends.

With help from RIPE NCC (many thanks), we did measurements both ways.

Cheers,

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs.nl/



More information about the NANOG mailing list