[dns-operations] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC

[Joe Abley]

On 2010-02-04, at 01:57, Rick Jones wrote:

> Joe Abley wrote:

Actually, I presume Geoff wrote (at least, it wasn't me):

>> Because IPv6 UDP does not support fragmentation in flight, if the path MTU between the server and the DNS client is less than the IPv6 interface MTU at the server, then the server will emit a large UDP packet matching the local interface MTU. This will cause the packet
>> to be dropped at the path MTU bottleneck, and an ICMPv6 "packet too
>> big" response sent back to the server. The server has no remembered
>> state of the original query, and cannot reformat its response. The
>> client will not receive any response to its original query, and will
>> time out. In such a case, the client turning to any other server may
>> not help either. If all servers are delivering the same large
>> response via UDP and there is a path MTU blackhole close to the
>> client, then the client may well have a problem!
> 
> If there is such a "dumbell" (Wide at the ends, narrow in the middle) between the client and the server, that will affect the query carried over TCP as well.  Ditto with IPv4.

With IPv4, if we assume that DF is not set, fragmentation is done by intermediate routers in the path. There is no state required on the sending host for fragmentation to happen.

With conventional, non-Geoff TCP and in the absence of anycast there is state retained for the response, and so it is possible to react to an ICMPv6 packet too big that you receive due to a path MTU that is lower than your sending interface MTU. (With anycast there's the possibility that the ICMPv6 message will arrive back on the wrong host.)

On L-Root we have manually configured an outbound path MTU of 1280 in an attempt to force response packets larger than that to be fragmented by the sending host all the time, since we don't believe we can reliably perform that fragmentation opportunistically.


Joe