Joel, > There are two separate but related issues here. One is what behavior we want to require. The other is whether we make the document clear. > > I think choosing to leave a document going to Internet Standard ambiguous is a serious mistake, bordering on failure. We know that the choice of permitting insertion of extension headers has interoperability implications. There are weveral ways we can clarify the text. > o We could say "MUST NOT" be added. Preferably with explaantion of the problems being avoided. Yes. > o We could say "MUST NOT unless some other standards track RFC says it is okay" which is technically correct but confusing. That's redundant. A new standards RFC can always be written that will override this. > o We can say "SHOULD NOT unless ..." as long as we can write a clear description of the conditions under which it is safe. As the 6man chair we declared that as out of scope in the context of advancing 2460 to Internet standard. > o We can say "AMY< but note that doing so has the following risks" if that is the IETF rough consensus. Middleboxes live in unregulated territory, there was no support (or even suggestion) in the working group for explicitly permitting header insertion. > But leaving it ambiguous ought to be a non-starter. Why? Leaving it as it was, including describing what we would imagine it would break was the preferred solution in the working group. Note that both IPv4 and IPv6 has this so-called ambiguity, that has caused no known interoperability issues and has existed for decades. This is perceived as an ambiguity only because we as a community have accepted layer violations for so long. This can be exemplified by discussions on maximum extension header length in IPv6. The only reason that discussion happens is because middleboxes require access to the transport header and beyond. In a purist 2460 view a router doing 5-tuple ECMP is not compliant with the specification. Clarifying that ambiguity would probably not make the operational community proud of us. The only purpose an outright ban would achieve, would be a pre-emptive strike against potential future standardisation. So when you think long enough about it, which choice you pick will unlikely have much consequence either way. It has no effect on implementations, it is not testable. In the context of 2460 this isn't a debate with many technical points. Which is why the working group could not reach a consensus, and we ended up decided it with a poll. Do you prefer your bike shed red, yellow or green. You have added a couple of more colours. > Personally, I would go with "MUST NOT", as I think that is the robust and interoperable answer. But that is MUCH less important to me than our being unambiguous. There is an infinite set of creative (ab)uses of 2460 that hasn't been banned. I would claim it would be impossible to write a document which would MUST NOT every potential abuse. Best regards, Ole
Attachment:
signature.asc
Description: Message signed with OpenPGP