> Mark Andrews <mailto:[email protected]> > Friday, January 23, 2015 12:50 PM > In message <[email protected]>, Nicholas > Weaver writes: >> ... >> >> The Internet has unfortunately decreed that Fragmentation Does Not Work >> with IPv4, and Really Does Not Work with IPv6. > > No. Firewall vendors are too lazy to properly design them to handle > fragments. There is nothing inherently wrong with using fragments.
if you said "theoretically" rather than "inherently" i would agree. because from a practical standpoint, nicholas is correct, and RFC 2671 was wrong-headed. the authors of "Fragmentation Considered Harmful, WRL-87-3" (online at http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.html) were my direct supervisors in 1988 and 1989, and i had read this paper and agreed with it. yet, a few short years later my body was apparently taken over by a space alien who had not read this paper, yielding RFC 2671 and all of its fragmentary evils. > > ... > > "pass udp any any frag" works when the firewall vendor doesn't add > the second on demand rule. yes, and, i have this rule in all my firewall rulesets where "pass udp any any 53" is also present. let's assume that all readers of this mailing list also do, because, that's the reasonable thing for educated people to do. there would still be no place in today's world for any wide area protocol that depends on working end-to-end fragmentation, because too many DNS protocol endpoints are behind middleboxes that are either not configurable, or which can only permit fragments if you turn on statefulness (which yields a far worse result), or because the operators are unaware (and will never become aware) of this problem. this is why RFC 6013, and <http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf>, exist. sadly, the tcp-m WG did not agree with that approach. the goal of "robust cookies" was to retain compressed connection state on the same order of cost magnitude as is universally used by compressed TCP SYN flood protection state, so that sessions would become "mostly dead" rather than "fully dead" after the FIN/FINACK. this allowed multi-segment responses to single-segment requests, which is the same packet flow as for EDNS, but with zero danger of DDoS reflection or amplification. (google's tcp-fastopen has similar aspirations but with nothing like the same security profile.) -- Paul Vixie
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
