Re: [RFC] ipv6: dst_allfrag() not taken into account by TCP

[Tore Anderson <tore@fud.no>]

* Eric Dumazet

> Now I wonder if some RFC can allow us to send small frames without a
> frag header, since this frag header forces us to perform tx checksum in
> software.

Yes. In my opinion, the most correct thing to do would be to keep track
of the actual IPv6 Path MTU (the value indicated in the ICMPv6 Packet
Too Big message received) as a separate property that is added to the
routing cache, and to include the Fragment header only if you transmit
a packet that is larger than the PMTU.

So, let's say you get an ICMPv6 PTB with MTU=800. Then the resulting
host route added to the routing cache should contain both "mtu 1280"
as well as "pmtu 800". You can then safely omit the Fragmentation
header from any packet smaller than 800 bytes. You might of course then
get another ICMPv6 PTB with an even smaller MTU originated from an IPv4
router even further out in the path, which should then result in
lowering the cached pmtu value further, of course.

> > I guess 576 should be safe ?

I have difficulty determining whether or not the minimum permitted IPv4
MTU is 576 or 68 bytes, actually. Assuming it's the latter, by hard-
coding the former, you may end up in a situation where you'll be stuck
in a PMTUD loop - you'll be re-transmitting 576 bytes large packets
over and over again, while getting back ICMPv6 PTBs with an even lower
MTU value for each of the packets you transmit.

That said, you can add 20 bytes to whatever value you hard-code, as the
IPv6 header is 20 bytes larger than the IPv4 header. In other words,
596- and 88-byte large IPv6 packets will be translated into 576- or
68-byte large IPv4 packets.

Another way of solving it and avoiding the Fragmentation headers
altogether would be to allow the "route MTU" to drop below 1280 as a
result of Path MTU Discovery. I opened an enchancement bug report
requesting this:

https://bugzilla.kernel.org/show_bug.cgi?id=42599

Best regards,
-- 
Tore Anderson