On 05 Jan 2011, at 05:12 , Suresh Krishnan wrote: > I'm up for it :-). In fact I already suggested the meat in > > http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html > > "RFC2460 allows the use of both extension headers and destination options in > order to encode optional destination information in an IPv6 packet. The use > of destination options to encode this information, provides more flexible > handling characteristics and better backward compatibility than using > extension headers. Because of this, implementations SHOULD use destination > options as the preferred mechanism for encoding optional destination > information, and use a new extension header only if destination options do > not satisfy their needs.
I apologise that I was not clear enough in my note yesterday. I was looking for something different from the text above. Specifically, I'm suggesting a 1 page (plus boilerplate) draft that has both less text and slightly different text. Here are the 3 key points that I'd like to see: A) Prohibiting new IPv6 Extension Headers outright, as Joel has repeatedly suggested. This removes the narrow case where RFC-2460 allows Extension Headers, so the I-D would be an Update to RFC-2460. B) Mandating use of existing IPv6 headers instead in all cases. Obviously, the Destination Options Header is preferred as it has the least impact on the transit infrastructure. (Remi gave an example yesterday that probably belongs as a new "Routing Type" for the existing IPv6 Routing Header.) C) No definition of any new IPv6 Extension Header, as per (A). Yours, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
