[DNSOP] draft-fujiwara-dnsop-avoid-fragmentation-03.txt

fujiwara@jprs.co.jp Mon, 13 April 2020 09:01 UTC

Return-Path: <fujiwara@jprs.co.jp>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91413A122F for <dnsop@ietfa.amsl.com>; Mon, 13 Apr 2020 02:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYYOCYI7QYIE for <dnsop@ietfa.amsl.com>; Mon, 13 Apr 2020 02:01:50 -0700 (PDT)
Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DDD3A122E for <dnsop@ietf.org>; Mon, 13 Apr 2020 02:01:48 -0700 (PDT)
Received: from off-sendsmg31.osa.jprs.co.jp (off-sendsmg31.osa.jprs.co.jp [172.23.8.161]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id 03D91lc7013339 for <dnsop@ietf.org>; Mon, 13 Apr 2020 18:01:47 +0900
Received: from off-sendsmg31.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss91 (Postfix) with ESMTP id EA1A96028C84 for <dnsop@ietf.org>; Mon, 13 Apr 2020 18:01:45 +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 D56B160284D4 for <dnsop@ietf.org>; Mon, 13 Apr 2020 18:01:45 +0900 (JST)
Date: Mon, 13 Apr 2020 18:01:45 +0900
Message-Id: <20200413.180145.2021663541328289720.fujiwara@jprs.co.jp>
to: dnsop@ietf.org
From: fujiwara@jprs.co.jp
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-GCONF: 00
X-TM-AS-Product-Ver: IMSS-9.1.0.1231-8.2.0.1013-25352.005
X-TM-AS-Result: No--17.039-5.0-31-10
X-imss-scan-details: No--17.039-5.0-31-10
X-TMASE-Version: IMSS-9.1.0.1231-8.2.1013-25352.005
X-TMASE-Result: 10--17.039200-10.000000
X-TMASE-MatchedRID: e01xcIcDidBCXIGdsOwlUmmpWpGzPzJdZggZX8gYmrW9eNsTtvBD3mc6 FiBin4LddZ7fu9NDAa5ztfyJonoYMSDDYPyuSHGfT3nBCKOvAEt9m5tDcb5SYRQUOSCpbPwOVQU 8VbWsRfgTW3f589Qq37tCCJ8Cv8fxxB4g7OBWY2xO7YI53bP1ZTVPM/rRSR0dGUs9b7xvtJozy+ CKVy54HoYPzHvoX0gUm2P6wJVvGubQDjdxmODVASfphWrcxCwj4NNiN6MhlPBa1yhTwm1zuXMCl s199RV9P4rDRbEExRvqRiUgB0CArE6cZmu8CZmK48SQ1JLtjzZzHsCOuSqn1oPLx3vY4vNitFbV LrqTerTfWs89M0W8hFaELS2YjCQ6nySqCTVRfyRJPklCNaEkBmPSZS8C9XYNr3DiW2de5g/YTyK JpFE3VOLzNWBegCW2XC3N7C7Yzreq8gvEUudt+Gc9AABlmIKioOaKLxFhZimOhzOa6g8KrZRMZU CEHkRt
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/djOcNA3MISrgvg5s8Bq8KbCmfWY>
Subject: [DNSOP] draft-fujiwara-dnsop-avoid-fragmentation-03.txt
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: Mon, 13 Apr 2020 09:01:52 -0000

Hello,

Paul Vixie and I submitted draft-fujiwara-dnsop-avoid-fragmentation-03.txt

Please review it.

Changes from 01 to 03 are:
- Changed title as Fragmentation Avoidance in DNS
- Refer draft-ietf-intarea-frag-fragile
- Fixed:  Minimum MTU forIPv4 is 68 (from 576)
- Added: DNS flag day 2020 proposed 1232 as an EDNS buffer size.
- Added: 'minimal-responses' configuration
- Added: consideration of DNS packet size
- Added: How to measure path MTU and calculate maximum DNS/UDP payload size

I think that we may need definition of "minimal-responses".

-----

A new version of I-D, draft-fujiwara-dnsop-avoid-fragmentation-03.txt
has been successfully submitted by Kazunori Fujiwara and posted to the
IETF repository.

Name:		draft-fujiwara-dnsop-avoid-fragmentation
Revision:	03
Title:		Fragmentation Avoidance in DNS
Document date:	2020-04-13
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-avoid-fragmentation-03.txt
Status:         https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/
Htmlized:       https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-avoid-fragmentation
Diff:           https://www.ietf.org/rfcdiff?url2=draft-fujiwara-dnsop-avoid-fragmentation-03

Abstract:
   Path MTU discovery remains widely undeployed due to security issues,
   and IP fragmentation has exposed weaknesses in application protocols.
   Currently, DNS is known to be the largest user of IP fragmentation.
   It is possible to avoid IP fragmentation in DNS by limiting response
   size where possible, and signaling the need to upgrade from UDP to
   TCP transport where necessary.  This document proposes to avoid IP
   fragmentation in DNS.

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