On Thu, Jul 9, 2020 at 3:35 AM Mark Andrews <ma...@isc.org> wrote: > > I have two problems with this proposal. First, it doesn't mention IPv4 > > vs IPv6 differences at all. In IPv4 landscape fragmentation, while a > > security issue, is generally fine. In the IPv6 world, fragmentation is > > disastrous - packets with extension headers are known to be dropped. > > Not really. UNKNOWN extensions tend to get dropped but the fragmentation > header is a KNOWN extension header.
https://labs.apnic.net/presentations/store/2019-09-11-ipv6-fail.pdf Slide 34 and 35 indicate, with IPv6: - 38% recursive resolvers fail to reassemble packets with fragmentation extension header - 22% of browsers fail to process TCP packets with fragmentation header This data is from 2017 - around that time I did similar experiments with similar results. Delivery of fragmented packets in IPv6 sometimes work, but this is more of an exception than a rule. > > Second, this proposal assumes that path MTU detection works correctly. > > This is surprisingly optimistic. Let's consider IPv6 - in IPv6 the > > smaller path MTU < 1500 is very common. > > Which is why IPV6_USE_MIN_MTU exists (RFC 3542). USE THE SOCKET OPTION. > It was put there specifically to support DNS over UDP and other applications > like that. I know this as I proposed the predecessor option back in 1999 > which became IPV6_USE_MIN_MTU. You are suggesting to always use at most 1280 byte packets in IPv6. The draft we are discussing does not suggest that. Did I misunderstand something? Marek _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
