RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 11 records.

Status: Verified (2)

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

Source of RFC: 6man (int)

Errata ID: 5945
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Bob Hinden
Date Reported: 2019-12-24
Verifier Name: Suresh Krishnan
Date Verified: 2020-02-03

Section 4.5 says:

4.5.  Fragment Header

   The Fragment header is used by an IPv6 source to send a packet larger
   than would fit in the path MTU to its destination.  (Note: unlike
   IPv4, fragmentation in IPv6 is performed only by source nodes, not by
   routers along a packet's delivery path -- see [RFC8200].)  The
   Fragment header is identified by a Next Header value of 44 in the
   immediately preceding header and has the following format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header         8-bit selector.  Identifies the initial header
                          type of the Fragmentable Part of the original
                          packet (defined below).  Uses the same values
                          as the IPv4 Protocol field [IANA-PN].

      Reserved            8-bit reserved field.  Initialized to zero for
                          transmission; ignored on reception.

      Fragment Offset     13-bit unsigned integer.  The offset, in
                          8-octet units, of the data following this
                          header, relative to the start of the
                          Fragmentable Part of the original packet.

      Res                 2-bit reserved field.  Initialized to zero for
                          transmission; ignored on reception.

      M flag              1 = more fragments; 0 = last fragment.

      Identification      32 bits.  See description below.

   In order to send a packet that is too large to fit in the MTU of the
   path to its destination, a source node may divide the packet into
   fragments and send each fragment as a separate packet, to be
   reassembled at the receiver.

   For every packet that is to be fragmented, the source node generates
   an Identification value.  The Identification must be different than
   that of any other fragmented packet sent recently* with the same
   Source Address and Destination Address.  If a Routing header is
   present, the Destination Address of concern is that of the final
   destination.


      *  "recently" means within the maximum likely lifetime of a
         packet, including transit time from source to destination and
         time spent awaiting reassembly with other fragments of the same
         packet.  However, it is not required that a source node knows
         the maximum packet lifetime.  Rather, it is assumed that the
         requirement can be met by implementing an algorithm that
         results in a low identification reuse frequency.  Examples of
         algorithms that can meet this requirement are described in
         [RFC7739].

   The initial, large, unfragmented packet is referred to as the
   "original packet", and it is considered to consist of three parts, as
   illustrated:

   original packet:

   +------------------+-------------------------+---//----------------+
   |  Per-Fragment    | Extension & Upper-Layer |   Fragmentable      |
   |    Headers       |       Headers           |      Part           |
   +------------------+-------------------------+---//----------------+

      The Per-Fragment headers must consist of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

      The Extension headers are all other extension headers that are not
      included in the Per-Fragment headers part of the packet.  For this
      purpose, the Encapsulating Security Payload (ESP) is not
      considered an extension header.  The Upper-Layer header is the
      first upper-layer header that is not an IPv6 extension header.
      Examples of upper-layer headers include TCP, UDP, IPv4, IPv6,
      ICMPv6, and as noted ESP.

      The Fragmentable Part consists of the rest of the packet after the
      upper-layer header or after any header (i.e., initial IPv6 header
      or extension header) that contains a Next Header value of No Next
      Header.

   The Fragmentable Part of the original packet is divided into
   fragments.  The lengths of the fragments must be chosen such that the
   resulting fragment packets fit within the MTU of the path to the
   packet's destination(s).  Each complete fragment, except possibly the
   last ("rightmost") one, is an integer multiple of 8 octets long.

   The fragments are transmitted in separate "fragment packets" as
   illustrated:

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

   The first fragment packet is 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.  The Fragment
              Offset of the first ("leftmost") fragment is 0.

              An M flag value of 1 as this is the first fragment.

              The Identification value generated for the original
              packet.

      (3)  Extension headers, if any, and the Upper-Layer header.  These
           headers must be in the first fragment.  Note: This restricts
           the size of the headers through the Upper-Layer header to the
           MTU of the path to the packet's destinations(s).

      (4)  The first fragment.

   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.

              An M flag value of 0 if the fragment is the last
              ("rightmost") one, else an M flag value of 1.

              The Identification value generated for the original
              packet.

      (3)  The fragment itself.

   Fragments must not be created that overlap with any other fragments
   created from the original packet.

   At the destination, fragment packets are reassembled into their
   original, unfragmented form, as illustrated:

   reassembled original packet:

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

   The following rules govern reassembly:

      An original packet is reassembled only from fragment packets that
      have the same Source Address, Destination Address, and Fragment
      Identification.

      The Per-Fragment headers of the reassembled packet consists of all
      headers up to, but not including, the Fragment header of the first
      fragment packet (that is, the packet whose Fragment Offset is
      zero), with the following two changes:

         The Next Header field of the last header of the Per-Fragment
         headers is obtained from the Next Header field of the first
         fragment's Fragment header.

         The Payload Length of the reassembled packet is computed from
         the length of the Per-Fragment headers and the length and
         offset of the last fragment.  For example, a formula for
         computing the Payload Length of the reassembled original packet
         is:

            PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last


            where
            PL.orig  =  Payload Length field of reassembled packet.
            PL.first =  Payload Length field of first fragment packet.
            FL.first =  length of fragment following Fragment header of
                        first fragment packet.
            FO.last  =  Fragment Offset field of Fragment header of last
                        fragment packet.
            FL.last  =  length of fragment following Fragment header of
                        last fragment packet.

         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.

         The Fragment header is not present in the final, reassembled
         packet.

         If the fragment is a whole datagram (that is, both the Fragment
         Offset field and the M flag are zero), then it does not need
         any further reassembly and should be processed as a fully
         reassembled packet (i.e., updating Next Header, adjust Payload
         Length, removing the Fragment header, etc.).  Any other
         fragments that match this packet (i.e., the same IPv6 Source
         Address, IPv6 Destination Address, and Fragment Identification)
         should be processed independently.

   The following error conditions may arise when reassembling fragmented
   packets:

      o  If insufficient fragments are received to complete reassembly
         of a packet within 60 seconds of the reception of the first-
         arriving fragment of that packet, reassembly of that packet
         must be abandoned and all the fragments that have been received
         for that packet must be discarded.  If the first fragment
         (i.e., the one with a Fragment Offset of zero) has been
         received, an ICMP Time Exceeded -- Fragment Reassembly Time
         Exceeded message should be sent to the source of that fragment.

      o  If the length of a fragment, as derived from the fragment
         packet's Payload Length field, is not a multiple of 8 octets
         and the M flag of that fragment is 1, then that fragment must
         be discarded and an ICMP Parameter Problem, Code 0, message
         should be sent to the source of the fragment, pointing to the
         Payload Length field of the fragment packet.

      o  If the length and offset of a fragment are such that the
         Payload Length of the packet reassembled from that fragment
         would exceed 65,535 octets, then that fragment must be
         discarded and an ICMP Parameter Problem, Code 0, message should
         be sent to the source of the fragment, pointing to the Fragment
         Offset field of the fragment packet.

      o  If the first fragment does not include all headers through an
         Upper-Layer header, then that fragment should be discarded and
         an ICMP Parameter Problem, Code 3, message should be sent to
         the source of the fragment, with the Pointer field set to zero.

      o  If any of the fragments being reassembled overlap with any
         other fragments being reassembled for the same packet,
         reassembly of that packet must be abandoned and all the
         fragments that have been received for that packet must be
         discarded, and no ICMP error messages should be sent.

         It should be noted that fragments may be duplicated in the
         network.  Instead of treating these exact duplicate fragments
         as overlapping fragments, an implementation may choose to
         detect this case and drop exact duplicate fragments while
         keeping the other fragments belonging to the same packet.

   The following conditions are not expected to occur frequently but are
   not considered errors if they do:

      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

      The Next Header values in the Fragment headers of different
      fragments of the same original packet may differ.  Only the value
      from the Offset zero fragment packet is used for reassembly.

      Other fields in the IPv6 header may also vary across the fragments
      being reassembled.  Specifications that use these fields may
      provide additional instructions if the basic mechanism of using
      the values from the Offset zero fragment is not sufficient.  For
      example, Section 5.3 of [RFC3168] describes how to combine the
      Explicit Congestion Notification (ECN) bits from different
      fragments to derive the ECN bits of the reassembled packet.
      

It should say:

4.5.  Fragment Header

   The Fragment header is used by an IPv6 source to send a packet larger
   than would fit in the path MTU to its destination.  (Note: unlike
   IPv4, fragmentation in IPv6 is performed only by source nodes, not by
   routers along a packet's delivery path -- see [RFC8200].)  The
   Fragment header is identified by a Next Header value of 44 in the
   immediately preceding header and has the following format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header         8-bit selector.  Identifies the initial header
                          type of the Fragmentable Part of the original
                          packet (defined below).  Uses the same values
                          as the IPv4 Protocol field [IANA-PN].

      Reserved            8-bit reserved field.  Initialized to zero for
                          transmission; ignored on reception.

      Fragment Offset     13-bit unsigned integer.  The offset, in
                          8-octet units, of the data following this
                          header, relative to the start of the
                          Fragmentable Part of the original packet.

      Res                 2-bit reserved field.  Initialized to zero for
                          transmission; ignored on reception.

      M flag              1 = more fragments; 0 = last fragment.

      Identification      32 bits.  See description below.

   In order to send a packet that is too large to fit in the MTU of the
   path to its destination, a source node may divide the packet into
   fragments and send each fragment as a separate packet, to be
   reassembled at the receiver.

   For every packet that is to be fragmented, the source node generates
   an Identification value.  The Identification must be different than
   that of any other fragmented packet sent recently* with the same
   Source Address and Destination Address.  If a Routing header is
   present, the Destination Address of concern is that of the final
   destination.

      *  "recently" means within the maximum likely lifetime of a
         packet, including transit time from source to destination and
         time spent awaiting reassembly with other fragments of the same
         packet.  However, it is not required that a source node knows
         the maximum packet lifetime.  Rather, it is assumed that the
         requirement can be met by implementing an algorithm that
         results in a low identification reuse frequency.  Examples of
         algorithms that can meet this requirement are described in
         [RFC7739].

   The initial, large, unfragmented packet is referred to as the
   "original packet", and it is considered to consist of two parts, as
   illustrated:

   original packet:

   +------------------+-----------------------------//----------------+
   |  Per-Fragment    |               Fragmentable                    |
   |    Headers       |                   Part                        |
   +------------------+-----------------------------//----------------+

      The Per-Fragment headers must consist of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

      The Fragmentable Part consists of the rest of the packet, that is,
      any extension headers that need be processed only by the final
      destination node(s), plus the upper-layer header and data.

   The Fragmentable Part of the original packet is divided into
   fragments.  The lengths of the fragments must be chosen such that the
   resulting fragment packets fit within the MTU of the path to the
   packet's destination(s).  Each complete fragment, except possibly the
   last ("rightmost") one, is an integer multiple of 8 octets long.

   The fragments are transmitted in separate "fragment packets" as
   illustrated:

   original packet:

    +------------------+--------------+--------------+--//--+----------+
    |  Per-Fragment    |    first     |    second    |      |   last   |
    |   Headers        |   fragment   |   fragment   | .... | fragment |
    +------------------+--------------+--------------+--//--+----------+

   fragment packets:

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

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

   The first fragment packet is 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.  The Fragment
              Offset of the first ("leftmost") fragment is 0.

              An M flag value of 1 as this is the first fragment.

              The Identification value generated for the original
              packet.

      (3)  Extension headers, if any, and the Upper-Layer header.  These
           headers must be in the first fragment.  Note: This restricts
           the size of the headers through the Upper-Layer header to the
           MTU of the path to the packet's destinations(s).

           Extension headers are all other extension headers that are
           not included in the Per-Fragment headers part of the packet.
           For this purpose, the Encapsulating Security Payload (ESP) is
           not considered an extension header.  The Upper-Layer header
           is the first upper-layer header that is not an IPv6 extension
           header.  Examples of upper-layer headers include TCP, UDP,
           IPv4, IPv6, ICMPv6, and as noted ESP.

      (4)  The remainder of the first fragment.

   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.

              An M flag value of 0 if the fragment is the last
              ("rightmost") one, else an M flag value of 1.

              The Identification value generated for the original
              packet.

      (3)  The fragment itself.

   Fragments must not be created that overlap with any other fragments
   created from the original packet.

   At the destination, fragment packets are reassembled into their
   original, unfragmented form, as illustrated:

   reassembled original packet:

   +------------------+----------------------//------------------------+
   |  Per-Fragment    |                 Fragmentable                   |
   |    Headers       |                     Part                       |
   +------------------+----------------------//------------------------+

   The following rules govern reassembly:

      An original packet is reassembled only from fragment packets that
      have the same Source Address, Destination Address, and Fragment
      Identification.

      The Per-Fragment headers of the reassembled packet consists of all
      headers up to, but not including, the Fragment header of the first
      fragment packet (that is, the packet whose Fragment Offset is
      zero), with the following two changes:

         The Next Header field of the last header of the Per-Fragment
         headers is obtained from the Next Header field of the first
         fragment's Fragment header.

         The Payload Length of the reassembled packet is computed from
         the length of the Per-Fragment headers and the length and
         offset of the last fragment.  For example, a formula for
         computing the Payload Length of the reassembled original packet
         is:

            PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last


            where
            PL.orig  =  Payload Length field of reassembled packet.
            PL.first =  Payload Length field of first fragment packet.
            FL.first =  length of fragment following Fragment header of
                        first fragment packet.
            FO.last  =  Fragment Offset field of Fragment header of last
                        fragment packet.
            FL.last  =  length of fragment following Fragment header of
                        last fragment packet.

         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.

         The Fragment header is not present in the final, reassembled
         packet.

         If the fragment is a whole datagram (that is, both the Fragment
         Offset field and the M flag are zero), then it does not need
         any further reassembly and should be processed as a fully
         reassembled packet (i.e., updating Next Header, adjust Payload
         Length, removing the Fragment header, etc.).  Any other
         fragments that match this packet (i.e., the same IPv6 Source
         Address, IPv6 Destination Address, and Fragment Identification)
         should be processed independently.

   The following error conditions may arise when reassembling fragmented
   packets:

      o  If insufficient fragments are received to complete reassembly
         of a packet within 60 seconds of the reception of the first-
         arriving fragment of that packet, reassembly of that packet
         must be abandoned and all the fragments that have been received
         for that packet must be discarded.  If the first fragment
         (i.e., the one with a Fragment Offset of zero) has been
         received, an ICMP Time Exceeded -- Fragment Reassembly Time
         Exceeded message should be sent to the source of that fragment.

      o  If the length of a fragment, as derived from the fragment
         packet's Payload Length field, is not a multiple of 8 octets
         and the M flag of that fragment is 1, then that fragment must
         be discarded and an ICMP Parameter Problem, Code 0, message
         should be sent to the source of the fragment, pointing to the
         Payload Length field of the fragment packet.

      o  If the length and offset of a fragment are such that the
         Payload Length of the packet reassembled from that fragment
         would exceed 65,535 octets, then that fragment must be
         discarded and an ICMP Parameter Problem, Code 0, message should
         be sent to the source of the fragment, pointing to the Fragment
         Offset field of the fragment packet.

      o  If the first fragment does not include all headers through an
         Upper-Layer header, then that fragment should be discarded and
         an ICMP Parameter Problem, Code 3, message should be sent to
         the source of the fragment, with the Pointer field set to zero.

      o  If any of the fragments being reassembled overlap with any
         other fragments being reassembled for the same packet,
         reassembly of that packet must be abandoned and all the
         fragments that have been received for that packet must be
         discarded, and no ICMP error messages should be sent.

         It should be noted that fragments may be duplicated in the
         network.  Instead of treating these exact duplicate fragments
         as overlapping fragments, an implementation may choose to
         detect this case and drop exact duplicate fragments while
         keeping the other fragments belonging to the same packet.

   The following conditions are not expected to occur frequently but are
   not considered errors if they do:

      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

      The Next Header values in the Fragment headers of different
      fragments of the same original packet may differ.  Only the value
      from the Offset zero fragment packet is used for reassembly.

      Other fields in the IPv6 header may also vary across the fragments
      being reassembled.  Specifications that use these fields may
      provide additional instructions if the basic mechanism of using
      the values from the Offset zero fragment is not sufficient.  For
      example, Section 5.3 of [RFC3168] describes how to combine the
      Explicit Congestion Notification (ECN) bits from different
      fragments to derive the ECN bits of the reassembled packet.

Notes:

This errata replaces and resolves the issues raised in Errata 5170, 5171, 5172, 5173. Credit goes to Fernando Gont for reporting the issues raised in these errata. They correctly reported that the text in Section 4.5 of RFC8200 defined Fragment Offset as pointing to “Fragmentable Part”, this was an error and should have pointed to “Extension & Upper-Layer Headers”.

After review by the 6man working group the conclusion was to fix the issue in a more general way than what was proposed in Errata 5170, 5171, 5172, 5173, hence the need for a new errata.

Errata ID: 5256
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2018-02-06
Verifier Name: Suresh Krishnan
Date Verified: 2020-02-03

Section 4.8 says:

      Hdr Ext Len           8-bit unsigned integer.  Length of the
                            Destination Options header in 8-octet units,
                            not including the first 8 octets.

It should say:

      Hdr Ext Len           8-bit unsigned integer.  Length of the
                            extension header in 8-octet units,
                            not including the first 8 octets.

Notes:

Copy-paste error.

Status: Reported (1)

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

Source of RFC: 6man (int)

Errata ID: 6248
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jingrong Xie
Date Reported: 2020-08-06

Section 4.5 says:

      The Per-Fragment headers must consist of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

It should say:

      The Per-Fragment headers must consist of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination. In the recommended order of extension headers listed 
      in section 4.1, the Per-Fragment headers include all headers up to 
      and including the Routing header if present, else the Hop-by-Hop 
      Options header if present, else no extension headers. In case the
      order of extension headers is specified, the Per-Fragment headers 
      include all headers that is required to be before the Fragment Header.

Notes:

1. As specified in in section 4.1 of RFC8200, the recommended order of existing extension headers could be revised, and there have been some examples in the RFCs that do such revision: RFC7837, RFC6275 and its related RFCs, RFC3775/RFC3776/RFC4784.
2. RFC6275 requires DoH carrying a special option to be placed before Fragmentation header. This gives an example how to support Fragmentation with the order of extension headers revised.
3. As specified in section 4.8 of RFC8200, new extension headers could be defined, and there may be some new Per-fragment header(s) defined requiring en route processing with fragmentation support.

Status: Held for Document Update (3)

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

Source of RFC: 6man (int)

Errata ID: 5933
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Fernando Gont
Date Reported: 2019-12-11
Held for Document Update by: Suresh Krishnan
Date Held: 2020-03-02

Section 4 says:

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  The Hop-by-Hop Options header, when present, must
   immediately follow the IPv6 header.  Its presence is indicated by the
   value zero in the Next Header field of the IPv6 header.

It should say:

   Extension headers (except for the Hop-by-Hop Options header, or a 
   Destination Options header preceding a Routing header) are not processed,
   inserted, or deleted by any node along a packet's delivery path, until the
   packet reaches the final destination node (or each of the set of final
   destination nodes, in the case of multicast). 

   For packets that do not include a Routing Header, the final destination
   node is identified by the Destination Address field of the IPv6 header. 
   For packets that include a Routing Header, the final destination node is 
   identified by the Destination Address field of the IPv6 header only when
   the Segments Left field of the Routing Header is 0. 

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the final destination node (or each of the set of
   final destination nodes, in the case of multicast). The Hop-by-Hop Options 
   header, when present, must immediately follow the IPv6 header.  Its 
   presence is indicated by the value zero in the Next Header field of the 
   IPv6 header.

   A Destination Options header preceding a Routing Header is not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the destination node (or each of the set 
   of destination nodes, in the case of multicast) identified by the 
   Destination Address field of the IPv6 header. This means that  a 
   Destination Options header preceding a Routing Header will be
   processed by the first destination of the packet (specified by the
   Destination Address field of the IPv6 header at the origin node) and by 
   each node listed in the Routing Header.

Notes:

This errata clarifies two different issues:

* It clarifies that nodes other than the final destination do not insert o remove extension headers.

* It clarifies that the Destination Options header preceding a routing header *is* processed along the
packet delivery's path, but the node(s) identified by the Destination Address of the IPv6 header.

Area Director's Note (Suresh Krishnan):

I am handling this based on the IESG Statement about processing of RFC Errata for the IETF Stream (https://ietf.org/about/groups/iesg/statements/processing-rfc-errata/)

"Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected."

Some people might interpret the text in RFC8200 to mean the replacement text provided above in the erratum but others might read the text exactly as written ("until the packet reaches the node identified in the Destination Address field of the IPv6 header”). Given that the text in RFC8200 had consensus and it is impossible to tell after the fact if the proposed replacement text would have achieved consensus, I believe this erratum falls under the above category.

The change proposed by this erratum has to be evaluated for correctness and consensus if and when there is an update of RFC8200.

Errata ID: 5259
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2018-02-08
Held for Document Update by: Suresh Krishnan
Date Held: 2020-02-03

Section Appendix B says:

      -  Updated the Fragmentation header text to correct the inclusion
         of an Authentication Header (AH) and noted No Next Header case.

It should say:

      -  Updated the Fragment header text to correct the inclusion
         of an Authentication Header (AH) and noted No Next Header case.

Notes:

Typo

Errata ID: 5506
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: jiangmaoyong
Date Reported: 2018-09-27
Held for Document Update by: Suresh Krishnan
Date Held: 2020-02-03

Section Appendix B. says:

      -  Updated the Fragmentation header text to correct the inclusion
         of an Authentication Header (AH) and noted No Next Header case.

It should say:

      -  Updated the Fragmentation header text to correct the inclusion
         the Encapsulating Security Payload (ESP)  and noted No Next 
         Header case.

Notes:

The Extension headers are all other extension headers that are not
included in the Per-Fragment headers part of the packet. For this
purpose, the Encapsulating Security Payload (ESP) is not
considered an extension header. The Upper-Layer header is the
first upper-layer header that is not an IPv6 extension header.
Examples of upper-layer headers include TCP, UDP, IPv4, IPv6,
ICMPv6, and as noted ESP.

The Fragmentable Part consists of the rest of the packet after the
upper-layer header or after any header (i.e., initial IPv6 header
or extension header) that contains a Next Header value of No Next
Header.

Status: Rejected (5)

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

Source of RFC: 6man (int)

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.

Errata ID: 5171
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 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
--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.

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.

Errata ID: 5173
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:

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

Errata ID: 6003
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Fernando Gont
Date Reported: 2020-03-02
Rejected by: Erik Kline
Date Rejected: 2020-05-10

Section 4 says:

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  The Hop-by-Hop Options header, when present, must
   immediately follow the IPv6 header.  Its presence is indicated by the
   value zero in the Next Header field of the IPv6 header.

It should say:

   The source node of a packet, identified by the source address, may
   include extension headers in a packet when it is created. Extension
   headers must not be inserted or removed or have their length altered
   by any node for the lifetime of the IPv6 packet. Note that it follows
   from these requirements that the length of an IPv6 packet cannot
   change once the packet has been created by the source node. The
   aforementioned rules apply to all IPv6 extension headers.

   Extension headers (except for the Hop-by-Hop Options header, a
   Routing Header, or a Destination Options header preceding a Routing
   Header) are not processed by any node along a packet's delivery path,
   until the packet reaches the final destination node (or each of the
   set of final destination nodes, in the case of multicast).

   For packets that do not include a Routing Header, the final
   destination node is identified by the Destination Address field of
   the IPv6 header. For packets that include a Routing Header, the final
   destination node is identified by the Destination Address field of
   the IPv6 header only when the Segments Left field of the Routing
   Header is 0.

   The Hop-by-Hop Options header may be examined or processed by any
   node along a packet's delivery path, until the packet reaches the
   final destination node (or each of the set of final destination
   nodes, in the case of multicast). The Hop-by-Hop Options header, when
   present, must immediately follow the IPv6 header.  Its presence is
   indicated by the value zero in the Next Header field of the IPv6
   header.

   A Destination Options header preceding a Routing Header is processed
   only by the destination node (or each of the set of destination
   nodes, in the case of multicast) identified by the Destination
   Address field of the IPv6 header. This means that a Destination
   Options header preceding a Routing Header will be processed by the
   first destination of the packet (specified by the Destination Address
   field of the IPv6 header at the source node) and by each node listed
   in the Routing Header.

   A Routing Header is processed only by the destination node (or each
   of the set of destination nodes, in the case of multicast) identified
   by the Destination Address field of the IPv6 header. This means that
   a Routing Header will be processed by the first destination of the
   packet (specified by the Destination Address field of the IPv6 header
   at the source node) and by each node listed in the Routing Header. 

Notes:

This erratum addresses the following problems from RFC8200:

* It clarifies that IPv6 does not support en-route insertion/removal
of IPv6 Extension Headers

* Clarifies the the processing rules for Routing Headers and Destination
Options headers preceding a Routing Header.


RATIONALE:

IPv6 never supported the en-route insertion/removal of IPv6 Extension Headers, since it would have broken a number of IPv6 core components, including:

* IPsec Authentication Header (AH)

* Path-MTU Discovery for IPv6 (RFC8201)

* Error reporting based on ICMPv6 error messages (RFC4443), since hosts
validate that received error messages correspond to packets sent by
the host receiving the error message.


It was the intent of RFC8200 to clarify this behavior, as noted by Appendix B ("Changes Since RFC 2460") of RFC8200:

o Clarified that extension headers (except for the Hop-by-Hop
Options header) are not processed, inserted, or deleted by any
node along a packet's delivery path.

however, the resulting text was far from perfect. This erratum means to more closely reflect and respect the intent of RFC8200.

The corrected text has benefited from the review and input from Ron Bonica, Brian Carpenter, and Tom Herbert.
--VERIFIER NOTES--
Section 3 clearly highlights for the reader when the IPv6 Destination Address in the header might differ from the IPv6 address of the ultimate destination.

As such, all references in the document to "Destination Address" lacking further qualifying text should be read bearing this in mind. The text in section 4 is no exception. The key text has remained unchanged since RFC 1883.

Though it may be fraught with operational peril, including impeding the correct processing by the source node of a received ICMPv6 error message's encapsulated packet payload, a strict literal reading of the existing text affords any node in the header's Destination Address field a (possibly surprising) degree of flexibility in the handling of extension headers.

If IPsec AH (RFC 4302) were in use, the overall IPv6 header Payload Length field would need to remain intact, but the contents of certain types of extension headers between the IPv6 header and the AH header may not need to be preserved. If AH is not in use, it is not clear that any AH-related requirements need apply at all.

Given the continuing discussion, whether this text (and its strict literal interpretation) is a feature or a bug appears to lack consensus.

In fact, considering the apparent lack of substantive progress toward resolution on this issue in the working group since https://www.rfc-editor.org/errata/eid5933 previously attempted to revise this text, continuing use of the erratum report process for this could risk the appearance of bypassing the working group consensus process.

The text from Section 3 makes it clear that making the kind of change proposed would require a consensus change; this is not a matter to be address by an erratum alone.

Report New Errata