Re: Adding headers and adding options to headers

[[e-mail]]

Brian,

> Trying to answer your specific comments concisely:

Thank you.

[...]

>> do you know of any interoperability problems with the current RFC2460?
>> that has to be the driving issue in deciding this.
> 
> Yes. Inserting extension headers breaks PMTUD. RFC2460 cites RFC1981
> as "strongly recommended" so that is normative.

Yes, that would be a valid argument if we were discussing how to design header injection.
Describing header injection in RFC2460bis is not on the table.
My argument is about what we put in 2460bis.
I believe no interoperability issue has been shown in RFC2460. Do you concur with that?

(Future specifications can of course create as many interoperability issues they like, not much we can or should do about that in 2460).

>> with regards to making prohibitions on future work in current protocol specifications, can you cite any example of the IETF being successful with that? :-)
>> 
>> RFC2460 already has this prohibition by the way:
>> 
>>   With one exception, extension headers are not examined or processed
>>   by any node along a packet's delivery path, until the packet reaches
>>   the node (or each of the set of nodes, in the case of multicast)
>>   identified in the Destination Address field of the IPv6 header.
>> 
>> I'm afraid I don't see the point in changing RFC2460 here.
> 
> The word "processed" is the problem here - it is ambiguous. That is the
> spcific reason for adding "modified or inserted".

I don't think this text is ambiguous at all.
Every network on the planet seems to violate it though, which of course is a much larger problem than the one we're talking about here.

To summarise my view:
 - There has not been shown any interoperability issues caused by the extension header text in 2460
 - Adding a general prohibitions to avoid something we dislike happening in the future, does a) not belong in 2460, b) is not testable c) is  unlikely to have the desired effect

Best regards,
Ole