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
--------------------------------------------------------------------

Reply via email to