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

[Lee]

On 9/2/19, Paul Vixie <paul at redbarn.org> wrote:
> 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).

I thought we both agreed that path mtu discovery couldn't be relied
on, but whatever..

> and to state
> again for the record, i am not asking the DNS community to take that on.

I was wondering.  It wasn't clear exactly what you were asking for.

> 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".

I think I understand now.  "unless better information is available"
sounds reasonable enough

Thanks
Lee