Re: Spring Appeal and [Errata Rejected] RFC8200 (6003)

[Sander Steffann <[e-mail]>]

Hi Erik,

> RFC 8200 includes an exemption to this behaviour for nodes whose
> address appears in the Destination Address field of the IPv6 header.
> This text has not changed from 1883 to 2460 to 8200.

I disagree with your interpretation of the text of 8200. It 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.

It mentions _the_ node identified in the DA, singular. It only specifies multiple nodes in the case of multicast. The combination of using singular and only using plural when explicitly talking about multicast reads to me as only referring to the final destination. The use of the word "until" signals the same to me. Using "until" for something that can occur multiple times sequentially in a packets lifetime would be very confusing.

Now, this does pose a problem, because strict reading of that text also means that a node can only learn that it is not the final destination by processing the routing header. As I read it, that node can process the routing header but then has to stop further processing when it finds out it is not the final destination. In blunt English: any further processing of headers is none of its business. As I understand it that is also the reason that a separate destination options header may appear *before* the routing header.

Cheers,
Sander