Re: [Technical Errata Reported] RFC8200 (5933)

[Alexandre Petrescu <[e-mail]>]

Le 12/12/2019 à 20:32, Brian E Carpenter a écrit :
> 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.

I agree IPv6 could have been specified to support local features, and
that's where we are.  It is a positive note.

I would like to extend it with another positive note.

RH0 (Routing Header type 0) was mandated in RFC2460.  It was
subsequently used in other specs and implementations, like Mobile IPv6.
  It hurt to see it disappear in RFC8200, but there must be reasons for
that.  These reasons seem important.

Other spec and implementation trying variations of routing headers is
RPL.  It is today in the same state: no widespread deployment, has
security issues, but is rather ok in a limited domain.

I now wonder whether the SRH concepts take these reasons into account
(RFC5095ish on security of Routing Header), and lack of deployment on a
wide scale.

If not, then we risk arriving at the same situation as with RH0: spec
it, implement it, realize its lack of security and deployment, and then
get rid of it.  I do not know what are the encouraging things about SRH
such as to hope it will be better than RH0 and will not lead to an
RFC15095ish that deprecates SRH.

The idea to remove Segments Left altogether from RFC8200 is something
that could be considered.

Alex


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