Return-Path: 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 EF5E3C151520; Sun, 7 Jul 2024 18:41:29 -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 qdhU5zPr6BfK; Sun, 7 Jul 2024 18:41:26 -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 EBFD2C14F68F; Sun, 7 Jul 2024 18:41:25 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (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 0EB1F19B7B1; Mon, 8 Jul 2024 01:41:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1720402885; bh=/b+LVspgBmh7x4OFQh45VqB3Gi4v/asxgsqQuDZlDd4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=VgilgoPxNSloTThZ3cQ9OB+t9po+Z8aDpHAm2LelzogQgDNcI5Rzz4zg9JsnlAedH x/j6WkQFMcmDBhwCSgU60HtwgwbNnHfYtSHr7PRxY8o5phKerP0GfI+Y7JPp60oAfv cNcrx2KO9Cepy3G0smXrzilG01jYWr+jMxUwkqj0= 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 CD36AC3F22; Mon, 8 Jul 2024 01:41:24 +0000 (UTC) From: Paul Vixie To: David Farmer Date: Sun, 07 Jul 2024 18:41:24 -0700 Message-ID: <3365165.44csPzL39Z@heater.srcl.tisf.net> In-Reply-To: References: <13146571.ZYm5mLc6kN@heater.srcl.tisf.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart8455258.T7Z3S40VBb" Content-Transfer-Encoding: 7Bit Message-ID-Hash: GK3DGSMNX2FTYKILWPKQU4ITXEW6HUSM X-Message-ID-Hash: GK3DGSMNX2FTYKILWPKQU4ITXEW6HUSM 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: v6ops@ietf.org, dnsop@ietf.org X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_=5Bv6ops=5D_Re=3A_Re=3A_Fwd=3A_New_Version_Notif?= =?utf-8?q?ication_-_draft-ietf-dnsop-avoid-fragmentation-18=2Etxt?= List-Id: IETF DNSOP WG mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --nextPart8455258.T7Z3S40VBb Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" see inline. On Sunday, July 7, 2024 3:55:36 PM PDT David Farmer wrote: > Paul, >=20 > 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 =3D=3D a udp payload. it is subject to limitation by remote bufs= ize or local policy.=20 the estimated or discovered MTU has to be 100 octets larger than that. so t= he above=20 paragraph has a type error. so while this formulation is clearer than mine,= it's also=20 incorrect, and as you can see in my "second try" draft, i think the differe= nce is important. re: >=20 > - If the path MTU can be reliably discovered, then such discovery SHOU= LD > 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 packetizati= on > by the UDP and IP/IPv6 layers, which might add as many as 100 bytes, > resulting in the RECOMMENDED 1400 Bytes. >=20 > 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. >=20 >=20 > - If the path MTU can be reliably discovered, then such discovery SHOU= LD > 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 packetizati= on > by the UDP and IP/IPv6 layers, which might add as many as 100 bytes, > resulting in the RECOMMENDED 1400 Bytes. >=20 > What do you think? >=20 > On Sun, Jul 7, 2024 at 1:19=E2=80=AFPM Paul Vixie wrot= e: > > 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: > >=20 > >=20 > > R3. UDP responders should compose response datagrams whose size does not > >=20 > > exceed either the policy maximum if specified, or the requestor's offer= ed > > buffer > >=20 > > size (EDNS bufsize), and will not after packetization by the UDP and > > IP/IP6 > >=20 > > layers (which might add as many as 100 octets) not exceed the predicted > > end- > >=20 > > to-end network MTU for the path to the requester. Neither the interface > > MTU if > >=20 > > known, or the route MTU if known, or the path MTU if known, shall be > > exceeded. > >=20 > > If neither the route MTU or path MTU are known, a default of 1500 should > > be > >=20 > > assumed. If interface, route, or path MTU can be reliably discovered, t= hen > >=20 > > such discovery SHOULD be attempted. Absent such knowledge, the lower of > >=20 > > requester's offered buffer size (EDNS), or 1400, will be the maximum > > datagram size for that response. The recommended 1400 value is simply 1= 500 > > (default MTU) minus 100 (room for transport and network headers) and th= ese > > values may be revised in the future. > >=20 > > If something like this can work, then something like it would have to a= lso > > be done for R5. > >=20 > > -- > >=20 > > P Vixie > >=20 > > ---------- Forwarded Message ---------- > >=20 > > Subject: [v6ops] Re: [DNSOP] Re: Fwd: New Version Notification - > > draft-ietf-dnsop-avoid-fragmentation-18.txt > >=20 > > Date: Saturday, July 6, 2024, 7:35:11 PM PDT > >=20 > > From: Paul Vixie > >=20 > > To: v6ops@ietf.org, David Farmer > >=20 > > On Friday, July 5, 2024 12:48:18 PM PDT David Farmer wrote: > > > Paul and Tim, > > >=20 > > >=20 > > >=20 > > > Would this fit the bill? > >=20 > > i don't think so, but it's a step in the right direction. we should not > >=20 > > mention PLPMTUD since it's considered controversial in the here and now, > > and --nextPart8455258.T7Z3S40VBb Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

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 doe= s not

>= ; exceed the requestor's offered buffer size (EDNS bufsize) or the interfac= e

>= ; MTU, the route MTU, or the path MTU, if any are known.


a datagram =3D=3D a udp payload. it is subject to limitation by remote b= ufsize or local policy. the estimated or discovered MTU has to be 100 octet= s 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 i= n 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 shou= ld be

>= ;    advertised in a Router Advertisement [RFC4861].

>= ;    - If none of the MTUs are known, a default of 1500 byte= s 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<= /p>

>= ; minimum of the interface MTU, the route MTU, or the path MTU, if any are<= /p>

>= ; 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 shou= ld be

>= ;    advertised in a Router Advertisement [RFC4861].

>= ;    - If none of the MTUs are known, a default of 1500 byte= s 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=E2=80=AFPM Paul Vixie <paul@redbarn.org>= ; wrote:

>= ; > Looks like the second WG mailing list fell off of this thread. See b= elow

>= ; > 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 of= fered

>= ; > 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 predic= ted

>= ; > end-

>= ; >

>= ; > to-end network MTU for the path to the requester. Neither the interf= ace

>= ; > 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 sh= ould

>= ; > 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 simpl= y 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 t= o 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=3D40redbarn.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 knowledg= e 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.)<= /p>

