Re: Fun and surprises with IPv6 fragmentation

[Ryan Hamilton <[e-mail]>]

I missed this summary when you sent it out earlier. Thanks for getting to
the bottom of this, and for the detailed explanation. Your conclusion fo
always set the DF option when sending makes a ton of sense. IP fragments
are ... not awesome!

On Sun, Mar 4, 2018 at 10:45 AM, Christian Huitema <[e-mail]>
wrote:

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