RFC 8200, "Internet Protocol, Version 6 (IPv6) Specification", July 2017

Errata ID: 5170
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2017-10-28
Rejected by: Suresh Krishnan
Date Rejected: 2020-02-03

Section 4.5 says:

              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              Fragmentable Part of the original packet.  The Fragment
              Offset of the first ("leftmost") fragment is 0.

It should say:

              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              "Extension & Upper-Layer Headers" Part of the original 
              packet. The Fragment Offset of the fragment containing
              the "Extension & Upper-Layer Headers" part is 0.

Notes:

Clearly, the first fragment will contain a Fragment Offset of 0.

However, given the figure:

---- cut here ----
original packet:

+-----------------+-----------------+--------+--------+-//-+--------+
| Per-Fragment |Ext & Upper-Layer| first | second | | last |
| Headers | Headers |fragment|fragment|....|fragment|
+-----------------+-----------------+--------+--------+-//-+--------+

fragment packets:

+------------------+---------+-------------------+----------+
| Per-Fragment |Fragment | Ext & Upper-Layer | first |
| Headers | Header | Headers | fragment |
+------------------+---------+-------------------+----------+

+------------------+--------+-------------------------------+
| Per-Fragment |Fragment| second |
| Headers | Header | fragment |
+------------------+--------+-------------------------------+
o
o
o
+------------------+--------+----------+
| Per-Fragment |Fragment| last |
| Headers | Header | fragment |
+------------------+--------+----------+


it is the part market as "Ext & Upper-Layer Headers" the one that will have a Fragment offset of 0, rather than the part marked as "first fragment". For example, one could envision this scenario:

---- cut here ----
original packet:

+-----------------+-----------------+---------------+
| Per-Fragment |Ext & Upper-Layer| first & last |
| Headers | Headers | fragment |
+-----------------+-----------------+---------------+

fragment packets:

+------------------+---------+-------------------+
| Per-Fragment |Fragment | Ext & Upper-Layer |
| Headers | Header | Headers |
+------------------+---------+-------------------+

+------------------+--------+---------------+
| Per-Fragment |Fragment| first & last |
| Headers | Header | fragment |
+------------------+--------+---------------+

---- cut here ----

Where the first fragment just contains the entire IPv6 header chain, and then second fragment contains the chunk marked as "first fragment" (this "first fragment" part is the only "Fragmentable" part of the packet).

Note: the text "The Fragment Offset of the first ("leftmost") fragment is 0." was re-phrased in the "corrected text", since it might confuse the reader regarding whether it refers to the actual first fragment (i.e. the first packet corresponding to the fragmented datagram), or the chunk marked as "first fragment" in the figure.
--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.

Report New Errata