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

fujiwara@jprs.co.jp Thu, 24 June 2021 10:08 UTC

Return-Path: <fujiwara@jprs.co.jp>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A17533A1546 for <dnsop@ietfa.amsl.com>; Thu, 24 Jun 2021 03:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PrzDOurTjsNC for <dnsop@ietfa.amsl.com>; Thu, 24 Jun 2021 03:07:58 -0700 (PDT)
Received: from off-send41.osa.jprs.co.jp (off-send41.osa.jprs.co.jp [IPv6:2001:218:3001:17::50]) by ietfa.amsl.com (Postfix) with ESMTP id D31B13A09BE for <dnsop@ietf.org>; Thu, 24 Jun 2021 03:07:57 -0700 (PDT)
Received: from off-sendsmg31.osa.jprs.co.jp (off-sendsmg31.osa.jprs.co.jp []) by off-send41.osa.jprs.co.jp (Postfix) with ESMTP id 02EC24058C5 for <dnsop@ietf.org>; Thu, 24 Jun 2021 19:07:55 +0900 (JST)
Received: from off-sendsmg31.osa.jprs.co.jp (localhost []) by postfix.imss91 (Postfix) with ESMTP id E2390602730E for <dnsop@ietf.org>; Thu, 24 Jun 2021 19:07:53 +0900 (JST)
Received: from localhost (off-cpu08.osa.jprs.co.jp []) by off-sendsmg31.osa.jprs.co.jp (Postfix) with ESMTP id D738660270BE for <dnsop@ietf.org>; Thu, 24 Jun 2021 19:07:53 +0900 (JST)
Date: Thu, 24 Jun 2021 19:07:53 +0900 (JST)
Message-Id: <20210624.190753.168308958972133046.fujiwara@jprs.co.jp>
To: dnsop@ietf.org
From: fujiwara@jprs.co.jp
In-Reply-To: <162443885506.9986.7425839137217623053@ietfa.amsl.com>
References: <162443885506.9986.7425839137217623053@ietfa.amsl.com>
X-Mailer: Mew version 6.8 on Emacs 24.5
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--9.267-5.0-31-10
X-imss-scan-details: No--9.267-5.0-31-10
X-TMASE-Version: IMSS-
X-TMASE-Result: 10--9.266600-10.000000
X-TMASE-MatchedRID: sbZa3S7lkwxCXIGdsOwlUh5+URxv1WlBBtG6netTkaUm8HVb/vaoaMyg Al+yObROPf7xVQccaoBaosFST81rS3Irb5Ge0lCi9FQh3flUIh4zb7mBjwZUkbxgMf9QE2ebvCv usD3ui2v+nd34g3pHr/0c1k/nPlUcLgrb1Iou0iksWoJRDvGFzPO5Jn404TbXemFtlEOlo/IpYQ O9By0JCaVctVRU0QJ5ejT+aLsqhrjoNWItALAKTx1kSRHxj+Z5jWP6asaL88XIHdWfR5P9kiGuz VLLKJdOVjrYqVjs7GiBuBbZYT0iAz0A4XbR3uLfOM7ns3UgBY1ztaGkOdQrjZsoi2XrUn/JyeMt MD9QOgCcvwj3ddqeiUme0AhhlKpMZz0AAGWYgqKg5oovEWFmKY6HM5rqDwqtCq8F3ZljnI7mUe7 1dmPXFQCRLUiYUbjOOlo0XsOdBFkth25x79DI7w==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WAGL2YhvGnEgOVz74Rcyd6H0pc4>
Subject: [DNSOP] draft-ietf-dnsop-avoid-fragmentation-05
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jun 2021 10:08:11 -0000

Paul Vixie and I submitted draft-ietf-dnsop-avoid-fragmentation-05.

Please review it.


Major changes are the following:

 1. Moved some text from Introduction to Appendix A. Weaknesses of IP

 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_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
    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 <fujiwara@jprs.co.jp>