I noticed this Errata. I'm OK with removing the requirement (MUST), but I think the recommendation is not entirely bad to discard fragments that may follow - albeit for a limited time and subject to finding a way to implement. MSL As presently defined could also be regarded as too harsh, that's a different topic.
The note mentions "normal" stacks: Normal stacks do not keep state when the IP packet has been resembled (forwarded), but do keep it while the IP packet is not complete. Hence, if the packet did not reassemble, the "overlap" state would be kept. Gorry > > The following errata report has been submitted for RFC5722, > "Handling of Overlapping IPv6 Fragments". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5722&eid=3089 > > -------------------------------------- > Type: Technical > Reported by: Simon Perreault <[email protected]> > > Section: 4 > > Original Text > ------------- > IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT > create overlapping fragments. When reassembling an IPv6 datagram, if > one or more its constituent fragments is determined to be an > overlapping fragment, the entire datagram (and any constituent > fragments, including those not yet received) MUST be silently > discarded. > > Corrected Text > -------------- > IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT > create overlapping fragments. When reassembling an IPv6 datagram, if > one or more its constituent fragments is determined to be an > overlapping fragment, the entire datagram (and any constituent > fragments) MUST be silently discarded. > > Notes > ----- > Discarding fragments "including those not yet received" is not > implementable. You'd have to keep state about the (source, destination, > protocol, id) 4-tuple for MSL (120 seconds). If you do this you create two > bugs: > - A new attack vector: an attacker could eat your resources. And if you > just limit the number of such state entries then you fail to implement RFC > 5722 correctly. > - It breaks at fairly low speeds. See draft-ietf-intarea-ipv4-id-update. > > The proposal is simply to remove the "including those not yet received" > bit. Normal host stacks do not keep state once a fragment has been > reassembled. You reassemble the full packet and clear the fragment table. > So this corrected text would align the RFC with actual practice. > > This errata report results from an implementation attempt by OpenBSD. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5722 (draft-ietf-6man-overlap-fragment-03) > -------------------------------------- > Title : Handling of Overlapping IPv6 Fragments > Publication Date : December 2009 > Author(s) : S. Krishnan > Category : PROPOSED STANDARD > Source : IPv6 Maintenance > Area : Internet > Stream : IETF > Verifying Party : IESG > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
