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