Re: Fun and surprises with IPv6 fragmentation

[Christian Huitema <[e-mail]>]

Thanks to all of you for the comments. I updated my blog entry on the
subject
(https://huitema.wordpress.com/2018/03/03/having-fun-and-surprises-with-ipv6/)
with the following new conclusion:

/It seems clear now that the fragmentation happened at the source, in
the Linux kernel. This leaves one remaining issue, the out of order
delivery./

/There are in fact two separate out of order delivery issues. One is
having the second fragment arrive between the first one, and the second
is having the MTU probe arrive before the previously sent Handshake
packet. The inversion between the segments may be due to code in the
Linux kernel that believes that sending the last segment first speeds up
reassembly at the receiver. The inversion between the fragmented MTU
probe and the Handshake packet has two plausible causes:/

  * /Some router on the path may be forwarding the small fragment at a
    higher priority level./
  * /Some routers may be implementing equal cost multipath, and then
    placing fragmented packets and regular packets into separate hash
    buckets/

/The summary for developers, and for QUIC in particular, is that we
should really avoid triggering IPv6 fragmentation. It can lead to packet
losses when NATs and firewalls cannot find the UDP payload type and the
port numbers in the fragments. And it can also lead to out of order
delivery as we just saw. And for my own code, the lesson is simple. I
really need to set up the IPv6 Don’t Fragment option when sending MTU
probes, per section 11.2 of RFC 3542
<https://tools.ietf.org/html/rfc3542#section-11.2>.

/-- Christian Huitema