>= ; >

>= ; > R3. UDP responders should compose response datagrams whose size does= not

>= ; >

>= ; > exceed either the policy maximum if specified, or the requestor's of= fered

>= ; > 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 predic= ted

>= ; > end-

>= ; >

>= ; > to-end network MTU for the path to the requester. Neither the interf= ace

>= ; > 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 sh= ould

>= ; > be

>= ; >

>= ; > assumed. If interface, route, or path MTU can be reliably discovered= , then

>= ; >

>= ; > such discovery SHOULD be attempted. Absent such knowledge, either th= e

>= ; >

>= ; > requester's offered buffer size, or 1400 if lower, will be the effec= tive

>= ; > 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 th= e

>= ; > future.

>= ; >

>= ; > > R5. UDP requestors should set the requestor's maximum UDP paylo= ad size

>= ; > >

>= ; > > [RFC6891] to the RECOMMENDED maximum DNS/UDP payload size of 14= 00 bytes

>= ; > >

>= ; > > unless the interface MTU or the network MTU is known to be smal= ler or a

>= ; > >

>= ; > > different Path MTU value that is known to function without enco= untering

>= ; > >

>= ; > > fragmentation, as determined by PLPMTUD [RFC 8899] or some othe= r future

>= ; > >

>= ; > > mechanism. (See Appendix A for more information.)

>= ; >

>= ; > i'd like to see this revised similarly to my example above, if you a= gree.

>= ; >

>= ; > --

>= ; >

>= ; > P Vixie

>= ; >

>= ; >

>= ; > _______________________________________________

>= ; >

>= ; > v6ops mailing list -- v6ops@ietf.org

>= ; >

>= ; > To unsubscribe send an email to v6ops-leave@ietf.org

>= ; >

>= ; > -----------------------------------------



--nextPart8455258.T7Z3S40VBb--