Turn off IPV6_USE_MIN_MTU?
Mark Andrews
marka at isc.org
Tue May 31 11:32:34 UTC 2016
In message <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. In reality it doesn't save you. It
just increases your costs. It results in stupidity of firewalls
dropping DNS packet with EDNS options set, EDNS flags being set and
EDNS version fields being set for ZERO benefit. DPI is snake oil.
Mark
ip6:
1834879 total packets received
0 with size smaller than minimum
0 with data size < data length
0 with bad options
0 with incorrect version number
6643 fragments received
0 fragments dropped (dup or out of space)
53 fragments dropped after timeout
0 fragments that exceeded limit
3295 packets reassembled ok
1399135 packets for this host
0 packets forwarded
323493 packets not forwardable
0 redirects sent
1424933 packets sent from this host
0 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
49158 output packets discarded due to no route
2384 output datagrams fragmented
4768 fragments created
0 datagrams that can't be fragmented
56 packets that violated scope rules
323455 multicast packets which we don't join
Input histogram:
hop by hop: 745
TCP: 1322934
UDP: 389988
fragment: 6643
ICMP6: 114557
Mbuf statistics:
521200 one mbuf
two or more mbuf:
lo0= 365456
948223 one ext mbuf
0 two or more ext mbuf
0 packets whose headers are not continuous
0 tunneling packets that can't find gif
0 packets discarded due to too may headers
0 failures of source address selection
0 forward cache hit
0 forward cache miss
0 packets dropped due to no bufs for control data
> Anyway, Geoff's measurement was that 1400 byte packets work the same as
> 1280 byte packets for delivery. He also measured that if you fragment
> larger packets at 1280 then the failure rate goes way up.
>
> The summary seems to be that setting MTU to 1280 decreases the ability
> to deliver packets, rather than increasing it. A simple fix would be to
> stop setting IPV6_USE_MIN_MTU, at least for the UDP case. We live in a
> 1500-byte packet size world (or in the case of IPv6, maybe a 1420-byte
> packet size world, because tunnels).
>
> While I think removing this call the best solution, in keeping with
> BIND 9 tradition maybe making a configurable knob for people who really
> want it is reasonable. Would a patch for this be rejected out of hand
> or should I pursue it?
>
> Cheers,
>
> --
> Shane
>
> --Sig_/PtoendUfJlHQBMbcli0rI6Y
> Content-Type: application/pgp-signature
> Content-Description: OpenPGP digital signature
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAldNSF8ACgkQMsfZxBO4kbSZvACg1heT2xNL4kd3Umdy/n7sgDQ7
> dcoAoOES7FwngPzTX8ruIEDgRn18s3Pn
> =3xTI
> -----END PGP SIGNATURE-----
>
> --Sig_/PtoendUfJlHQBMbcli0rI6Y--
>
> --===============6230218504958761950==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> bind-workers mailing list
> bind-workers at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-workers
> --===============6230218504958761950==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-workers
mailing list