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: > > > > 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. > > I will remove "Path MTU discovery remains widely undeployed due to > security issues" from abstract. > > > 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)?
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
