On 09/25/2014 01:39 PM, Joe Touch wrote: >>> In every statement where an existing IPv6 required capability is changed. >>> >>> E.g.: >>> - demotes requirements to "SHOULDS" (most x.x.x.5 sections). >> >> They are lowercase shoulds. And not protocol changes, but operational >> advice. > > I see no utility to a BCP that makes operational recommendations without > qualifying them in RFC2119 language.
Yes, the document track should be changed to Informational, as suggested by Brian. > Further, this doc does not explicitly indicate the distinction between > upper and lowercase of the RFC2119 terms. It's the uppercase that are special, not the lowercase. There's a single bogus RFC2119 usage that needs to be changed to lowercase.. and that's it. >>> - deprecates the flags in HBH options intended to declare how an option >>> is handled when not known by providing advice specific to each option >>> type that does not consider the flag setting >> >> The advice in this I-D essentially mimics RFC7045 for options. That was >> the intent. Am I missing something? > > The places where you provide contradictory advice, notably (from 7045): > > RFC 2460 requires destination hosts to discard packets containing > unrecognised extension headers. However, intermediate forwarding > nodes SHOULD NOT do this, since that might cause them to > inadvertently discard traffic using a recently standardised extension > header not yet recognised by the intermediate node. The exceptions > to this rule are discussed next. Looks like you've decided to ignore the next paragraph, which says: If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. This means that the discard policy for each standard type of extension header MUST be individually configurable. The default configuration SHOULD allow all standard extension headers. and also ignore the Security Considerations, which says: These changes do not affect a firewall's ability to filter out traffic containing unwanted or suspect extension headers, if configured to do so. However, the changes do require firewalls to be capable of permitting any or all extension headers, if configured to do so. The default configurations are intended to allow normal use of any standard extension header, avoiding the connectivity issues described in Sections 1 and 2.1. draft-gont-opsec-ipv6-eh-filtering provides configuration advice, *not* a default policy or the like (and this is pretty clear in the Intro). So it doesn't go against RFC7045. For instance, that was the main/sole goal of the latest rev of the I-D Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
