--- Begin Message ---
+1 to running the probes again.
Thanks in advance.
On Wed, Mar 25, 2020 at 7:14 AM Willem Toorop <wil...@nlnetlabs.nl> wrote:
> Op 25-03-2020 om 09:27 schreef Paul Vixie:
> > On Wednesday, 25 March 2020 07:41:51 UTC Petr Špaček wrote:
> >> Hello DNS operators!
> >> ...
> >> Are you a DNS vendor, operator, firewall vendor or service provider and
> >> want
> >> to improve on DNS resilience?
> > yes.
> >> Then ready our guidelines on "Message Size Considerations" for EDNS  to
> >> reduce or even avoid fragmentation of the DNS and please allow DNS over
> >> TCP!
> >>  https://dnsflagday.net/2020/#message-size-considerations
> > from :
> > "An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly all
> > current networks. This is based on an MTU of 1280, which is required by the
> > IPv6 specification, minus 48 bytes for the IPv6 and UDP headers."
> > many of us are successfully using 1400 or larger. the MTU value of 1280 that
> > this calculation is based on, was arbitrarily chosen in the IPv6
> > specification, and no real network operates with this limit. the 48 byte
> > subtrahend was arbitrarily chosen without leaving room for IP6 options. this
> > never matters for TCP because TCP knows the size of the IP6 options that
> > will
> > be used. this in turn never matters because the internet's effective MTU is
> > ~1500.
> Hi Paul,
> I did measure MTU's available to resolvers on RIPE Atlas in June 2013
> and presented results then at RIPE67:
> At that time there were 1029 RIPE Atlas probes, which combined had 863
> IPv6 capable resolvers. 411 of those (51%) had MTU smaller than 1500.
> 115 had an MTU of 1280. On slide 17 of the presentation you can see the
> the different detected MTU's at that time.
> Maybe it's worthwhile to redo those measurements again with the 16000
> IPv6 capable resolvers that we can target on RIPE Atlas right now.
> -- Willem
> > a less-arbitrary value would be better. those of us using 1400 do so because
> > we want to leave room for IP6 options as well as tunnel overhead.
> > please reconsider the further use of the number 1280, which was made
> > deliberately small because of the unrealistic expectation that all IP6 flows
> > would be governed by PMTUD. no real network today operates with this MTU
> > size.
> dns-operations mailing list
--- End Message ---
dns-operations mailing list