Re: IPv6 header insertion in a controlled domain

[Alexandre Petrescu <[e-mail]>]

Le 08/12/2019 à 17:10, Joel M. Halpern a écrit :
> Ole, as far as I can tell, to answer the apparently simple quesiton you 
> propose "is there a s safe way to do header insertion?" we would need
> o a clear definition of the domain in which it is to be done

In that direction, I think there could be two distinct kinds of domains 
that would denote a limited domain:

- an Enterprise network.

- a single large computer with numerous virtual nodes.

In each of these the EH insertion/deletion might not disturb the 
Internet at large.  The sentinels could be DMZs or 'air gaps'.

Alex

> o a clear definition of the participants
> o and a full re-examination of the discussion which led to the 
> prohibition against doing so in RFC 8200
> 
> We do not have in front of us a document which achieves either of the 
> first two bullets. Without that, it is very hard for us to perform the 
> third bullet.
> 
> I note for example that the presentation in Sngapore did not disucss the 
> implications or behaviors of hosts inside the Segment Routing v6 domain. 
>   But the rfc-to-be explicitly includes hosts inserting the information 
> in the original header.
> the presentation in Singapore did not discuss how SR header creators 
> will deal with errors caused by in=-path header insertion, when the 
> errors arrive at places that did not perform the insertion.
> 
> But there is a more important issue.  The usual IETF practice (not the 
> rule, but a practice we have found to be good) is to ask what problem is 
> being solved BEFORE we evaluate solutions.  There are many good reasons 
> why we have found this helpful.  You seem to be asking for the opposite.
> 
> I find myself forced to repeat my question:  what benefit is header 
> insertion bringing to justify working group consideration.
> I understand your earlier request not to repeat points.  But for me at 
> least, it is very hard to answer your question without that.
> 
> Yours,
> Joel
> 
> On 12/8/2019 4:24 AM, [e-mail] wrote:
>> Mark,
>>
>> [...]
>> [renamed thread]
>>
>>> Take an example of 3 routers A, B and C that is under the same control.
>>> Traffic travels from left to right.
>>>
>>> A -- B -- C
>>>
>>> A has a tunnel to C using ULA source and destination.
>>> A packet ingresses on A, is encapsulated and forwarded towards C.
>>> A has for reasons unknown to us outsourced a function to B. Where B 
>>> insert an extension header in the packet originated by A.
>>> C is also in on the game, being a tunnel end-point, removing the 
>>> encapsulating header and extension header.
>>>
>>> If you can leave the nuances of SR and the whatever they propose on 
>>> the shelf for a minute.
>>>
>>> Do you agree in principle that this approach of "header insertion in 
>>> a controlled domain" can be made to work,
>>> and should be indiscernible from A inserting the extension header 
>>> itself?
>>
>> Yes, there are obviously many ways of skinning this cat.
>> In this thread I don't want to try solve whatever problem the EH 
>> insertion camp wants solved. I don't think I understand it well enough.
>> And I'm unconvinced the 6man group in general understands the 
>> underlaying routing problems leading to the proposed solution.
>> What I was interested in exploring in this thread was if we could 
>> reach agreement that there in principle is a safe way of doing header 
>> insertion.
>>
>> In my simple example above.
>> Do you agree that in a controlled distributed system there is no 
>> perceivable difference between node A inserting the header or node B 
>> doing it?
>> Conceptually you could think of it as a tunnel with muliple endpoints 
>> (although that's a bit hard to visualize ;-)).
>>
>> Can we agree that inserting headers and changing the packet size among 
>> participating nodes in a distributed system is not inherently unsafe?
>> As far as I can think of the only complication to be considered is 
>> that node A must be aware of packet size changes when doing PMTU 
>> estimation.
>> (typically though in these types of networks, one simply declares that 
>> "MTU must be well managed. i.e. large enough".
>>
>> Cheers,
>> Ole
>>
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------