[Int-area] Please review draft-ietf-dnsop-avoid-fragmentation

Kazunori Fujiwara <fujiwara@jprs.co.jp> Fri, 29 July 2022 12:12 UTC

Return-Path: <fujiwara@jprs.co.jp>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F0EC1C50EA; Fri, 29 Jul 2022 05:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_zdkKrtjwUv; Fri, 29 Jul 2022 05:12:43 -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 5A356C16ECE8; Fri, 29 Jul 2022 05:12:40 -0700 (PDT)
Received: from off-sendsmg31.osa.jprs.co.jp (off-sendsmg31.osa.jprs.co.jp [172.23.8.161]) by off-send41.osa.jprs.co.jp (Postfix) with ESMTP id 402D2402F6D; Fri, 29 Jul 2022 21:12:38 +0900 (JST)
Received: from off-sendsmg31.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss91 (Postfix) with ESMTP id B6576602759A; Fri, 29 Jul 2022 21:12:36 +0900 (JST)
Received: from localhost (off-cpu08.osa.jprs.co.jp [172.23.4.18]) by off-sendsmg31.osa.jprs.co.jp (Postfix) with ESMTP id A75DF602758F; Fri, 29 Jul 2022 21:12:36 +0900 (JST)
Date: Fri, 29 Jul 2022 21:12:36 +0900
Message-Id: <20220729.211236.1112281904300036081.fujiwara@jprs.co.jp>
To: int-area@ietf.org
CC: dnsop@ietf.org
From: Kazunori Fujiwara <fujiwara@jprs.co.jp>
X-Mailer: Mew version 6.8 on Emacs 24.5.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSS-9.1.0.1373-9.0.0.1002-27044.007
X-TM-AS-Result: No--7.039-5.0-31-10
X-imss-scan-details: No--7.039-5.0-31-10
X-TMASE-Version: IMSS-9.1.0.1373-9.0.1002-27044.007
X-TMASE-Result: 10--7.039100-10.000000
X-TMASE-MatchedRID: 3RAVi5XHW/RCXIGdsOwlUh5+URxv1WlB/czC/snTsNcxkLdkW7C5qlKC SV79Dbqw6rOV4DPw+1zbHSmBaTg05Ix8jP90278eGhRbJzT/dqM1TzP60UkdHabGGv9dC9UcpC0 eXDBJ89Fr/wFZWHKkUF/dL3tcOQuKDDMqyfSlsoRrzsINdopFUlwp6KDoOP25ReOJg/1Upn0Xn0 fuBWX+3WB2fKOLUt198eh+/X9EWdqnbZwEx097TZ4CIKY/Hg3AtOt1ofVlaoK41AzfZSSK8nnhQ EB6FTWSbxc8rwAf4o7dB/CxWTRRu25FeHtsUoHuK/jc74rnS/Qbz4scs6YDpOe3uoXkhgzPE1tR 7UGHxvFLhb8xGEnVfg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/NCSeuj6kz4HzRQh9g0vWYLLlY1Y>
Subject: [Int-area] Please review draft-ietf-dnsop-avoid-fragmentation
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2022 12:12:47 -0000

Dear intarea WG,

dnsop WG is working on a document to avoid IP fragmentation in DNS.
Now, the draft is on Working Group Last call in dnsop WG (until August 16).

The draft attempt to advance the goals of RFC 8900 IP Fragmentation
Considered Fragile. (Section 5.1 Domain Name System (DNS))

As one of the co-authors of the draft, I would like advices from
intarea because there may be inadequate descriptions related to path
MTU discovery and DF bit / IPV6_DONTFRAG.

Fragmentation Avoidance in DNS
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/


(1) About DF bit, IPV6DONTFRAG

| 1.  Introduction
|
|  This document proposes to set IP_DONTFRAG / IPV6_DONTFRAG in DNS/UDP
|  messages in order to avoid IP fragmentation, and describes how to
|  avoid packet losses due to IP_DONTFRAG / IPV6_DONTFRAG.

| 2.  Terminology
| 
|  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.

| 3.1.  Recommendations for UDP responders
|
|  *  UDP responders SHOULD send DNS responses with IP_DONTFRAG /
|     IPV6_DONTFRAG [RFC3542] options.

(2) about path MTU discovery

| 2.  Terminology
|
|  "Path MTU" is the minimum link MTU of all the links in a path between
|  a source node and a destination node.  (Quoted from [RFC8201])
|
|  In this document, the term "Path MTU discovery" includes Classical
|  Path MTU discovery [RFC1191], [RFC8201], Packetization Layer Path MTU
|  discovery [RFC8899] and as well as similar methods.

| 3.2.  Recommendations for UDP requestors
|
|  *  UDP requestors MAY probe to discover the real MTU value per
|     destination.  (Path MTU discovery per destionation) Then,
|     calculate their maximum DNS/UDP payload size as the reported path
|     MTU minus IPv4/IPv6 header size (20 or 40) minus UDP header size
|     (8).  If the path MTU discovery failed or is impossible, use the
|     default maximum DNS/UDP payload size 1400.

------------

Regards

--
Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>