[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt
David Farmer <farmer@umn.edu> Mon, 08 July 2024 22:26 UTC
Return-Path: <farmer@umn.edu>
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 374ADC14F6B7 for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2024 15:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 bYhlj7R6bLX7 for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2024 15:26:00 -0700 (PDT)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37B7BC151084 for <dnsop@ietf.org>; Mon, 8 Jul 2024 15:25:59 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 4WHzGt6gWmz9vqNm for <dnsop@ietf.org>; Mon, 8 Jul 2024 22:25:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H74hcB76h0Pa for <dnsop@ietf.org>; Mon, 8 Jul 2024 17:25:58 -0500 (CDT)
Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 4WHzGt1YZvz9vqNg for <dnsop@ietf.org>; Mon, 8 Jul 2024 17:25:58 -0500 (CDT)
DMARC-Filter: OpenDMARC Filter v1.3.2 mta-p7.oit.umn.edu 4WHzGt1YZvz9vqNg
DKIM-Filter: OpenDKIM Filter v2.11.0 mta-p7.oit.umn.edu 4WHzGt1YZvz9vqNg
Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2ee87546e5eso46669091fa.0 for <dnsop@ietf.org>; Mon, 08 Jul 2024 15:25:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; t=1720477555; x=1721082355; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ukvLo4/0atOHAa7d0B7KZ3S/C8FNCTjypjnI1RSRUGE=; b=m1d+1lH6NxrHuYXjdf5iUhCCJtn83xgcJyUjX8Wp0Wc2osj/XXlS3w4jEyvp6H1L1q sWVIo9txM33LWHiKaqyKzWeiyEd6tltMz+PTxOacGd9hnVLYoeH+0zfb3PG/rBJ5P6XV CMvUhZjMc9AzKY29E+blJ1Li2wdKPN48qL+wDKb9WWu33pm1M3GB4hP8JuUS3zMLXF9Y L7Aw6tuTiapR3irCRnR3pxIJjHJk/JNyo8WqMHn31KYeP1PTPd4a8VMhmre6oHyEnPgS XsE7diXcTty7xKK85iZ6N4vCGZuCyYiEfvAvJLg18IfaHaLEiWxeXeS0c/I0ZYE+rmPx ofhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720477555; x=1721082355; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ukvLo4/0atOHAa7d0B7KZ3S/C8FNCTjypjnI1RSRUGE=; b=bWOMNZ0PEUM4d+c0FH5Qyyl+3Y6Vr3fhMo4tWG6YGgwthIo7KgLjLUp3JrbK6usdlx VUPtf+EYVIHFMggb6LLXyTD0ewA9EE+Bpp++tzQaA76fD6atuXP0wK2UAkXs+1AZusaF DwHoFCiLQ27iemIVa9spmWhtwxU0rXfK/hgCYktV0RbiS1s0c/f86fVyR1sJItDOjpkK 0FYR0DzFY44KImLN/dKSLMadwNWMNWUrzwjZaYjhrk7XP/7Zt1NmxOPbLdVbzNP/m3WC 6TOoB/yi8jX0P+5JyfwJqhcq7Yspn2Nu8y6nFhLQYjgABIu0HESMkOVFkNBHUGMIHyTM 5teA==
X-Forwarded-Encrypted: i=1; AJvYcCVtVb3j1kRr9QPhLiD4DAw4eUr/S0T1ECwRn0FxLTXJWhOas/P+biEfFFgyEgWf2i3OmO84rALpQDvyfSAruA==
X-Gm-Message-State: AOJu0YyYi2IJBYJK/3QmwnQszGmi2ym0i5+n8eoiwM3uJjlTpNuCyLU+ lqxvh8L07/4vkSEeihYuoXxeDV7EZocyUB5c+pESmlD8/ly6yjgj2ue5J/hMleYib7w2VS+GODD XKI23N+oWHR0hbV1kfNGxgpxPDHoEHHycLbw759fmOPnhJm1cWSqggU/jBdZ5jVu8UAgTlfIhza aK6+J61DOuU6KVNmbDcDGaVQ==
X-Received: by 2002:a2e:a99f:0:b0:2ee:8817:422b with SMTP id 38308e7fff4ca-2eeb30e39d1mr6915301fa.19.1720477554676; Mon, 08 Jul 2024 15:25:54 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFAyFewh6BRNDeI6I+unwfew9CHK1l9EDLFisP7xgeEHeE39qgBgjFc4lrVi3xQaH/JuUdN5fGCG5+R74z1G/g=
X-Received: by 2002:a2e:a99f:0:b0:2ee:8817:422b with SMTP id 38308e7fff4ca-2eeb30e39d1mr6915201fa.19.1720477554192; Mon, 08 Jul 2024 15:25:54 -0700 (PDT)
MIME-Version: 1.0
References: <13146571.ZYm5mLc6kN@heater.srcl.tisf.net> <CAN-Dau3qqEWpSyjYNUKX++FUGmnk1ZVQjL4O77RVfXP+wOJ=3g@mail.gmail.com> <3365165.44csPzL39Z@heater.srcl.tisf.net>
In-Reply-To: <3365165.44csPzL39Z@heater.srcl.tisf.net>
From: David Farmer <farmer@umn.edu>
Date: Mon, 08 Jul 2024 17:25:37 -0500
Message-ID: <CAN-Dau1a9XdoBxJcVn1+1xSHUacy1R-uSTfKdsdXDXEqdnnfQw@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Content-Type: multipart/alternative; boundary="000000000000764f85061cc3e5e6"
Message-ID-Hash: 65EPMGQP2R52EFKKRF7KBAUD45WUNZVB
X-Message-ID-Hash: 65EPMGQP2R52EFKKRF7KBAUD45WUNZVB
X-MailFrom: farmer@umn.edu
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: v6ops@ietf.org, dnsop@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [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/V4hl3fB8QWWmx7jgcUZRotnMtB4>
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>
Does this resolve the type mismatch? Do you have any other concerns? R3. UDP responders should compose response datagrams whose size does not exceed the requestor's offered buffer size (EDNS bufsize) or, after packetization by the UDP and IP/IPv6 layers, does not exceed the interface MTU, the route MTU, or the path MTU, if they are known. - If the path MTU can be reliably discovered, then such discovery SHOULD be attempted, and the result used. - For IPv6, an interface MTU other than 1500 bytes should be advertised in a Router Advertisement [RFC4861]. - If none of the MTUs are known, a default of 1500 bytes should be assumed. Considering packetization, which might add as many as 100 bytes, the RECOMMENDED buffer size is 1400 bytes. R5. UDP requestors should set the requestor's offered buffer size (EDNS bufsize) to and compose request datagrams whose size, after packetization by the UDP and IP/IPv6 layers, does not exceed the interface MTU, the route MTU, or the path MTU, if they are known. - If the path MTU can be reliably discovered, then such discovery SHOULD be attempted, and the result used. - For IPv6, an interface MTU other than 1500 bytes should be advertised in a Router Advertisement [RFC4861]. - If none of the MTUs are known, a default of 1500 bytes should be assumed. Considering packetization, which might add as many as 100 bytes, the RECOMMENDED buffer size is 1400 bytes. On Sun, Jul 7, 2024 at 8:41 PM Paul Vixie <paul@redbarn.org> wrote: > see inline. > > On Sunday, July 7, 2024 3:55:36 PM PDT David Farmer wrote: > > > Paul, > > > > > > I think this might be a little easier for people to parse, and I think it > > > covers everything in yours; > > that attempt is visible, but there's a fine point it loses. > > > R3. UDP responders should compose response datagrams whose size does not > > > exceed the requestor's offered buffer size (EDNS bufsize) or the > interface > > > MTU, the route MTU, or the path MTU, if any are known. > > a datagram == a udp payload. it is subject to limitation by remote bufsize > or local policy. the estimated or discovered MTU has to be 100 octets > larger than that. so the above paragraph has a type error. so while this > formulation is clearer than mine, it's also incorrect, and as you can see > in my "second try" draft, i think the difference is important. > > re: > > > > > > - If the path MTU can be reliably discovered, then such discovery > SHOULD > > > be attempted, and the result used. > > > - For IPv6, an interface MTU other than 1500 bytes should be > > > advertised in a Router Advertisement [RFC4861]. > > > - If none of the MTUs are known, a default of 1500 bytes should be > > > assumed. Further, the MTU should be reduced to account for > packetization > > > by the UDP and IP/IPv6 layers, which might add as many as 100 bytes, > > > resulting in the RECOMMENDED 1400 Bytes. > > > > > > R5. UDP requestors should set the requestor's offered buffer size (EDNS > > > bufsize) to and compose request datagrams whose size does not exceed the > > > minimum of the interface MTU, the route MTU, or the path MTU, if any are > > > known. > > > > > > > > > - If the path MTU can be reliably discovered, then such discovery > SHOULD > > > be attempted, and the result used. > > > - For IPv6, an interface MTU other than 1500 bytes should be > > > advertised in a Router Advertisement [RFC4861]. > > > - If none of the MTUs are known, a default of 1500 bytes should be > > > assumed. Further, the MTU should be reduced to account for > packetization > > > by the UDP and IP/IPv6 layers, which might add as many as 100 bytes, > > > resulting in the RECOMMENDED 1400 Bytes. > > > > > > What do you think? > > > > > > On Sun, Jul 7, 2024 at 1:19 PM Paul Vixie <paul@redbarn.org> wrote: > > > > 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 > > > > > > > > ----------------------------------------- > > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
- [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