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/ _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
