On 25/05/2013 00:40, John Leslie wrote: > Ray Hunter <[email protected]> wrote: >> I would also like to see some text on whether it is possible/desirable >> for a middleware box to strip unknown headers, or even some known >> headers, rather than making a binary decision to drop or transmit the >> entire packet. If (new) headers are truly optional or experimental, the >> residual stripped packet may still have value e.g. stripping hop by hop >> extension headers on entry to/ egress from a corporate network or >> transit AS. That way the (new) extension headers could be usefully >> deployed in an AS that supports them, but the end to end traffic would >> not be blocked further along the path by firewalls in an AS that does not. > > I had a similar thought -- even going so far as to posit a way to > notate that a header had been stripped... > > I think the answer is we don't want to do that in this document; > nonetheless some folks are likely to try it. I think a mention of the > issue, and a reference to RFC(s) stating the current rules, would help.
What rules? As far as I know, no such mechanism is defined or allowed, so there is nothing to refer to. I would object (as a WG participant) to even mentioning such a mechanism. (As a document editor, I would of course edit the document according to WG consensus.) > > (The prime purpose of this document is creating an IANA registry; > that purpose should not be clouded by discussion of what firewalls > "should" do.) Not so. The prime purpose of this document is to make extension headers useable. The registry is a means to that end; describing precisely how middleboxes should treat them is another means to that end. We can make that clearer in the text, of course. Describing how middleboxes might block or destroy them is antithetical to the purpose of the document. That's why Ray says "I'm not sure the current text is entirely balanced in this respect." He's right. Again speaking as a WG participant, I'm happy with that. On 25/05/2013 02:43, Tim Chown wrote: > A couple of additional comments. > > One is that from time to time there may be security issues raised with > certain headers, e.g. RH0. These may obviously be raised over time. Is there > a mechanism to catch these in the IANA registry somehow? Shouldn't this just be part of the Security Comsiderations for the definition of each header? The registry will always contain a pointer to the relevant RFCs. IANA can't do much if the Security Considerations are insufficient. > Another is whether there is any use of the "null" header type 59? Or has > that been deprecated? If not, should it be so, given Brian doesn't list it. > Or is this viewed in the same category as TCP, etc as header types? I think we included that in an earlier draft, but then removed it because it appears to function as a null transport header. It's a judgment call, and only needs a few keystrokes to put it back in the list. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
