On 2019-03-03 20:13, Mark Tinka wrote:
On 3/Mar/19 18:05, Jeroen Massar wrote:
IPv6 requires a minimum MTU of 1280.
If you cannot transport it, then the transport (the tunnel in this case) needs to handle the fragmentation of packets of 1280 down to whatever does fit in the tunnel.
As you know, IPv6 does not support fragmentation in transit. So that's not an option.
The transport (tunnel) CAN support that kind of fragmentation. (e.g. the tunnel could chop up a 1280 byte packet into two packets and the remote then join them together; that is a "ethernet" level thing). Indeed, IPv6 won't do it: get a better transport.
Host fragmentation is per standard, but signaling of that was not so successful in IPv4. Real world scenarios for IPv6 (reasonably) apply here.
Real world for IPv6 is: do not try to transport it over a medium that does not support packets of at least 1280 bytes.
Have fun with all your UDP traffic that does not care about your TCP MSS adjustment. You just hid the problem...
I considered this issue, but as with all things UDP re: fragmentation, it depends.
Testing I've been doing all day shows previously (mostly-TCP) issues have resolved, and I've not run into any major problems that are impacting UDP. Nonetheless, I'm keeping an eye out.
And a correctly configured MTU is especially going to be fun with "HTTP/3" that is being pushed through, even though the predecessor QUIC does not care about MTU at all... good that it is all in the hands of a company that can fix it themselves ;)
Is it an ideal situation? About as ideal as flying in the cargo bay. But my reality is that until my FTTH provider can deliver native IPv6, this is what I have.
Maybe you should ask this "FTTH" provider to deliver a decent MTU size? (next to native IPv6, something something, 20+ years old protocol...) Greets, Jeroen