Re: [Errata Rejected] RFC8200 (6003)

[Fernando Gont <[e-mail]>]

Erik,

I have some questions about the processing of this erratum, which I'd 
like to ask, if anything, for the sake of transparency.

Based on the errata processing rules 
(https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/), 
it would seem that one of these two would apply:

1 Only errors that could cause implementation or deployment problems or 
significant confusion should be Verified.

[....]

2. 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. In unclear situations, small changes can be Hold for Document 
Update.

I'd argue that the erratum I filed belongs to "1.". But based on the 
result of the processing of this erratum, it would seems that you've 
considered it belongs to "2", as in the submitted erratum changing the 
intent of the specification and/or the working of the protocol. -- or, 
put another way, you seem to suggest that RFC8200 allows for EH header 
insertion/removal/mangling in any intermmediate hop that is listed in a 
Routing Header.

In that light, and for the sake of transparency and understanding the 
processing of this erratum, my questions are:

1) Is the current state of the IPv6 standard that nodes listed in a 
Routing Header can insert, remove, process, or (more generally) mangle 
with the packet structure?

2) If that's the assumption, how does IPv6 operate with respect to
AH, PMTUD, and error reporting?  Allowing intermmediate nodes (such as 
those listed in a RH) can certainly break AH, PMTUD, and (ICMPv6) error 
reporting.   Whereas nono of these core functionalities break if 
EH-mangling on the delivery path is forbidden -- as I personally think 
it is.


3) RFC8200 also contains the following text, as one of the intended 
clarifications:

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

If the argument is that nodes listed in a RH can mangle with EHs, then, 
in order for this sentence to make any sense, is your interpretation 
that the noes listed in a RH are not part of the packet delivery path?


4) The very RH is specified as:
   4.4.  Routing Header

      The Routing header is used by an IPv6 source to list one or more
      intermediate nodes to be "visited" on the way to a packet's
      destination.

Where there's no use of destination vs final destination -- indeed, this 
text implies that the "destination" is the final destination of the 
packet. In that light, why would one specific interpretation of one part 
of the current standard (RFC8200) be considered to override or take 
precedence over other parts of the standard?  And, in particular, when 
one of such parts and interpretations break several protocol mechanisms, 
and the other doesn't?

5) Based on a literal reading of RFC8200, the processing of a 
Destinations OPtions Header preceding a RH is not allowed. As such, 
should we also consider that nodes must ignore the DOH preceding a RH in 
IPv6 packets?


I believe the above should be considered a clear indication that while 
the text is precise, the intent of the original spec is in-line with the 
erratum that I have submitted. That said, at the very least a 
clarification of my questions about might help me to understand the 
processing of this erratum.


Thanks,
Fernando




On 10/5/20 15:41, RFC Errata System wrote:
> The following errata report has been rejected for RFC8200,
> "Internet Protocol, Version 6 (IPv6) Specification".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6003
> 
> --------------------------------------
> Status: Rejected
> Type: Technical
> 
> Reported by: Fernando Gont <[e-mail]>
> Date Reported: 2020-03-02
> Rejected by: Erik Kline (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
> --------------
>     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.
> 
> 
> --------------------------------------
> 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
> 


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492