> From: Tony Finch <d...@dotat.at>
> I've had a look through and I have a few comments.

Thanks.

> Regarding smallest MTUs, I understand from Geoff Huston that it's common
> for IPv6 breakage to start at 1281 bytes.

Then, without path MTU discovery, IPv6 default path MTU value should
equal to the IPv6 minimum link MTU size 1280.

How about IPv4 ?

> I would find it easier to understand the recommendations if the
> requirements for responder and requester were separated. In particular I
> don't know how a responder can do MTU discovery (though a simplified
> version might be possible).

Then, separate real recommendations to "3.1 Recommendations for UDP
requestors" and "3.2 Recommendations for UDP responders".

> Here's my understanding of your recommendations:
> 
> Requester:
> 
> * should have a default EDNS buffer size no more than 1500 bytes (smaller
>   than the 4096 that is currently typical, but bigger than the flag day
>   recommendation)
> 
> * should probe to discover the real MTU per destination, which can be less
>   than the default, and use the discovered MTU for the EDNS buffer size in
>   queries (resolvers already do this)

In my opinion, if path MTU discovery to works, then use the value
(minus header sizes) as Requestor's Payload Size in EDNS0.
Otherwise, use "good" default EDNS buffer size (for example, 1232).

> * at the moment UDP timeouts don't cause fallback to TCP, but this should
>   be added to the list of recovery tactics
>
> * requesters are supposed to guess (how?) the size of response before
>   sending a query, so that they can skip UDP and go straight to TCP

If requestors set good EDNS Requestor's Payload size,
responders can set TC bit if response size exceeds the EDNS0 size.
(Otherwise, fragmented responses may lose.)

> * should set the DONTFRAG option, though it's unlikely they are sending
>   a query big enough for this to matter. (UPDATE clients need to care,
>   though.)
> 
> Responder:
> 
> * should have a default UDP response size limit of no more than 1500 bytes
>   (smaller than the 4096 that is currently typical, but bigger than the
>   flag day recommendation)

To avoid packet loss caused by IP_DONTFRAG, if responders know real
path MTU value, responders compose packets fit in the path MTU.

Otherwise, at least, IP_DONTFRAG works well.

I think that most of DNS servers are located at 1500-octets MTU area.

> * should limit response sizes by based on the minimum of the request's
>   EDNS buffer size and the server's limit (servers already do this)

If operators of DNS servers know that the network does not support
1500-octet MTU, operators should consider good UDP response size
limit.

> * should use minimal responses
> 
> * should set the DONTFRAG option on responses

And responders should set TC=1 (and re-compose smaller response)
if sendto returned EMSGSIZE.

> * should listen for ICMP frag needed packets, and react by re-sending the
>   response (which is embedded in the ICMP packet) with a TC bit set

It is a part of path MTU discovery.

> Network:
> 
> * should send rate-limited ICMP frag needed messages to DNS servers when
>   appropriate

I don't know.

--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to