--minMTU6 applied to IPv4 packets with DF=1

[toreanderson]

When Jool receives an IPv4 packet with DF=1 that would be too large to fit in the --minMTU6 value, but not too large to fit in the MTU of the IPv6 egress interface, it returns an ICMPv4 Fragmentation Needed, as seen here with --minMTU6 1280:

12:38:49.811512 IP (tos 0x0, ttl 63, id 60034, offset 0, flags [DF], proto UDP (17), length 1328)
    87.238.39.42.12345 > 185.47.42.1.4444: UDP, length 1300
12:38:49.811571 IP (tos 0xc0, ttl 64, id 63918, offset 0, flags [none], proto ICMP (1), length 576)
    185.47.41.3 > 87.238.39.42: ICMP 185.47.42.1 unreachable - need to frag (mtu 1260), length 556
    IP (tos 0x0, ttl 63, id 60034, offset 0, flags [DF], proto UDP (17), length 1328)
    87.238.39.42.12345 > 185.47.42.1.4444: UDP, length 1300

I believe this is incorrect behaviour per section 4 of RFC 6145. When the IPv4 sender sets DF=1, PMTUD can operate across the translator, and there is no need for Jool to send ICMPv4 Fragmentation Needed (except if the the packet can't fit in the MTU of egress IPv6 interface of the Jool server).

The way I read the RFC, the --minMTU6 functionality only applies when the sender doesn't set the DF flag. I'm quoting the relevant passages below:

   When an IPv4 node performs path MTU discovery (by setting the Don't
   Fragment (DF) bit in the header), path MTU discovery can operate end-
   to-end, i.e., across the translator.  In this case, either IPv4 or
   IPv6 routers (including the translator) might send back ICMP Packet
   Too Big messages to the sender.  When the IPv6 routers send these
   ICMPv6 errors, they will pass through a translator that will
   translate the ICMPv6 error to a form that the IPv4 sender can
   understand.  As a result, an IPv6 Fragment Header is only included if
   the IPv4 packet is already fragmented.

   However, when the IPv4 sender does not set the DF bit, the translator
   MUST ensure that the packet does not exceed the path MTU on the IPv6
   side.  This is done by fragmenting the IPv4 packet (with Fragment
   Headers) so that it fits in 1280-byte IPv6 packets, since that is the
   minimum IPv6 MTU.  The IPv6 Fragment Header has been shown to cause
   operational difficulties in practice due to limited firewall
   fragmentation support, etc.  In an environment where the network
   owned/operated by the same entity that owns/operates the translator,
   the translator MAY provide a configuration function for the network
   administrator to adjust the threshold of the minimum IPv6 MTU to a
   value that reflects the real value of the minimum IPv6 MTU in the
   network (greater than 1280 bytes).  This will help reduce the chance
   of including the Fragment Header in the packets.

[ydahhrk]

Good point; adding to the current milestone.

[ydahhrk]

We fixed this, but then sort of reintroduced it when we decided to defer fragmentation to the kernel.

Will open the updated status quo as another issue later.