Re: [Technical Errata Reported] RFC8200 (5933)

[Fernando Gont <[e-mail]>]

On 12/12/19 05:12, Alexandre Petrescu wrote:
[....]
>>>
>>> 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.
> 
> Right.
> 
> That means that a new item could be part of the list of limited domains
> (currently Enterprise and Computer Farm). 

THere's no IETF consensus for limited domains. SO I have no idea how
that could/should influence RFC8200.



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

We could do that, and then only comment on the "processing" bit for the
various Extension Headers.


> 
>> 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
>                                               ^^ other: any _other_ node
>> 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.
> 
> I agree.  That is a typical requirement following from the Smart End
> Dumb Network principle.  It is also told as "packets are not modified
> en-route, with the only exceptions of decrementing the Hop Limit field,
> and the Segments Left field if present".
> 
> One example that modifies packets en-route is the modification of the
> src address.  This is forbidden.

HOw is this related to what we're discussing?




> Another example that does not modify packets en-route, but creates other
> packets by incorporating the untouched orignal is the ESP encapsulation
> of VPN Gateways.  This is allowed.

That's encapsulation. We're talking about EH
insertion7removal/processing here.

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