Hi Andrew, On Aug 4, 2022, at 15:33, Andrew McConachie <and...@depht.com> wrote:
> I apologize for derailing this conversation by bringing up NAT. My point was > that the document makes a claim that PMTUD ‘remains widely undeployed due to > security issues’. Yet it makes no reference to anything that might back up > that claim. I think the concern about the assertion and the lack of citation are reasonable and it ought to be possible to improve the text. Anecdotally, the problems I have observed with pMTUd is with networks that blindly and misguidedly block all ICMP inbound "because security" which breaks the signalling path that pMTUd relies upon to know that an interface with a small MTU has been found by an outbound packet sent with DF=1. This used to be [*] overwhelmingly common when sending large responses back from servers to client devices attached through tunnels, e.g. CPE routers using upstream PPPoE: servers that are "protected" by over-suppression of downstream ICMP have no way of knowing that a packet has been dropped and sessions stall. For TCP this is mitigatable on the client side (in this example) by techniques like MSS-clamping in the CPE. For other layer-4 protocols, not so much. This makes failures difficult to troubleshoot since "the internet" seems fine for some users/applications but broken for others. I do not have a convenient reference for this, but searching for "operational problems with pmtud" seems to yield a healthy number of results, so perhaps something suitable can be found quite easily. RFC 2923 contains descriptions of various problems that are relevant, although its clearly-stated focus is with TCP transport, not UDP. Joe [*] might still be, but I'm more distant from the operational front line than I used to be, these days _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
