On Wed, 16 Jul 2014, Joe Touch wrote: JT> I'm including INTAREA in the discussion because this doc seems to be an JT> end-run around intending to deprecate IPv6 HBH options, or at least to JT> redefine the option behavior bits defined in RFC 2460. IMO, that ought to be JT> addressed in INTAREA, not V6OPS.
I think this would be within the purview, not of INTAREA, but of 6MAN, which, as noted by Brian Carpenter earlier in this thread, has recently spoken the subject: On Mon, 14 Jul 2014, Brian E Carpenter wrote: BEC> In fact, RFC [7045] changes that: BEC> BEC> > 2.2. Hop-by-Hop Options BEC> > BEC> > The IPv6 Hop-by-Hop Options header SHOULD be processed by BEC> > intermediate forwarding nodes as described in [RFC2460]. However, it BEC> > is to be expected that high-performance routers will either ignore it BEC> > or assign packets containing it to a slow processing path. BEC> BEC> You could s/must/should/. BEC> BEC> More important: BEC> BEC> > 2.3.1.5. Advice BEC> > BEC> > Intermediate systems should, by default, drop packets containing a BEC> > IPv6 Hop-by-Hop Option Extension Header. BEC> BEC> You can't say that! Firstly, RFC 7045 makes it permissible to BEC> simply ignore them. That's the simplest DoS defence. Secondly, BEC> well, dropping them is the wrong default because it breaks stuff. BEC> You could discuss whether to inspect them for valid contents, and BEC> you could discuss rate-limiting, which I understand some vendors BEC> support already. JT> IMO, the real DOS attack here is twofold: JT> JT> 1) vendors who misrepresent their boxes as IPv6-capable JT> at a given packet rate JT> JT> 2) documents, such as this, JT> that invert the Postel Principle into the Gont Principle: JT> JT> - Postel Principle: JT> Be conservative in what you send JT> and liberal in what you receive. JT> JT> - Gont Principle: JT> Be paranoid in what you receive. JT> JT> Just because you receive something you didn't expect, does NOT make it an JT> attack. JT> JT> I sincerely hope there are others who share this view, or we might as well JT> just go straight to the conclusion that IPv6 routers that can't process JT> 128-bit addresses really ought to be OK just forwarding based on the last 32. I've complained before about "default deny" bias harming the internet, and so have many others. It is a real problem. And it appears that both of the factors you mention are responsible for large-scale dropping of packets with IPv6 fragment headers in today's Internet. That being said, it is a different and more hostile Internet than in Postel's day. Under the Postel Principle, something useless but harmless (w.g., the IPv4 stream ID option) would be ignored; nowadays, you will probably find consensus that it is OK, or even desirable, to block things like that. In fairness to Mr. Gont, this draft is MUCH better that the initial versions of the corresponding IPv4 options filtering document. Even it I don't agree with all of them, the filtering recommendations in this draft do seem to motivated by legitimate operational concerns, not blanket paranoia. I think we should move further discussion back to OPSEC and V6OPS. //cmh _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
