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

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.

Report New Errata