On 01/04/2012 02:51 PM, Timothy Hartrick wrote: > Folks, > > The posting of draft-gont-6man-ipv6-atomic-fragments-00.txt triggered > some (unintended) discussion about the usefulness/legitimacy of IPv6 > "atomic fragments" (IPv6 packets that contain a Fragmentation Header, > but that have the "More Fragments" bit set to zero). > > > Just to clarify what you mean by an atomic fragment; you mean fragments > with an offset of 0 and the "More Fragments" flag set to zero. That is, > this is the beginning and there is no more.
Yes, exactly. (Sorry for the confusion! -- 24-hours working on code without any sleep (literally) did have their effect on me, it seems... :-( ) > My understanding is that is quite clear that such packets have been > found in the wild and that a number of things would break if they were > blocked or banned. > > > They are essential to translation systems. Firewalls that block them > are broken since "atomic fragments" represent no security risk and are a > legal part of the protocol. That's my take, too. > That said, I'd like some feedback on the actual proposal in > draft-gont-6man-ipv6-atomic-fragments-00.txt: process the aforementioned > "atomic fragments" as if they were non-fragmented packets. This would > basically eliminate all the security issues and problems normally > associated with framgentation, while still allowing their legitimate > use. > > On the one hand I would prefer that this document not be necessary. > That is, treating "atomic fragments" as not being fragmented at all is > the way that any competent software engineer would treat them. The idea > of allocating reassembly state and timers for datagrams of this sort and > then executing anything like the normal reassembly logic on them is > absurd. It is difficult to imagine that there are implementations that > would do so. Test some of them, and you'll see. :-) > That said, if we need to spell that out in great and gory detail to get > implementors to do the obvious thing, then I guess we need to. I > grudgingly support the proposal to document how implementations should > treat "atomic fragments". Thanks, for your support. My experience with this sort of corner cases is that unless you explicitly say what should be done, you cannot assume that implementers will follow your own logic (even if it's supposed to be obvious). Sometimes it takes time and discussion (such as that in this thread) for us (protocol types :-) ) to converge on something.. so it shouldn't be surprising that someone working on tons of patches doesn't spend some time trying to get every detail right. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
