[DNSOP] Fwd: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt
Paul Vixie <paul@redbarn.org> Sun, 07 July 2024 18:19 UTC
Return-Path: <paul@redbarn.org>
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 F054AC14F61D; Sun, 7 Jul 2024 11:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.org
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 QI6loanpsiiD; Sun, 7 Jul 2024 11:19:56 -0700 (PDT)
Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05A8C14F61C; Sun, 7 Jul 2024 11:19:55 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.redbarn.org", Issuer "RapidSSL TLS RSA CA G1" (not verified)) by util.redbarn.org (Postfix) with ESMTPS id 1421619B7B1; Sun, 7 Jul 2024 18:19:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1720376395; bh=BTfl+n2SWtfiyFQ3DfGpr2CIyGK5fMNXlci+BTF3DCE=; h=From:To:Cc:Subject:Date; b=RqVtDOxN/ozT6afIkCxdHOrjMlRKBw9KbVzipACOj0xWGc9qYfborq0anNFQOSKrI 6Ii1VYuWhl4LMMWDxCOsKiYB3S+GTTathdAefmOFOgF/WIhaf0X60KxGB1F/1/mENb 8EUIyNwMepLw20MpYHwvHh8hQd39eH4kknXceXcI=
Received: from heater.srcl.tisf.net (heater.srcl.tisf.net [IPv6:2001:559:8000:cc::111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPS id D1673C3F22; Sun, 7 Jul 2024 18:19:54 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: v6ops@ietf.org, dnsop@ietf.org
Date: Sun, 07 Jul 2024 11:19:54 -0700
Message-ID: <13146571.ZYm5mLc6kN@heater.srcl.tisf.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart6202331.2l3rmUXbR5"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: RPVGGDBLYKRFLVDMOMNMWKXMBMK63KXB
X-Message-ID-Hash: RPVGGDBLYKRFLVDMOMNMWKXMBMK63KXB
X-MailFrom: paul@redbarn.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: David Farmer <farmer@umn.edu>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Fwd: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PKFh1acVQ8umYKwk3RbbM1FZIPw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
Looks like the second WG mailing list fell off of this thread. See below for history. I realize that the text I proposed to Mr. Farmer was incoherent, so here's a second try: R3. UDP responders should compose response datagrams whose size does not exceed either the policy maximum if specified, or the requestor's offered buffer size (EDNS bufsize), and will not after packetization by the UDP and IP/IP6 layers (which might add as many as 100 octets) not exceed the predicted end- to-end network MTU for the path to the requester. Neither the interface MTU if known, or the route MTU if known, or the path MTU if known, shall be exceeded. If neither the route MTU or path MTU are known, a default of 1500 should be assumed. If interface, route, or path MTU can be reliably discovered, then such discovery SHOULD be attempted. Absent such knowledge, the lower of requester's offered buffer size (EDNS), or 1400, will be the maximum datagram size for that response. The recommended 1400 value is simply 1500 (default MTU) minus 100 (room for transport and network headers) and these values may be revised in the future. If something like this can work, then something like it would have to also be done for R5. -- P Vixie ---------- Forwarded Message ---------- Subject: [v6ops] Re: [DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid- fragmentation-18.txt Date: Saturday, July 6, 2024, 7:35:11 PM PDT From: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org> To: v6ops@ietf.org, David Farmer <farmer@umn.edu> On Friday, July 5, 2024 12:48:18 PM PDT David Farmer wrote: > Paul and Tim, > > Would this fit the bill? i don't think so, but it's a step in the right direction. we should not mention PLPMTUD since it's considered controversial in the here and now, and there's no need to be provocative. > R3. UDP responders should compose response packets that fit in the minimum > of the offered requestor's maximum UDP payload size [RFC6891], the > interface MTU, the network MTU value configured by the knowledge of the > network operators, and the RECOMMENDED maximum DNS/UDP payload size of 1400 > bytes, or a different Path MTU value that is known to function without > encountering fragmentation, as determined by PLPMTUD [RFC 8899] or some > other future mechanism. (See Appendix A for more information.) R3. UDP responders should compose response datagrams whose size does not exceed either the policy maximum if specified, or the requestor's offered buffer size (EDNS bufsize), and will not after packetization by the UDP and IP/IP6 layers (which might add as many as 100 octets) not exceed the predicted end- to-end network MTU for the path to the requester. Neither the interface MTU if known, or the route MTU if known, or the path MTU if known, shall be exceeded. If neither the route MTU or path MTU are known, a default of 1500 should be assumed. If interface, route, or path MTU can be reliably discovered, then such discovery SHOULD be attempted. Absent such knowledge, either the requester's offered buffer size, or 1400 if lower, will be the effective maximum datagram size. The 1400 value is simply 1500 (default MTU) minus 100 (room for transport and network headers) and these values may be revised in the future. > R5. UDP requestors should set the requestor's maximum UDP payload size > [RFC6891] to the RECOMMENDED maximum DNS/UDP payload size of 1400 bytes > unless the interface MTU or the network MTU is known to be smaller or a > different Path MTU value that is known to function without encountering > fragmentation, as determined by PLPMTUD [RFC 8899] or some other future > mechanism. (See Appendix A for more information.) i'd like to see this revised similarly to my example above, if you agree. -- P Vixie _______________________________________________ v6ops mailing list -- v6ops@ietf.org To unsubscribe send an email to v6ops-leave@ietf.org -----------------------------------------
- [DNSOP] Fwd: [v6ops] Re: Re: Fwd: New Version Not… Paul Vixie
- [DNSOP] Fwd: New Version Notification - draft-iet… Tim Wicinski
- [DNSOP] Re: [v6ops] Fwd: New Version Notification… David Farmer
- [DNSOP] Re: Fwd: New Version Notification - draft… Petr Špaček
- [DNSOP] Re: Fwd: New Version Notification - draft… Tim Wicinski
- [DNSOP] Re: [v6ops] Re: Fwd: New Version Notifica… Paul Vixie
- [DNSOP] Re: [v6ops] Re: Fwd: New Version Notifica… Tim Wicinski
- [DNSOP] Re: [v6ops] Re: Fwd: New Version Notifica… Tim Wicinski
- [DNSOP] Re: [v6ops] Re: Fwd: New Version Notifica… Geoff Huston
- [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Noti… Paul Vixie
- [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Noti… Nick Hilliard
- [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Noti… Paul Wouters
- [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Noti… Petr Špaček
- [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Noti… Paul Wouters
- [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Noti… Jared Mauch
- [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Noti… David Farmer
- [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Noti… Paul Vixie
- [DNSOP] Re: [v6ops] Fwd: New Version Notification… Tim Wicinski
- [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Noti… Philip Homburg
- [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Noti… Petr Špaček
- [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Noti… David Farmer