In message <caaedzxrr9jnhuo5tm6wmogkhhooudpd3+wk0rrn6hxzh0s3...@mail.gmail.com>, Erik Kline writes: > On 16 June 2013 23:15, Mark Andrews <[email protected]> wrote: > > > > In message <[email protected]>, joel jaeggli writes: > >> I'm interested in the intersection between the requested payload size > >> and the use of the v6 fragmentation header, 6891 I think is missing some > >> advice to implementers that might reasonably prevent fragmented replies > >> from being dropped and limit the degree of amplification that can be > >> achieved with large RRsets. > > > > Fragments get dropped because of badly configured/designed firewalls > > and PMTUD. Setting IPV6_USE_MIN_MTU to 1 helps with the latter > > though it may result in a addition fragment being sent. > > Unfortunately the former are far too prevalent. It's undoubtedly too > late, but unfortunately it might have been better to do the > fragmentation within the UDP payload (i.e. inside DNS) somehow (c.f. > http://tools.ietf.org/html/rfc5405#section-3.2).
It is *never* too late. For IPv6 we are still in the very early days. Firewalls could just as <src,dest,next header udp,frag!=0> when they add <src,dest,udp,port,port> tuple today for reply traffic. This make the hole for fragments a slit rather than wide open. One could extend IPv6 to add a ignorable hop-by-hop option that contains a copy the UDP header and add that when fragmentation is done. This would reduce the slit to a point. If the firewall is reassembling this would be used to protect the reassembly queue. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
