Re: [Errata Held for Document Update] RFC8200 (5933)

[Brian E Carpenter <[e-mail]>]

Hi everybody,

I've realised that we really do need a WG discussion & rough consensus on
this issue. As a matter of fact, RFC 8200 is internally inconsistent,
because there are three mutually incompatible statements (not just two
as implied by erratum 5933):

1. Some non-normative Appendix text that states an intention:

>>    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

2. A rule in section 4 that does not consider routing headers:

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

3. In section 4.4, a clear implication that the Segments Left field is
decremented in flight, in violation of that rule:

>>       Segments Left       8-bit unsigned integer.  Number of route
>>                           segments remaining, i.e., number of explicitly
>>                           listed intermediate nodes still to be visited
>>                           before reaching the final destination.

So it's a complete oversight that this exception to the previous rule
is not mentioned. That's additional to Fernando's statement that the 
DA field was intended to refer to the final DA in the routing header,
which some people may disagree about. We goofed, despite all the discussion
on 2460bis.

Regards
   Brian Carpenter

On 02-Mar-20 16:29, RFC Errata System wrote:
> The following errata report has been held for document update 
> for RFC8200, "Internet Protocol, Version 6 (IPv6) Specification". 
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5933
> 
> --------------------------------------
> Status: Held for Document Update
> Type: Technical
> 
> Reported by: Fernando Gont <[e-mail]>
> Date Reported: 2019-12-11
> Held by: Suresh Krishnan (IESG)
> 
> Section: 4
> 
> Original Text
> -------------
>    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.
> 
> 
> 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. 
> 
>    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.
> 
> --------------------------------------
> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>