Re: SRH insertion vs SRH insertion + encapsulation

[Fernando Gont <[e-mail]>]

On 9/9/19 21:49, Ole Troan wrote:
> Dear Ron,
> 
> I think we both have used up our posting quota for long into next year, but I'll one more on this topic.
> 
>> There is a big difference between translating a packet’s source/destination address and adding something to a packet. The best way to explain this difference is with an analogy.
>>  
>> Assume the following:
>>  
>> 	• I, Ronald, am conversing with an Italian speaker through a translator
>> 	• I say to the Italian speaker, through the translator, “your shoe is untied”
>>  
>> It is OK for the translator to tell the Italian speaker, “Aldo says that your shoe is untied”. He has translated my name into Italian, but not changed the message.
>>  
>> It is not OK for the translator to tell the Italian speaker, “Aldo says that your shoe is untied, and that you are ugly “.  If he were to do that, he would be originating a message and attributing it to me.
> 
> Translating the source address and/or destination address on the Internet is of course much worse than if a header inserted packet leaked.
> Translation breaks fundamental parts of the Internet architecture, which has shaped the unidirectional centralized network we have been forced into today.
> 
> I do think you are attacking a strawman though. I don't think many, apart from Fernando is talking about changing 8200. I.e the ground rules for end to end IPv6.

My argument is: let's call a lemon a lemon. Inserting EHs does break the
end-to-endness of IPv6.

If you want to do it, I'd expect:

1) A proposal that argues what problem they want to solve, and why they
don't solve it in a standards-compliant manner. You seem to imply that
"we have to allow EH-insertion of some sort", whereas I think the first
question is "should we, really?"

2) A document that, at the very least, contains an "Updates: RFC8200"
tag, such that the reader of RFC8200 is pointed to the document from
item "1)" above. As noted above, if you do "1)", you should really
change the text in RFC8200 such that s/must not/should not/.  If RFC8200
represents the consensus on the topic, and you want to deviate from
that, at the bare minimum your document should "Updates: RFC8200".

And to clarify the above: RFC8200 represents IETF consensus on this
topic. This is the reason why RFC8200 -- not because it's a sacred
document.

Besides, I will note that have always been keen to updating standards,
where deemed necessary. And when I've authored document, I've been
generous in including the "Update:" tags that would apply (see RFC8064,
for instance)



> The only realistic option for "header insertion" is within a limited domain.

I don't think we have "flavors" of IPv6 -- that, by itself, would be a
shift in the architecture. But in any case, I think this EH-insertion
thing (whether in a limited domain or not) would seem to me like out of
the scope of 6man.

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