Turn off IPV6_USE_MIN_MTU?

[João Damas]

> On 31 May 2016, at 16:31, Mark Andrews <marka at isc.org> wrote:
> 
> 
> In message <92E4FD9B-12A4-4773-B785-B3AA40F3E6B5 at bondis.org>, =?utf-8?Q?Jo=C3=A3o_Damas?= writes:
>> 
>> Mark,
>> 
>>> 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.
>> 
>> Agreed
>> 
>>> Additionally DPI is going away as more and
>>> more traffic is encrypted.
>> 
>> Perhaps
>> 
>>> 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
>> 
>> Joao
> 
> And if you live behind a tunnel you want the fragmentation @1280.

No you don’t, you want way more than 1280.

> 
> Too many idiots with authoritative servers block PTB messages and
> DNS/UDP doesn't resend automatically on receipt of PTB like TCP
> does.  Even if the site doesn't deliberately block PTB, broken load
> balancer that don't forward PTB corretly, etc. means that you don't
> want to rely on PTB working.  This even impacts DNS/TCP.

true, but 1280 is ridiculously small, not to mentioned pulled right out of someone’s ass (1280 = 1024 + 256 because it looks nice). Tunnels eat way less than 220 bytes for real observed cases.

> 
> You don't need to do reassembly and DPI to let fragmentmented
> responses through.  Just open a slit in the firewall for non initial
> fragment based on <src-addr,dst-addr,proto> along with the full
> tuple for the initial fragement <src-addr,src-port,dst-addr,dst-port,proto>
> and let the host reassemble the packet.  It doesn't have to be all
> fragments.

yep, we all know the theory. I talk to firewall people (vendors and users) and remind them of this each time. You can do the same. Unfortunately some times things are explained in a way that makes the user believe this is all black-magic and it is just easier to disable all the shit and just let port 80 and 443 through (so that’s the way DNS is headed :-(

Joao