[DNSOP] draft-ietf-dnsop-avoid-fragmentation-05

[[e-mail]]

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 <[e-mail]>