Re: [Technical Errata Reported] RFC8200 (5933)

[Tom Herbert <[e-mail]>]

On Tue, Dec 10, 2019 at 11:44 PM Alexandre Petrescu
<[e-mail]> wrote:
>
>
>
> Le 11/12/2019 à 04:27, RFC Errata System a écrit :
> > 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/eid5933
> >
> > --------------------------------------
> > 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
> > --------------
> >     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,
>
> packet delivery path, slow path... two very distinct concepts.  One is
> in the network with real cables, the other is in a chip or on a bus with
> copper on a printed board.
>
> >    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.
>
> This final destination is somehow a strange concept.  It can be a
> computer node that owns several addresses.  But this is difficult with
> virtualization.  Owning one address is difficult to prove as well.
>
Agreed. This could also be contorted to mean that the lower part of
the stack in final destination node might be allowed to insert
extension headers in a packet before delivering to the application. I
think it's more direct to simply say that inserting or removing
extension headers is not allowed at any node. A source node creates
packet with them, it doesn't insert them. Similarly, the final
destination discards extension headers after processing them as part
of the normal terminal processing of the packet, it doesn't remove
them.

I suggest this 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, and the length of any
extension header must not be changed, 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.

Extension headers (except for the Hop-by-Hop Options header) must not
be 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 including 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 must not
processed 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."

> In that sense, it would help to clarify the concept of 'final
> destination' by maybe using a tight relationship between an IP address
> and an identifier of a node.  Such an identifier could be a number in
> the BIOS, or something from a TPM or HSM (trust modules).
>
> Otherwise, I can still interpret that clarification as allowing
> intermediary nodes to insert/remove EHs.
>
> Alex
>
> >
> > * 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
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------