https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291617
--- Comment #1 from Kristof Provost <[email protected]> --- I've been trying to replicate this, and can't quite manage. In fact, in my test an overly large ping just succeeds. This is a little unexpected, but actually makes some amount of sense. For context, the test setup (in aft-python) has a 1500 byte MTU on the IPv6 side, which the nat64 router reduces to 1400 on its IPv4 side (and the next router further reduces to 1300, for $reasons). A ping of 1408 bytes to a host on the 1300 MTU IPv4 side just succeeds, because the nat64 code uses pf_route(), which fragments the IPv4 packet. Routers are allowed to do that to IPv4 (unless DF is set, but that doesn't exist on the IPv6 side, being implied, and we don't set it for IPv4 traffic. To say that differently, the PMTU discover ends at the nat64 router, because it's not required in IPv4. I am unclear on why you'd see transmission failures on the epair though. As I said, pf_route() will fragment (https://cgit.freebsd.org/src/tree/sys/netpfil/pf/pf.c#n9378). There are a few exceptions: if DF is set (it won't be, pf_translate_af() doesn't set it), or if the outgoing interface announces TSO support (in which case it's assumed the interface will do the fragmentation). if_epair doesn't announce TSO support, so I don't see how either case could apply. Are both ends of the epair interface set to the same MTU? (Iirc. if_epair doesn't do that automatically) -- You are receiving this mail because: You are the assignee for the bug.
