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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
