Turn off IPV6_USE_MIN_MTU?

[Mark Andrews]

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