Re: Next steps on Extension Header Insertion

[[e-mail]]

Fernando,

> > >> To make my point clear: I'm rather agnostic about SR, but I'm against
> > >> ambiguity in a std track documents, particularly when behind such
> > >> ambiguity there's the potential for a lot of problems.
> > >
> > > Well said. Ambiguity is harmful here and will cause serious problems later.
> >
> > There is absolutely no evidence that the lack of normative text here has led to any problems...
> 
> Because nobody before proposed or pushed into code the idea of mangling packets in the middle of the network with IPv6

That's only partly true from an IETF perspective (NPT66, TCP quick start... ), and certainly not the case if you look at the plethora of packet mangling middleboxes out there.

> > Regardless, it is also impossible to specify all the things creative people shouldn't be allowed to do. And that's probably not the purpose of standardisation either. It is to specify enough to make implementation interoperable.
> 
> If IPsec, Path-MTU, and normal troubleshooting could all break as a resultar of this, yes, we do have a say, and we should say so.
> 
> We should clearly state what the architecture is, including whether packets are meant to be end2end, or  expect anyone to do their own thing.
> 
> If I read the v6 spec, at the very least, I want to be able to tell whether I can expect that whatever I received in a packet was produced by the source, or whether it could have been produced by the network itself. Since a layer-3 protocol is supposed to be something quite simple, and such question is core to the architecture, I'd expect the spec to answer the question.
> 
> Clearly, it was obvious to everyone that intermediate systems don't mangle v6 packets  But since all this discussion seems to indicate it wasn't so obvious to everyone, the spec should make this important point very clear.
> 
> I'd say that some of the options given in the poll are rather misleading... Because truth is that as of today, header insertion is not allowed. So any discussion about "preferred way of doing eh insertion" seems like an implicit update/"relax of the spec" to me.

I fully agree with you on the architectural principles. I also think the Internet should be end to end transparent and that firewalls, NATs and other middleboxes have no place in the Internet architecture. _That_ political statement isn't for the core IPv6 _protocol specification_ though.


> > I'm just trying to point out that we shouldn't blow this issue out of proportion. Whatever we end up doing here, it is hard to see it being particularly important, nor have any big consequences.
> 
> Is that a politically-correct way of saying we're just irrelevant?

In the larger perspective we are all irrelevant. ;-)

I'm saying this is to a large degree politics. And as much as we want to put the middlebox cat back in the sack, the IETF doens't have the power to do that. Nor do I think it should.

End to end transparency has to be done by the end hosts with some sort of crypto.

Best regards,
Ole