Re: [Technical Errata Reported] RFC8200 (5933)

[Fernando Gont <[e-mail]>]

On 11/12/19 10:50, Tom Herbert wrote:
[.....]
>>>
>>> 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's already used in other parts of RFC8200, albeit inconsistently.


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

What matters is IPv6. What sources IPv6 packets is the origin IPv6
module, and the destination of IPv6 packets is the IPv6 module at the
final destination.



> I
> think it's more direct to simply say that inserting or removing
> extension headers is not allowed at any node. 

Yep, that's possible. FWIW, I reused as much of whats in RFC8200 as
possible.

The key is that since the phrase also includes "process", it can be
phrased as you suggest -- unless you unfold it in "insert or delete" and
"process", as you seem to suggest.




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

The text looks fine. I just hope that folks don't claim that, since the
EH-specific text only forbids "processing", insertion and deletion is
allowed (even when the catch-all text above says they cannot).

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