Re: [Technical Errata Reported] RFC8200 (5933)

On 11-Dec-19 16:27, RFC Errata System wrote:
...

> Corrected Text
> --------------
>    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. 

I'm seeing a problem here. The Segments Left field of the routing header
must be decremented at the end of each segment. That's processing the
RH in my book, and it will occur when Segments Left >0.

   Brian

> 
>    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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC8200 (draft-ietf-6man-rfc2460bis-13)
> --------------------------------------
> Title               : Internet Protocol, Version 6 (IPv6) Specification
> Publication Date    : July 2017
> Author(s)           : S. Deering, R. Hinden
> Category            : INTERNET STANDARD
> Source              : IPv6 Maintenance
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> .
> 