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

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