[Yeti DNS Discuss] Dealing with IPv6 Fragmentation in the DNS

Paul Vixie paul at redbarn.org
Sun Sep 3 22:19:48 UTC 2017



Geoff Huston wrote:
> ...
>
> The problem is that if you use a low MTU then you need to fragment
> your response if the response is larger than your MTU. The problem is
> that fragmenting the response means that there is a far change (more
> than 1 in 3) that you may be using a recursive resolver that cannot
> receive a fragmented DNS response over IPv6. Google’s public DNS
> service, for example.  ...

i do not believe that google's network, or servers, or dns app, filters 
out the extension headers or icmp messages needed for end-to-end ipv6 
fragmentation and reassembly to work correctly. if they did then this 
would be an easy fix, since google is competent and well-intentioned.

rather, i believe that middleboxes and middlemen (and middlewomen?) are 
keeping google from hearing this signalling. if i'm right, then those 
are the boxes and people that need a clue-by-four upside their heads. we 
watched EDNS deployment stall due to this same rampant cluelessness.

> ... So a low MTU for UDP increases the probability
> of encountering IPv6 fragmentation extension drop. bad.

to the extent that it is in our power to make things worse, we must do 
that. the folks who can't properly exchange the fragmentation signalling 
patterns needed by IPv6 must receive worse service overall, to ensure 
that when complaints come in, they go to the right actors.

so, bad, yes, but for whom and due to whom?

> Increasing the MTU size increases the possibility of encountering a
> Path MTU problem and at this stage you have the tough problem of
> figuring out how to manage an ICMPv6 PTB message and a sessionless
> application that emits UDP. bad.

you say bad, i say necessary evil. what configuration can we recommend 
to IPv6 operators that will maximize the number of fragmentation events 
and timeouts, so as to minimize the service level experienced by the far 
end, in a way that will put pressure on vendors and operators whose 
equipment causes this breakage, as early as possible, as often as possible?

> No clean answers here, but for UDP I would suggest that higher is
> marginally less worse than lower.

in the future, all restaurants will be taco bells. i saw that in a movie 
and it seemed credible, in a humourous kind of way.

and in the future, all internet communication will be via tcp/80.

but... let's resist.

-- 
P Vixie



More information about the discuss mailing list