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
