ipv6 quirk openwrt 21.02.1

[Nathan Lutchansky]

On 11/4/21 11:52 AM, Paul D wrote:
> Having a bit of IPv6 6in4 problem. I set a static MTU to 1480 locally 
> and remotely (HE tunnel).
>
>
> As I interpret the RFC [1] as referenced by overarching RFC [2], it 
> notes:
>
> >  When using the static tunnel MTU, the Don't Fragment bit MUST NOT be
> >  set in the encapsulating IPv4 header.  As a result, the encapsulator
> >  should not receive any ICMPv4 "packet too big" messages as a result
> >  of the packets it has encapsulated.
>
> But pcaps clearly show in the IPv4 packet:
>
> > Flags: 0x40, Don't fragment
> >     0... .... = Reserved bit: Not set
> >     .1.. .... = Don't fragment: Set
> >     ..0. .... = More fragments: Not set
>
> Is this considered normal IPv6 tunneling behaviour? Or is this broken?

This is normal for Linux. Since forcing routers to perform fragmentation 
mid-path is a huge performance hit, Linux uses path MTU discovery to 
determine the real MTU of the tunnel, and then generates 
fragmentation-needed errors at the tunnel ingress if the outer packet 
would be too large for the path.

It is possible to switch to the RFC-compliant behavior by setting 
"nopmtudisc" on the tunnel interface with the `ip` tool. Unfortunately, 
this is not implemented in netifd for 6in4 interfaces, so you would have 
to script the tunnel creation yourself.

However, it is a moot point as I don't believe HE's tunnel endpoints 
will reassemble fragmented packets.


> The diagnostics I perform are at IPv6, so if broken, 6in4 seems to be 
> errantly setting the DF bit in the IPv4 packet, and the 6in4 interface 
> sends a packet-too-big reply back for the re-assembled IPv6 ping 
> reply, if ping6 <dest> -s <size> size is >= 1232
>
>
> That in itself seems like a bug - that ipv6 on openwrt sends a 
> packet-too-big despite a static MTU big enough:
>
>
> 21    2021-11-04 14:56:06.394484    2001:470:XX:YY:ZZ::3 
> 2001:470:XX-1:YY::1     IPv6    1318    IPv6 fragment (off=0 more=y 
> ident=0xc6c3481c nxt=58)
> 22    2021-11-04 14:56:06.394538    2001:470:XX:YY:ZZ::3 
> 2001:470:XX-1:YY::1     ICMPv6    102    Echo (ping) request 
> id=0x0557, seq=0, hop limit=63 (reply in 23)
> 23    2021-11-04 14:56:06.437221    2001:470:XX-1:YY::1 
> 2001:470:XX:YY:ZZ::3     ICMPv6    1326    Echo (ping) reply 
> id=0x0557, seq=0, hop limit=64 (request in 22)
> 24    2021-11-04 14:56:06.437491    2001:470:XX-1:YY::2 
> 2001:470:XX-1:YY::1     ICMPv6    1318    Packet Too Big
>
>
> All underlying MTUs which are available to set, are ~1480-1500.
>
This is expected behavior if nopmtudisc is not set on the tunnel 
interface. Regardless of the configured MTU, the kernel will use the 
PMTUD result as the effective MTU of the tunnel.  -Nathan