Date: Thu, 14 May 2009 14:42:35 -0700 From: "Kevin Oberman" <oberman@es.net> To: freebsd-net@freebsd.org Subject: IPv6 fragmentation weirdness Message-ID: <20090514214235.B09701CC12@ptavv.es.net>
next in thread | raw e-mail | index | archive | help
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 byte packets. 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? 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@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090514214235.B09701CC12>