Le 3 janv. 2011 à 14:20, Suresh Krishnan a écrit : > 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) No opposition AND positive support: Skipping unknown extension headers can be useful not only in FWs but also in some other places (e.g. in some variants of load balancers) As Fernando noted, FWs that do "default deny" shouldn't be concerned. However, not all FWs are necessarily default deny in the strict sense (i.e. with all fields of accepted packets having to be described) It may be useful to say, for example, "accept all incoming connections to address X and port 80" without concern for extension headers. Besides, someone, Mark Townsley I believe, described a FW behavior where: - packets known to be good are accepted - packets known to be bad are discarded - unknown packets are rate limited This is IMHO an interesting possibility that differs from just "default deny". Points b and c are more debatable. I don't find them necessary. The draft would IMHO be better without them, but I don't object. The proposed addition in the "Meta question" seems useful => +1 (But the document remains acceptable without it.) Regards RD > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
