Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Peter van Dijk <[e-mail]>]

On Mon, 2021-04-19 at 07:31 -0400, Joe Abley wrote:
> NEW:
> 
>    For IPv4-connected hosts, the MTU is often the Ethernet payload
>    size of 1500 bytes.  This means that the largest unfragmented
>    UDP DNS message that can be sent over IPv4 is likely 1472 bytes,
>    although tunnel encapsulation may reduce that maximum message
>    size in some cases.
> 
>    For IPv6, the situation is a little more complicated.  First,
>    IPv6 headers are 40 bytes (versus 20 without options in IPv4).
>    Second, it seems as though some people have mis-interpreted
>    IPv6's required minimum MTU of 1280 as a required maximum.  Third,
>    fragmentation in IPv6 can only be done by the host originating
>    the datagram.  The need to fragment is conveyed in an ICMPv6
>    "packet too big" message.  The originating host indicates a
>    fragmented datagram with IPv6 extension headers.  Unfortunately,
>    it is quite common for both ICMPv6 and IPv6 extension headers
>    to be blocked by middleboxes. According to [HUSTON] some 37% of
>    IPv6-capable recursive resolvers were unable to receive a
>    fragmented IPv6 packet.  Even if the originating host does receive
>    a signal that fragmentation is required, the stateless nature
>    of the DNS protocol is such that the host does not generally
>    retain a copy of the message concerned and hence is unable to  
>    fragment and re-send anyway. 

This note on statelessness is good, but I don't think it should be tied to IPv6. Packets get lost in IPv4 too, especially when they are big, and even if such evens trigger a report in the form of an ICMP message, the same lack-of-state problem applies.

https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ even proposes setting DONTFRAG socket options, and some servers out there already send IPv4 replies with the DF bit set (the two I can verify immediately are OpenDNS, and whatever is running on the router my provider gave me, but most likely there are others too).

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/