Fujiwara-san, On Sep 22, 2022, at 11:05, Kazunori Fujiwara <fujiw...@jprs.co.jp> wrote:
> Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and > they often don't work as expected. > > However, it may be easy to avoid using the Fragment Header on IPv6. > (limit IPv6 response packet smaller than interaface MTU.) > (Or, is it not easy ?) I think it's easier if we just recommend a maximum message size for UDP transport that is likely to avoid truncation in the majority of cases. Perhaps that is the simplest formulation of your ultimate goal? Just update the base specification and say it clearly. This will make UDP transport only usable for a subset of DNS messages that are ever sent on the Internet. Other transports can remain as-is and do not need this limitation. People who ignore the recommendation are on their own. UDP then becomes a convenient choice for DNS messages that are small and that do not have requirements for confidentiality, bit not a default choice in the protocol sense (despite the fact that it will probably remain the choice for most messages). The default transport becomes TCP, since that is the alternative, must-implement transport available in all parts of the system. > Then, to allow larger than 1232/1400 and smaller than interface MTU > response packets, recommendations for UDP requestors are changed as: > > UDP responders can send reponses fit in both > the result of path MTU discovery (if available), > interface MTU and UDP requestor's payload size. I think a formulation to avoid magic numbers is probably better but to be honest I don't find magic numbers to be so terrible if they make the advice more clear. (I think the current draft's advice is not particularly clear since it contains a lot of if then else, but perhaps others think differently.) The DNS is used in private networks as well as on the Internet. I think it's ok to say simply that UDP transport is NOT RECOMMENDED for large messages since fragmentation SHOULD be assumed to be unavailable. That leaves wriggle room for implementations who have more knowledge of their network path or who don't care about delivery failures (for example) to do their own thing. I don't think we should spend too much time imagining what those things should be. >>> 4. TCP implementations SHOULD set DF bit / not use FRAGMENT header. >>> (many TCP implementations already set DF bit) >> >> I doubt we have control over this from the application. Is there even >> API to control that on TCP sockets?m I don't think we should write as if UDP and TCP are the only transports available. I also think it's a mistake to dive down into rabbit holes relating to any particular transport other than UDP. UDP is the only transport we have in which the DNS protocol needs to care about message size. I think the current draft does a good job in restricting its discussion to UDP. > At least, I would like to disable IPv6 fragmentation. > and I would like to make "avoid IPv4 fragmetion" our goal. I think we should just be bold and declare a RECOMMENDED maximum message size when using UDP transport and make TCP the default choice of transport. UDP becomes an acceptable alternative to TCP alongside other transports that might be available, if suitable for a particular message, according to local policy. The maximum that is specified could be a magic number (like the original specification's 512 bytes) or it could be a formulation based on particular address families' minimum capabilities. Clearly some people prefer the latter. The question of how to construct a minimum sized response in cases where a DNS responder really wants to avoid a trip through another transport might ideally live in a separate document. I appreciate that it's a bit late in the process to be suggesting such a change in approach to what is quite a mature document. Sorry about that. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
