RFC Errata
RFC 8200, "Internet Protocol, Version 6 (IPv6) Specification", July 2017
Source of RFC: 6man (int)
Errata ID: 5172
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2017-10-29
Rejected by: Suresh Krishnan
Date Rejected: 2020-02-03
Section 4.5 says:
The Fragmentable Part of the reassembled packet is constructed from the fragments following the Fragment headers in each of the fragment packets. The length of each fragment is computed by subtracting from the packet's Payload Length the length of the headers between the IPv6 header and fragment itself; its relative position in Fragmentable Part is computed from its Fragment Offset value.
It should say:
The "Ext & Upper-Layer Headers" part and Fragmentable Part of the reassembled packet are constructed from the "chunks" following the Fragment headers in each of the fragment packets. The length of each chunk is computed by subtracting from the packet's Payload Length the length of the headers between the IPv6 header and chunk itself; the relative position of the chunk is computed from its Fragment Offset value.
Notes:
* The original text misses how to construct the "Ext & Upper-Layer Headers" of the packet, which in the figures is not considered to be part of the "Unfragmentable part" (it *was* considered part of it in RFC2460).
* The original text does says:
The length of each fragment is computed
by subtracting from the packet's Payload Length the length of
the headers between the IPv6 header and fragment itself
Assuming "each fragment" refers to the pieces marked as "first fragment", "second fragment", etc., this does not apply for the computation of the length of the first fragment, since such computed length would otherwise include the length of the first fragment, plus the length of "Ext & Upper-Layer Headers".
* The "corrected text" requires more work, and employs the (previously undefined) term "chunk" to refer to the content of a fragment (the chunk following a Fragment Header in a given packet). This is because for all fragments other than the first, "fragment" is what follows an FH, but for the first fragment (given the figures), "first fragment" is NOT everything that follows the FH (i.e., it does not include the "Ext & Upper-Layer Headers" part.
* Note that in the corrected text, the phrase "its relative position in Fragmentable Part is computed from its Fragment Offset value", since the relative position is really from the "Ext & Upper-Layer Headers" part, rather than from the Unfragmentable part.
--VERIFIER NOTES--
Verifier's Note by Suresh Krishnan (Responsible AD for 6man): The 6man working group has chosen to address the subject of this Erratum and other related Errata using a consolidated fix detailed in the Erratum report #5945. I would like to thank the submitter Fernando Gont for bringing this up.