[dns-operations] DNS flag day 2020: Recommended EDNS buffer size discussion

[Paul Vixie]

On Monday, 2 September 2019 20:41:55 UTC Lee wrote:
> On 9/2/19, Paul Vixie <paul at redbarn.org> wrote:
> > On Monday, 2 September 2019 17:31:50 UTC Lee wrote:
> >> I think tcp mss working as well as it does is because the mss is
> >> negotiated at connection setup time (syn, syn+ack option tcp mss
> >> size).
> > 
> > no.
> 
> Are we arguing definitions?

perhaps.

> Source sends a SYN with the tcp mss option set to 1460, destination
> responds with a SYN+ACK with the tcp mss option set to 1280, both
> sides use an mss of 1280.  Which sounds like a negotiation to me..

neither side will transmit a larger segment than their PMTU indicates, nor 
larger than the far end's MSS offer indicates. so it amounts to the same 
outcome as you describe. as shown in RFC 6691, there are other reasons for 
sending even-smaller segments in some cases, which are per-segment and per-
sender and which are neither visible nor relevant to the far end. so, i have 
always treated MSS as an advertised maximum, not an agreed limit.

> > and it proceeds from local
> > knowledge of the path MTU like the routing table or the sysctl definitions
> > set by a sysadmin. generally speaking path MTU discovery does not work
> 
> Right - generally speaking path MTU discovery does not work.  So when
> setting up ipsec tunnels between routers I'd also configure ip tcp
> adjust-mss to lower the offered mss on traffic going through the
> tunnel & have everything work.

as we all do.

> I never did figure out how to automatically fix udp traffic.  So I'm
> not understanding how your suggestion to use what works for tcp is
> applicable to udp.

here's the text from RFC 2923 which applies:

> While Path MTU Discovery (PMTUD) can be used with any upper-layer
> protocol, it is most commonly used by TCP;  this document does not
> attempt to treat problems encountered by other upper-layer protocols.

see also this text from RFC 1122:

> However, in general the TCP layer may not have the
> appropriate information to make this decision, so it is
> preferable to leave to the IP layer the task of
> determining a suitable MTU for the Internet path.  We
> therefore recommend that TCP always send the option (if
> not 536) and that the IP layer determine MMS_R as
> specified in 3.3.3 and 3.4.  A proposed IP-layer
> mechanism to measure the MTU would then modify the IP
> layer without changing TCP.

the final sentence is, to me, the key to the future of PMTUD(6). and to state 
again for the record, i am not asking the DNS community to take that on. what 
i am asking is that any standard we write be future-proof in the sense that 
whatever "practical maximum" is chosen (1200, or similar) be described in the 
context of "unless better information is available". for example if my MTU was 
576 (can happen on serial and low-power networks) i would not want to 
advertise ~1200 as my edns buffer size, for the same reason that TCP would not 
advertise ~1200 as its MSS.

-- 
Paul