[v6ops] Re: [DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

[Paul Vixie <[e-mail]>]

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