Re: [Technical Errata Reported] RFC8200 (5933)

[Brian E Carpenter <[e-mail]>]

On 13-Dec-19 06:38, Fernando Gont wrote:
> 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. 

Correct, but they do exist in the real world ;-)

> SO I have no idea how
> that could/should influence RFC8200.

Actually there are a lot of IETF standards with explicit support for local
features, and there are a lot of uses of locally significant parameter
values. So IPv6 *could have been* specified to support local features,
but it wasn't. That's where we are.

    Brian

> 
> 
> 
> [....]
>>> 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,
>