(Top-reply, apologies for those offended by this practice.)
I also oppose adoption (at least of the draft in its current form).
Very quick questions:
(1) Has your testing revealed *where* the IPv6 fragmentation is occurring?
IIRC, IPv6 requires the originating host to do so. And originating UDP
packet size will be the smaller of the authority servers' configs and the
EDNS bufsize on the request.
(2) Have you experimented with setting EDNS0 UDP bufsize to the *actual max
size* that IPv6 allows *without fragmenting* (or MTU?), and what happens
when you do that? (Actual MTU may vary topologically, YMMV, etc.)
My suspicion is that the better approach for resolvers might actually be to
do their IPv6 stuff "better", for some value of "better", in a way that
does not require DNS protocol changes (or changes to transport specs like
UDP or IPv6).
Or maybe we could add a new edns0 ip6-bufsize option in future so v4 vs v6
limits can be separated (and thus standardize (and kind of simplify)
resolver and auth server configs).
Please experiment a bit and let us know the results.
Brian
On Tue, Jan 22, 2019 at 12:50 AM Davey Song(宋林健) wrote:
> Thanks for all commenter's, I appreciate your frankness and vote based on
> your technical sense. I understand your push back especially considering
> the DNS camel stuff. I try to reply some of comments here.
>
> Some people argues on the problem statement of this draft.
>
> > Peter: Meanwhile, we have no indication that the draft solves any
> existing real world problem in a useful way.
>
> > Petr Špaček : Solving rare operational problem with a huge and ugly hack
> is no-go territory for Knot Resolver project.
>
> It is not rare. It is just under the water. You cannot run a ship unaware
> of it, especially towards IPv6-only future. Here are some pointer and
> number are given:
>
> [1] presents a 28.26% ~ 55.23% packets drop rate for IPv6 fragements. [2]
> reports 10% of the paths between the vantage points and the experimental
> setup filter IP fragments. [3] reports 37.45% of endpoints used
> IPv6-capable DNS resolvers that were incapable of receiving a fragmented
> IPv6 response. [4] Yeti testbed also observed over 7% failure rate for
> queries against IPv6-only server during KSK rollover using 100 probes. [5]
> is a IETF workgroup document of this problem. It is **not** a rare
> operational problem.
>
> > Ralf Weber: Having one v6 name server that will respond correct with
> fragments also solves the problem. I think the problem space is to narrow
> to burden this problem on all resolvers.
>
> Now 389 of v6 tld server including .org reply with large packets, please
> check [Appendix]. I'm not sure how they can respond correct currently when
> they need to add more content in answer section. I'm told that a few large
> DNS operator using certain DNSSEC tool generating a large DNSKEY RRset and
> RRSIG RRset.
>
> > [Most importantly we need to get an explanation why Geoff's experiments
> > show problems but clients can in practice resolve org. DNSKEY just fine..]
>
> Network operation issues are hidden from the sense of application layer.
> The impact introduced by IPv6 fragments dropping is hidden by different
> layer of redundancy. From users perspective, dualstack applications run
> Happy eyeballs willl hide IPv6 networking issues from themselves and
> network operator. From DNS perspective, resolvers can retry, mostly likely
> fallback to TCP , without TCP they finally fallback to IPv4 to deliver
> record ! If we leave this issue along, I bet the dual-stack period will
> last much longer than expect.
>
> There is a separate thread in ORAC mailing list on " How .org name server
> handle large DNS response?". I'm looking forward to the response from org..
> DNS people. I expect some data and analysis not only emotion. I'm wondering
> there is difference in the query pattern (in terms of UDP/TCP ratio,
> IPv4/IPv6 ratio etc. ) between small response and large response .
>
> [1] RFC7872, Observations on the Dropping of Packets with IPv6 Extension
> Headers in the Real World, https://tools.ietf.org/html/rfc7872
> [2] De Boer, M. and J. Bosma, "Discovering Path MTU black holes on the
> Internet using RIPE Atlas", July 2012, <
> http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf
> >.
> [3] APNIC measurement study,
> https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/
> [4] RFC8483 Yeti DNS testbed https://tools.ietf.org/html/rfc8483
> [5] IP Fragmentation Considered Fragile,
> https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-04
> [Appendix] 389 TLD's response for dnsky with RRSIG larger than 1500 (msg
> size + 48)
>
>
> #389 TLD's response packet for dnsky with RRSIG are larger than 1500
> (msg size + 48)
> sl. 3319
> bg. 3103
> mm. 3063
> si. 2739
> xn--mgbx4cd0ab. 2511
> za. 2455
> best. 2053
> kred. 2053
> ceo.2051
> americanexpress.2006
> bananarepublic. 2003
>
