On 14/09/17 09:38, Dave Mill wrote:
Really, the 1492 packet size is just a non issue.
FWIW, in case people didn't see these APNIC blog posts last month, there's a risk of this ending up being an IPv6/UDP issue: https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/ https://blog.apnic.net/2017/08/29/dealing-ipv6-fragmentation-dns-part-2/ """However, what it does indicate is that some one-fifth of IPv6-capable endpoints are unable to receive a fragmented IPv6 packet. In TCP this may not be a major issue, but for UDP-based applications, and the DNS sites first and foremost as a UDP application where large packet responses are common, having one-fifth of the end-user population being incapable of receiving fragmented large responses over IPv6 is indeed a serious problem. [...] Whatever the reasons, the conclusion here is unavoidable: IPv6 fragmentation is just not a viable component of the IPv6 Internet. We need to adjust our protocols to avoid fragmentation. """ So forcing 1500/1492 MTU mismatch on end users is still potentially a landmine for the future. IMHO it'd be useful to push end users/CPE devices towards at least doing mini-jumbo-frames on the ONT/upstream side so that 1500-byte user packets can be passed as-is. From some casual investigation, QUIC -- which is UDP based -- appears to have decided it simply can't assume 1500-byte MTU will get through, and limited itself to 1350 data payload, plus various protocol headers (UDP, IPv4, etc), coming in well under 1480 all up. It may be that everything else without robust PMTU ends up having to make the same assumptions, forever, because we carry the past with us. Ewen