Moin,

I agree with this point, and will happily remove this paragraph in
place of only stating the reference to min-MTU/TCP_MAXSEG (which, iirc,
the draft explicitly notes further below) and RFC9715.

However, the above is a vocal counter argument against IPv6 for DNS,
and as such was strongly required during an earlier discussion...

So, as an author, I am currently receiving a bit of mixed signals from
the group here.

With best regards,
Tobias

On Tue, 2025-08-05 at 11:30 +1000, Mark Andrews wrote:
> 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]

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M [email protected]
Pronouns: he/him/his

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to