> On 10 Jul 2020, at 01:34, Marek Majkowski <[email protected]> wrote: > > On Thu, Jul 9, 2020 at 3:35 AM Mark Andrews <[email protected]> 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
Which means 62% of the world properly handles fragmented UDP packets. Also I forget how Geoff was actually performing the test. Where any of the responses greater than the advertised EDNS buffer size sent? Was fragmentation introduced when the UDP response size was less that 1280? > - 22% of browsers fail to process TCP packets with fragmentation header Which seems to be a very strange test to perform given that TCP segments are supposed to be atomic on IPv6. > 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? I’m suggesting that if you send UDP/IPv6 packets > 1280 that you force them to be fragmented into 1280 octet fragments. I’m suggesting that we force DNS/TCP/IPv6 packets to never be bigger that 1280 for regular requests. AXFR/IXFR would be a potential exception. Clients and servers can do this by setting the MSS to an appropriate value (1280-IPv6 header size-TCP header size). Setting IPV6_USE_MIN_MTU should also achieve this as TCP is supposed to take into account path MTU which is 1280 when this option is set. The IETF has designed IPv6 such that it is possible to run a DNS server that will never receive a ICMPv6 PTB to traffic it sends even if other applications on the server do. > Marek -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
