Re: IPv6 header insertion in a controlled domain

[Fernando Gont <[e-mail]>]

On 8/12/19 06:24, [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.

That's a good thing. If you don't understand the problems that folks
argue in order to do EH insertion solved, that's an indication that we
should stay safe, and stick to consensus.

In fact, I'd believe that it's quite interesting that we're even
bothering to talk about EH insertion when the folks proposing it didn't
even bother to do a proper analysis, and argue why they need it, and why
the problem can't be solved in any other way.


Datapoint: As a measure of process fairness: when we were doing RFC7217,
we were kind of required to do RFC7721 in order to eventually do
RFC8064. (and we were talking about a host-local policy thing).

So it is quite nice to see that now you are open to screw up the
architecture just because a big vendors wants it, with the only
rationale for doing it, "the operator community want it".

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