The case usually mentioned is in firewalls, under a policy that targets reassembly attacks. If system A sends a fragment but not all fragments of a message to system B, some of system B's resources are consumed until a timeout-or-something occurs. Dropping fragments prevents that.
Personally, I think the right solution is not to drop fragments, but impose limits on storage for reassembly. Fragments arriving in B should consume at most some amount of storage for some amount of time; if the time elapses, one discards the stale fragments, and if a new fragment arrives when resources are maxed out, one discards the oldest fragment present (LRU). We can argue ad infinitum on the amount of storage and time; I actually don't think the exact numbers are important. The time should be some multiple of the largest RTT the system sees, which is probably on the order of hundreds of milliseconds to seconds, and the storage quantum that is reasonable is probably measured in kilobytes. Beyond orders of magnitude, it's cook's choice. Listing the folks that have that firewall rule - I can't say. There seems to be a widely-held belief that the people exist. On Jun 25, 2013, at 11:56 AM, Ole Troan <otr...@employees.org> wrote: > Randy, > >>> If it's a statement of fact, it shouldn't use RFC 2119 language. It >>> should simply state the truth: "Network operators might filter IPv6 >>> fragments." >> >> s/might/do/ > > would you be able to answer why and where? > > cheers, > Ole > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
