Are we using the recent fragmentation avoidance rfc so soon? Mark, the locally witnessed network MTU does not completely predict the full path MTU. Plpmtud is and should remain in scope. Let's not close off a way to reach reasonable datagram sizes in the future. Every 10x in speed should someday show up as 3.333x in packet rate and 3.333x in packet size. We are using tinygrams in comparison. What we do today will affect the possibilities later. Vixie Paul Vixie
Aug 5, 2025 03:30:00 Mark Andrews <[email protected]>: > draft-ietf-dnsop-3901bis-03 states: > > If the requesting resolver is unable to process fragments, or if > fragments are filtered on-path, resolution will fail over UDP. > These issues are more prevalent for IPv6, as it no longer allows > on-path hosts to fragment packets. Therefore, working Path MTU > Discovery (PMTUD) is essential for IPv6 DNS-over-UDP packets to be > fragmented to a size that allows them to traverse all segments on > a path. > > This is not factually correct. There is NO requirement to perform PMTUD > at all in a DNS server over IPv6. For UDP you just fragment at network > MTU in the sending node at network MTU. This can be achieved by using > IPV6_USE_MIN_MTU=1 socket option from RFC 3542 or using an interface that > is configured with a MTU that matches the network MTU. For TCP you use > the socket option TCP_MAXSEG to set the MSS to the network MTU. > > Both of these options have been used for years in nameservers and avoid > response losses caused by attempting PMTUD itself. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
