> From: Mukund Sivaraman <m...@mukund.org> > Subject: Re: [DNSOP] [Int-area] Please review > draft-ietf-dnsop-avoid-fragmentation > Date: Tue, 16 Aug 2022 10:58:04 +0530
> On Tue, Aug 16, 2022 at 01:07:34PM +0900, Kazunori Fujiwara wrote: >> Thanks very much for your review. >> >> > From: "to...@strayalpha.com" <to...@strayalpha.com> >> > Some comments: >> > 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. >> >> I will consider changing to "SHOULD" at recommendations to UDP >> requestors (DNS clients). > > Some resolver implementations where possible turn off the effect of ICMP > v4 frag needed and v6 PTB messages to affect the kernel's PMTU cache (as > a blanket cover for possible vulnerabilities in this area). > > As an example, the resolvers in NIOS, BIND, Loop (all of which are BIND > or derived from BIND code) set the IP_PMTUDISC_OMIT and > IPV6_PMTUDISC_OMIT socket options to prevent how the Linux kernel uses > ICMP frag needed/PTB messages received over udp4/udp6 sockets > respectively to modify the PMTU for that peer. > > Would the SHOULD be satisfied by application layer fallback to smaller > advertised sizes (e.g., RFC 6891 section 6.2.5 fallback to lower > requestor payload sizes)? I meant "Yes". In section 2, "Path MTU discovery" | 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. One of the "similar methods" was supposed to be how BIND 9 chooses EDNS requestors payload size, starting with 512 and larger, per IP address. If you have good idea, please propose good text. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
