Subject: [DNSOP] bar bof, edns buffer size, avoid fragmentation

From: Paul Vixie <[email-masked]>
Date: Mon, 22 Jul 2019 19:33:32 -0400

fujiwara-san and i will be at an otherwise quiet bar at 21h local time tonight, here in the neighborhood of ietf Montreal. email me if you want to join us.

⁣Get BlueMail for Android ​

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Jul 2019 00:19:18 +0000

with four of us in attendance monday evening, i presented my appreciation for 
fujimora-san's draft and admitted that EDNS0 ought to have required DF and 
ought to have used examples which would fit in a then-common MTU 1500 network.

i then asked that numbers like 1220, 1280, 576, and 1500 not be specified as 
fixed constants, but rather, should be computed in the same way and for the 
same reasons as TCP MSS. those of us running jumbograms or still running FDDI 
or perhaps speaking POS should not be artificially limited in our DNS payload 
sizes.

in discussion, the following details appeared:

TCP MSS is calculated from the routing table. on microsoft windows, there's an 
easy way to find the route for a destination...

https://docs.microsoft.com/en-us/windows/win32/rras/search-for-the-best-route

...and while there's no portable way to do this from user mode in Linux or BSD 
or other UNIX-style systems such as Android, there is always a way.

it is the route's MTU and not any one interface's MTU, and not any constant, 
that should be used to calculate EDNS0 buffer size. that will probably be 1280 
or 1220 for most V6 routes (including "default", the route of last resort) and 
1460 for most V4 routes (including default).

(noting, i've made a similar plea to the QUIC team. the 1500 MTU will not last 
our lifetimes, and we must not hard code the 1500 MTU assumption... anywhere.)

also, there were beer and snacks.

-- 
Paul

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Jul 2019 00:23:12 +0000

one other matter emerged during this discussion. path mtu discovery is dead at 
the moment, for valid security reasons. however, a jumbogram sized campus can 
be described in static routes, using MTU 1500 only for "default". and also, 
any future path mtu discovery functions will, as in the past, simply create 
"host routes" (/32 or /128) to memorialize the MTU known for that host, since 
that is where the TCP MSS computation will expect to find it. so, the lack of 
path mtu discovery in today's networks does not invalidate the method of 
calculating TCP MSS from the route MTU; thus, this should be safe for EDNS 
buffer size as well.

paul

re:

On Thursday, 25 July 2019 00:19:18 UTC Paul Vixie wrote:
> with four of us in attendance monday evening, i presented my appreciation
> for fujimora-san's draft and admitted that EDNS0 ought to have required DF
> and ought to have used examples which would fit in a then-common MTU 1500
> network.
> 
> same reasons as TCP MSS. those of us running jumbograms or still running
> FDDI or perhaps speaking POS should not be artificially limited in our DNS
> payload sizes.
> 
> TCP MSS is calculated from the routing table. on microsoft windows, there's
> an easy way to find the route for a destination...
> 
> ....and while there's no portable way to do this from user mode in Linux or
> BSD or other UNIX-style systems such as Android, there is always a way.
> 
> that should be used to calculate EDNS0 buffer size. that will probably be
> 1280 or 1220 for most V6 routes (including "default", the route of last
> resort) and 1460 for most V4 routes (including default).
> 
> (noting, i've made a similar plea to the QUIC team. the 1500 MTU will not
> last our lifetimes, and we must not hard code the 1500 MTU assumption...
> anywhere.)
> 

-- 
Paul

---

From: william manning <[email-masked]>
Date: Wed, 24 Jul 2019 23:46:48 -0700

sounds like a delightful session with some productive ideas.

On Wed, Jul 24, 2019 at 5:23 PM Paul Vixie <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>