Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt

[Mark Andrews <[e-mail]>]

> On 10 Jul 2020, at 01:34, Marek Majkowski <[e-mail]> wrote:
> 
> On Thu, Jul 9, 2020 at 3:35 AM Mark Andrews <[e-mail]> 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: [phone]              INTERNET: [e-mail]