IPv6 fragmentation weirdness
oberman at es.net
Thu May 14 21:42:38 UTC 2009
I have recently noticed problems with data transfers via IPv6. Attempt
to fetch files from dome sites was hanging as soon as the data started
to flow. Felt like an MTU issue, so I tried sending various sizes of
ICMP echo (ping) packets and discovered that I could not send a packet
of over 1280 bytes. (ping6 -s 1232) If I disabled kernel fragmentation
(-m), I could use packets up to the MTU of my interface (1500 bytes).
The path is entirely native IPv6. No tunnels. All should allow full 1500
I then captured the ICMP and discovered that the kernel was fragmenting
all of them! Worse, the fragment was sent out before the ICMP! What the
heck is going on! Thread synchronization?
When I captured the packets (via tcpdump -s0 -w file host ftp.funet.fi), the
first things captured is an IPv6 fragment of 72 bytes. 3 microseconds
later, I get the ICMP6 packet of 1294 bytes. This pattern is consistent
over repeated packets. This was with -s 1234 for a total ICMPv6 size of
First, why is the kernel fragmenting this at all as it fits in the
Second, why the heck is the fragment going out first? This should be OK,
but I suspect many firewalls (which are often not happy with fragments)
are not likely to pass a fragment which precedes the initial frame.
Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is
something in the path that is blocking my traffic, so others may not see
this, but I think the root issues is the kernel fragmenting packets way
below MTU size.
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
More information about the freebsd-net