ipv6 quirk openwrt 21.02.1

[Paul D]

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?


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.



Can anyone else confirm this behaviour, also?


21.02.1


[1] https://datatracker.ietf.org/doc/html/rfc4213#section-3.2.1
[2] https://datatracker.ietf.org/doc/html/rfc7059