Given that IP_PMTUDISC_PROBE exists (and has existed for more than 10 years), I don't understand how this sweeping statement can be justified. I'm not familiar with the history of RFC 9715, but maybe an errata against this RFC would be appropriate?
I really don't want to relitigate this issue in my current draft (draft-seemann-tsvwg-udp-fragmentation, Controlling IP Fragmentation on Common Platforms) though. I believe using IP_PMTUDISC_PROBE is perfectly safe, and that's what QUIC stacks that implement DPLPMTUD have been doing. On Fri, 21 Mar 2025 at 09:05, C. M. Heard <he...@pobox.com> wrote: > Greetings, > > The I-D "Controlling IP Fragmentation on Common Platforms > <https://datatracker.ietf.org/doc/html/draft-seemann-tsvwg-udp-fragmentation>," > targeted as an information RFC, was presented in a recent IETF 122 tsvwg > session and is under consideration for adoption in that working group. > > At least one of the findings reported therein has a bearing on > Recommendation R2 in Section 3.1 of RFC 9715 > <https://datatracker.ietf.org/doc/html/rfc9715#name-proposed-recommendations-fo> > : > > Linux systems do not expose a direct API for this purpose and require the > use of Path MTU socket options (IP_MTU_DISCOVER) to manage fragmentation > settings. However, it is important to note that enabling IPv4 Path MTU > Discovery for UDP in current Linux versions is considered harmful and > dangerous. For more details, see Appendix C > <https://datatracker.ietf.org/doc/html/rfc9715#impl>. > > This may already be out-of-date, given what I see in Section 3.1 > <https://datatracker.ietf.org/doc/html/draft-seemann-tsvwg-udp-fragmentation#name-linux> > of > the aforementioned draft: > > PMTUD behavior is controlled via the IP_MTU_DISCOVER and IPV6_MTU_DISCOVER > socket options at the IPPROTO_IP and IPPROTO_IPV6 levels. There are two > closely related values: For IPv4, both IP_PMTUDISC_DO and IP_PMTUDISC_PROBE > enable setting the DF bit. For IPv6, both IPV6_PMTUDISC_DO and > IPV6_PMTUDISC_PROBE prevent fragmentation by the sender.¶ > <https://datatracker.ietf.org/doc/html/draft-seemann-tsvwg-udp-fragmentation#section-3.1-1> > > The difference between the former and the latter is that the former > instructs the kernel to process ICMP "Fragmentation Needed" messages, while > the latter does not.¶ > <https://datatracker.ietf.org/doc/html/draft-seemann-tsvwg-udp-fragmentation#section-3.1-2> > This point may be worth considering when and if RFC 9715 is updated from > Information to RFC. > > Thanks and regards, > > Mike Heard > > On Mon, May 6, 2024 at 6:59 AM Petr Špaček wrote: > >> Hello dnsop, >> >> Warren asked implementers to provide feedback on the current text, so >> I'm doing just that. >> > [ ... ] > >> On 01. 03. 24 3:54, internet-dra...@ietf.org wrote: >> > Internet-Draft draft-ietf-dnsop-avoid-fragmentation-17.txt is now >> available. >> > It is a work item of the Domain Name System Operations (DNSOP) WG of >> the IETF. >> > >> > Title: IP Fragmentation Avoidance in DNS over UDP >> > Authors: Kazunori Fujiwara >> > Paul Vixie >> > Name: draft-ietf-dnsop-avoid-fragmentation-17.txt >> > Pages: 14 >> > Dates: 2024-02-29 >> > > > [ ... ] > >> >> > R2. Where supported, UDP responders SHOULD set IP "Don't Fragment flag >> (DF) bit" [RFC0791] on IPv4. At the time of writing, most DNS server >> software did not set the DF bit for IPv4, and many operating systems' >> kernels constraint make it difficult to set the DF bit in all cases. >> >> E.g. on Linux socket API does not expose DF bit directly. Application >> can request DF bit to be turned on in outgoing packets but at the same >> time this implicitly enables receipt and processing of unauthenticated >> ICMP messages. These messages can be used to manipulate Path MTU records >> in the kernel and mount attacks misusing this technique. > >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
