Hi Folks, As some recent mails indicated there does not seem to be consensus on some parts of this draft. I would like to see what the wg feels (now) before proceeding any further with this draft.
The draft contains three independent components a) Specifying a uniform format for all future IPv6 extension headers to make them easier to parse/process. b) Requesting a single IP protocol number codepoint for all future extension headers and multiplexing them using a Specific Type field inside the generic header. c) Specifying error-handling and drop behavior for dealing with unknown extension headers. From what I have seen there seems to be no opposition to a) but there is for b) and c). I will try to (loosely) summarize the viewpoints on b) and c) and see if we can agree on what to do about them. b) was added due to wg feedback =============================== Pros: 1) Allows middleboxes to differentiate between unknown extension headers and unknown transport protocols 2) Reduces the strain on the protocol number space Cons: 1) Uses up one protocol number even if no now extension headers are ever defined 2) Any new extension header (including this one) will break existing silicon. c) was added due to the decision reached at the IETF79 wg meeting ================================================================= Pros: 1) Allows flexible handling behavior for dealing with unknown headers Cons: 1) Violates RFC2460 2) Duplicates the functionality provided by Destination options 3) Unnecessary META-question ============= RFC2460 allows the use of both extension headers and options to convey optional information, I would like to add some text into this draft suggesting that destination options are the preferred mechanism of doing so (since they offer better backward compatibility). Something like "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. The request for allocation of a Specific Type value MUST be accompanied by an specific explanation of why destination options could not be used to convey this information." Would this be an acceptable thing to add here? I would appreciate the WG's opinion on these issues/questions before going forward with this draft. Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
