[Yeti DNS Discuss] Dealing with IPv6 Fragmentation in the DNS
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.
More information about the discuss