[Netalyzr] IPv6 Fragements issue - netalzer problem?
nweaver at ICSI.Berkeley.EDU
Mon Mar 11 11:41:35 PDT 2013
On Mar 11, 2013, at 11:26 AM, "Bjoern A. Zeeb" <bzeeb-lists at lists.zabbadoz.net> wrote:
> some people here at the IETF ocnference network are seeing IPv6
> Fragements dropped in netalyzer results. We cannot really otherwise
> reproduce this but lowering the MTU of the local client fixes the
> problem. Could that be an issue with (one of) the netalzer servers?
> One of the results is here:
> One thing we cannot easily test is the reverse path from you to us.
> If you need a test target 2001:df8:0:5::8 should be fine.
I'm not able to ping that host.
Well, the reverse path is 1500B clean: The maximum MTU that can be sent from the server to the client is 1500B.
Its test-43 in the transcript:
It tries to send a UDP datagram of 2000B in Java to port 1948, but its not reassembled by the Linux server on the other side. (This service is written in python, and uses just the standard Unix API). It tries to send this packet multiple times in case of packet loss or a path MTU bottleneck forces things to be resent.
It then tries to send a small datagram where the reply is 2000B to port 1948, but its not reassembled by your client.
It then sends a packet to our raw-socket server on 1949: This server is written in C and uses PCAP & raw sockets. This returns the size of the FIRST fragment (which does get through), and thats sent with an MTU of 1280, so unfragmented send can work with an MTU of at least 1280.
It then asks to receive a packet of 1500B from our raw-sokcet server. This packet is successfully received, so there is no path MTU chokepoint in the return path.
When I get home tonight, I can validate that this test is still working on my home connection by plugging in directly to the network (Comcast residential IPv6. My AirPort Extreme, at least used to not handle IPv6 fragmentation).
There is only one IPv6 server, hosted in Host Virtual.
More information about the Netalyzr