Some comments: The doc starts by grouping ICMP-based path MTU discovery (PMTUD) with in-band discovery (PLPMTUD), but asserts (in the first paragraph) that the group term “path MTU discovery” isn’t deployed due to security concerns. I have seen no such concerns about PLPMTUD - if you are aware of them, they should be cited. More broadly, however, these two mechanisms should NOT be lumped together.
IP fragmentation is controlled at both the system (as a default for all new sockets) and per-socket level; this should be discussed. I disagree with “MAY probe to find path MTU”; IMO, they SHOULD. Appendix C implies that there is a way to know the path MTU by direct request. Unless this is verified with probes (as in PLPMTUD), any value returned is at best a hint and could be incorrect. This should be noted. It wouldn’t hurt (IMO) to point out the potential to use higher level fragmentation that avoids the issues with IP fragmentation. I’m not a DNS wonk but I’m surprised to see this doc imply that there isn’t such a mechanism at the application layer. Additionally, we are working on a mechanism at the UDP layer (UDP options) that may be useful in the future (not to recommend now, of course). Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Jul 29, 2022, at 5:12 AM, Kazunori Fujiwara <fujiw...@jprs.co.jp> wrote: > > Dear intarea WG, > > dnsop WG is working on a document to avoid IP fragmentation in DNS. > Now, the draft is on Working Group Last call in dnsop WG (until August 16). > > The draft attempt to advance the goals of RFC 8900 IP Fragmentation > Considered Fragile. (Section 5.1 Domain Name System (DNS)) > > As one of the co-authors of the draft, I would like advices from > intarea because there may be inadequate descriptions related to path > MTU discovery and DF bit / IPV6_DONTFRAG. > > Fragmentation Avoidance in DNS > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ > > > (1) About DF bit, IPV6DONTFRAG > > | 1. Introduction > | > | This document proposes to set IP_DONTFRAG / IPV6_DONTFRAG in DNS/UDP > | messages in order to avoid IP fragmentation, and describes how to > | avoid packet losses due to IP_DONTFRAG / IPV6_DONTFRAG. > > | 2. Terminology > | > | IP_DONTFRAG option is not defined by any RFCs. It is similar to > | IPV6_DONTFRAG option defined in [RFC3542]. IP_DONTFRAG option is > | used on BSD systems to set the Don't Fragment bit [RFC0791] when > | sending IPv4 packets. On Linux systems this is done via > | IP_MTU_DISCOVER and IP_PMTUDISC_DO. > > | 3.1. Recommendations for UDP responders > | > | * UDP responders SHOULD send DNS responses with IP_DONTFRAG / > | IPV6_DONTFRAG [RFC3542] options. > > (2) about path MTU discovery > > | 2. Terminology > | > | "Path MTU" is the minimum link MTU of all the links in a path between > | a source node and a destination node. (Quoted from [RFC8201]) > | > | In this document, the term "Path MTU discovery" includes Classical > | Path MTU discovery [RFC1191], [RFC8201], Packetization Layer Path MTU > | discovery [RFC8899] and as well as similar methods. > > | 3.2. Recommendations for UDP requestors > | > | * UDP requestors MAY probe to discover the real MTU value per > | destination. (Path MTU discovery per destionation) Then, > | calculate their maximum DNS/UDP payload size as the reported path > | MTU minus IPv4/IPv6 header size (20 or 40) minus UDP header size > | (8). If the path MTU discovery failed or is impossible, use the > | default maximum DNS/UDP payload size 1400. > > ------------ > > Regards > > -- > Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > > _______________________________________________ > Int-area mailing list > int-a...@ietf.org > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
