IPv6 fragmentation weirdness

[JINMEI Tatuya / 神明達哉]

At Thu, 14 May 2009 14:42:35 -0700,
"Kevin Oberman" <oberman at es.net> wrote:

> 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
> 1282.
> 
> First, why is the kernel fragmenting this at all as it fits in the
> interface MTU?

Do you mean why ping6 has the kernel fragment echo requests at 1280
bytes by default (i.e., when invoked without -m)?  If so, that's
because if a large echo request triggers path MTU discovery, some
initial requests won't be replied (recall that IPv6 routers never
fragment packets by themselves; they always drop too-large packet with
returning an ICMPv6 error).

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

Do you mean, for example, the kernel sends out a fragment with a non-0
offset before the 0-offset one?  I can't believe this.  If I tried
% ping6 -s 1300 www.isc.org
from a FreeBSD 6.3 host, I saw this:

08:22:04.821171 IP6 2001:200:0:8002:203:47ff:fea5:3085 > 2001:4f8:0:2::d: frag (0|1232) ICMP6, echo request, seq 0, length 1232
08:22:04.821181 IP6 2001:200:0:8002:203:47ff:fea5:3085 > 2001:4f8:0:2::d: frag (1232|76)

(captured on the sending host).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.