Hi Fernando, Full agreement on the substance of your draft, and support for an RFC based on it.
However, I believe it should rather be a BCP than a Standard-track RFC. (I don't see any need to standardize anything beyond what already exists.) Regards, RD Le 2012-01-04 à 20:36, Fernando Gont a écrit : > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
