Turn off IPV6_USE_MIN_MTU?

João Damas joao at bondis.org
Tue May 31 13:47:03 UTC 2016


> On 31 May 2016, at 13:32, Mark Andrews <marka at isc.org> wrote:
> In message <20160531161631.7ca7f650 at pallas.home.time-travellers.org <mailto:20160531161631.7ca7f650 at pallas.home.time-travellers.org>>, Shane Kerr writes:
>> Hello,
>> Geoff Huston has done some work recently looking at IPv6 fragmentation,
>> and there seem to be a number of cases where IPv6 fragments do not
>> work:
>> https://ripe72.ripe.net/archives/video/164/
>> (The link says "video" but there are also slides there.)
>> This is likely because of middleboxes; if you want to do deep-packet
>> inspection, you need to look at the reassembled packets, which mean
>> additional state and processing for the boxes. A simpler solution is
>> just to disable IPv6 fragments, since TCP doesn't need it and UDP is
>> unreliable anyway. :-P
> UDP is reliable if you don't have idiots breaking the protocol by
> dropping fragments.


>  Additionally DPI is going away as more and
> more traffic is encrypted.  


> Just because you can DPI something
> doesn't mean that you should.

Agreed, no only for this case.

Now… with that baseline established, there is a fact that Shane pointed out that I think should be the overriding argument:

measurements of reality indicate that using larger packets, stuffing as much data as possible into the UDP packet, in a world that overwhelmingly uses 1500(-tunnel) as its MTU, increases the chances of success of the communication.
if you remember, the 1280 magic number comes from pure gut-feeling on the side of the RFC author/editor, not hard evidence.

Please consider adoption of the change that Shane suggests as it will increase the chances of DNS lookups succeeding and we can continue to educate people about DPI, broken firewall rules, etc while getting the DNS to work better over UDP/IPv6

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-workers/attachments/20160531/d5857ef2/attachment.html>

More information about the bind-workers mailing list