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 <p...@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....@dmarc.ietf.org>
> >
> > To: v6...@ietf.org, David Farmer <far...@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
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
