Subject: [Errata Rejected] RFC8200 (5170)

From: RFC Errata System <[email-masked]>
Date: Mon, 3 Feb 2020 06:14:55 -0800 (PST)

The following errata report has been rejected for RFC8200,
"Internet Protocol, Version 6 (IPv6) Specification".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5170

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Fernando Gont <[email-masked]>
Date Reported: 2017-10-28
Rejected by: Suresh Krishnan (IESG)

Section: 4.5

Original Text
-------------
              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.

Corrected Text
--------------
              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. 

--------------------------------------
RFC8200 (draft-ietf-6man-rfc2460bis-13)
--------------------------------------
Title               : Internet Protocol, Version 6 (IPv6) Specification
Publication Date    : July 2017
Author(s)           : S. Deering, R. Hinden
Category            : INTERNET STANDARD
Source              : IPv6 Maintenance
Area                : Internet
Stream              : IETF
Verifying Party     : IESG