RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Reported (4)

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

Source of RFC: 6man (int)

Errata ID: 5170

Status: Reported
Type: Technical

Reported By: Fernando Gont
Date Reported: 2017-10-28

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.

Errata ID: 5171

Status: Reported
Type: Technical

Reported By: Fernando Gont
Date Reported: 2017-10-29

Section 4.5 says:

   The subsequent fragment packets are composed of:

      (1)  The Per-Fragment headers of the original packet, with the
           Payload Length of the original IPv6 header changed to contain
           the length of this fragment packet only (excluding the length
           of the IPv6 header itself), and the Next Header field of the
           last header of the Per-Fragment headers changed to 44.

      (2)  A Fragment header containing:

              The Next Header value that identifies the first header
              after the Per-Fragment headers of the original packet.

              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.

It should say:

   The subsequent fragment packets are composed of:

      (1)  The Per-Fragment headers of the original packet, with the
           Payload Length of the original IPv6 header changed to contain
           the length of this fragment packet only (excluding the length
           of the IPv6 header itself), and the Next Header field of the
           last header of the Per-Fragment headers changed to 44.

      (2)  A Fragment header containing:

              The Next Header value that identifies the first header
              after the Per-Fragment headers of the original packet.

              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.

Notes:

This complements this errata:

Reported By: Fernando Gont
Date Reported: 2017-10-28

Errata ID: 5172

Status: Reported
Type: Technical

Reported By: Fernando Gont
Date Reported: 2017-10-29

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.

Errata ID: 5173

Status: Reported
Type: Technical

Reported By: Fernando Gont
Date Reported: 2017-10-29

Section 4.5 says:

   reassembled original packet:

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

It should say:

   reassembled original packet:

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

Notes:

The figure in the "original text" is inconsistent with an earlier figure of the "original packet" (in page 18), where the "Ext & Upper-Layer Headers" part is followed by "first fragment" (rather than "first fragment data").

As an alternative to the "corrected text" above, one could modify such earlier figure (s/first fragment/first fragment data/), but this would beg a definition of "how is a fragment composed?" i.e., what's "fragment data" and what's not).

Report New Errata