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

> It mentions _the_ node identified in the DA, singular.

Lol ...

How can DA contain more then one destination node address (other then
multicast) in the view of RFC8200 ?

Unbelievable what is happening on this WG list.

Have a great weekend,
R.

On Sat, May 16, 2020 at 12:33 AM Sander Steffann <sander@steffann.nl> wrote:

> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>