Re: [Technical Errata Reported] RFC8200 (5933)

[Fernando Gont <[e-mail]>]

On 11/12/19 02:44, Alexandre Petrescu 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. 

Not sure what you mean. The errata does not mention "slow 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.
> 
> This final destination is somehow a strange concept. 

I used "final destination" to avoid confusion wrt "waypoints" in a
routing header.


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

Ńot sure where the confusion is.If you are the IP module that has been
assigned that final destination address, you are the final destination.


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

Obviously, such concepts escape IPv6. IN IPv6 you ahve IPv6 addressses
assigned to hosts or routers. How you implement them is irrelevant.



> Otherwise, I can still interpret that clarification as allowing
> intermediary nodes to insert/remove EHs.

Could you please elaborate?

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