Re: [Technical Errata Reported] RFC8200 (6003)

[Fernando Gont <[e-mail]>]

FYI.

This addresses an unaddressed bug in the previous errata I had submitted.

Thanks,
Fernando




On 2/3/20 18:00, RFC Errata System wrote:
> The following errata report has been submitted for RFC8200,
> "Internet Protocol, Version 6 (IPv6) Specification".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6003
> 
> --------------------------------------
> Type: Technical
> Reported by: Fernando Gont <[e-mail]>
> 
> 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.
> 
> 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
> 


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