> From: Peter van Dijk <peter.van.d...@powerdns.com> > Avoiding fragmentation is good. Putting that in a document is also good. > But this document is not ready for publication. It also most definitely > does not describe Best Current Practice; it also does not prescribe a > Best Current Practice I can agree with or even really implement. > > I'll call out a few specific problems below, but this list is not > complete. > > The (normative!) reference to RFC8900 is very vague.
I will change informative reference to RFC8900. > The IP_DONTFRAG reference (well, not really a reference) is handwavy and > ill-defined. The discussion of socket options is also incomplete. (See > also: Petr's email) > (That said, the advice is good.) I would like to change IP_DONTFRAG/IPV6_DONTFRAG related description as follows. If there is a better text, please suggest. | 2.1 "Don't Fragment" way | | In this document, the term "Don't Fragment" way | implies | to set "Don't Fragment flag (DF) bit" [RFC0791] on IPv4 | and not to use "Fragment header" [RFC8200] on IPv6. | | How to set "Don't Fragment flag (DF) bit" on IPv4 varies between | implementations, IP_DONTFRAG option is used on BSD systems to set | the Don't Fragment bit. On Linux systems this is done via | IP_MTU_DISCOVER and IP_PMTUDISC_DO. | | The way without "Fragment header" on IPv6 varies between | implementations. On BSD systems, use IPV6_DONTFRAG socket option | defined in [RFC3542]. | | 3.1. Recommendations for UDP responders - * UDP responders SHOULD send DNS responses with IP_DONTFRAG / - IPV6_DONTFRAG [RFC3542] options. + * UDP requestors SHOULD send DNS requests with "Don't Fragment" way. >> * UDP responders MAY probe to discover the real MTU value per >> destination. > > I have no clue how a responder would do this. If I'm wrong, and this is > possible at all, the document should explain how this would be done. The third and forth paragraphs may be merged, I think. > I assume section 3.2 means the EDNS bufsize in the request when it says > "their payload size", but I am not sure. The text could be clearer on > that. > >> * UDP requestors MAY probe to discover the real MTU value per >> destination. > > How? For example, recent BIND 9 starts small EDNS requestors maxiumum DNS/UDP payload size (512), and increases gradually. Do you have good text ? >> To avoid name resolution fails, UDP requestors need to retry using >> TCP, or UDP with smaller maximum DNS/UDP payload size. > > This lacks 2119/8174 keywords. "need" sounds like SHOULD or MUST, but I > do not think this behaviour should be mandated of implementations. > Several resolver implementations currently do none of this, and they work > fine on the existing Internet. We should not be adding code compensating > for potential breakage we can imagine. So, I suggest this would at most > be a MAY, or a lowercase "can retry using ...". Ok, change to "MAY". >> The proposed method supports incremental deployment. > > In its current shape, this document does not really propose a method for > anything. If the document gets updated to provide implementable advice, > it should get an Implementation Status section. Thanks. Section 4 Incremental deployment may be removed. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > Section 5 is solid advice. > > I also agree with the full text of Petr's response. > > Kind regards, > -- > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
