Paul Vixie and I submitted draft-ietf-dnsop-avoid-fragmentation-05. Please review it.
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-05 https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-avoid-fragmentation-05 Major changes are the following: 1. Moved some text from Introduction to Appendix A. Weaknesses of IP fragmentation. 2. Section 3.3 Default Maximum DNS/UDP payload size Generated Table 1 Default maximum DNS/UDP payload size 1400 as "Authors' recommendation". Moved details to Appendix B. Details of maximum DNS/UDP payload size discussions. Changed texts about " operators of DNS servers SHOULD measure their path MTU to UDP payload size. the Internet at setting up DNS servers" 3. added "IP_DONTFRAG option" definition in Terminology section. IP_DONTFRAG option is not defined by any RFCs. It is similar to IPV6_DONTFRAG option defined in [RFC3542]. IP_DONTFRAG option is used on BSD systems to set the Don't Fragment bit [RFC0791] when sending IPv4 packets. On Linux systems this is done via IP_MTU_DISCOVER and IP_PMTUDISC_DO. # IP_DONTFRAG is a macro used in BSD socket API. # IPV6_DONTFRAG is defined by RFC 3452, but it is BSD's IPv6 API. # Then, # We may need to change "IP_DONTFRAG" to "DF" bit. ([RFC0791]) # We may need to change "IPV6_DONTFRAG" to "Sending without Fragmentation". # (Good texts required.) # IPv6 experts, please advice. 4. Appendix sections reordered. Appendix A. Weaknesses of IP fragmentation Appendix B. Details of maximum DNS/UDP payload size discussions Appendix C. How to retrieve path MTU value to a destination from applications Appendix D. How to retrieve minimal MTU value to a destination Appendix E. Minimal-responses 5. Added some names in Acknowledgeent section -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
