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
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
https://list.waikato.ac.nz/mailman/listinfo/nznog
