Subject: Re: [v6ops] Promoting RFC 4890

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 1 Jan 2013 19:02:45 +0000

A thread between the chairs and the IESG, and a specific comment from Ralph that needs to be addressed.

On Dec 28, 2012, at 2:39 PM, Ralph Droms <[email-masked]> wrote:
> On Dec 28, 2012, at 3:53 PM, "Fred Baker (fred)" <[email-masked]> wrote:
>> On Dec 28, 2012, at 6:29 AM, Ralph Droms <[email-masked]> wrote:
>>> 
>>> Fred - there will likely be discussion about ICMP types that have been assigned since RFC 4890 was published and that are not mentioned explicitly in RFC 4890:
>>> 
>>> 154    FMIPv6 Messages            [RFC5568]
>>> 155    RPL Control Message        [RFC6550]
>>> 156    ILNPv6 Locator Update Message    [RFC6743]
>>> 157    Duplicate Address Request    [RFC-ietf-6lowpan-nd-21]
>>> 158    Duplicate Address Confirmation    [RFC-ietf-6lowpan-nd-21]
>>> 
>>> My personal opinion is that the current text in RFC 4890 covers these types; e.g.:
>>> 
>>> 4.4.5.  Traffic That Should Be Dropped Unless a Good Case Can Be Made
>> 
>> Implicit in that assumption is a model of the network. I would expect that if an ILNP host changes its locator, it will want its peer to know. Filtering that message breaks ILNP as much as filtering "too big" breaks PMTU. Filtering a DAD request or response makes it possible to have undetected duplicate addresses - assuming the 6lowpan network straddles a firewall. Personally, I think I would err on the side of preserving them unless a case can be made, not dropping them unless a case can be made. I might give guidance on how that case might be made; if no 6lowpan domain crosses a firewall, dropping the 6lowpan messages is probably a reasonable security precaution.
> 
> OK, then it seems there should be a discussion of the new options with updates in 4890bis.
> 
>>> Thinking orthogonally (and in an admittedly process-heavy way), would it make sense to consider, instead, an update to the registry and process that encodes the RFC 4890 filtering classification?  
>> 
>> Are you talking about http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml? It's a registry for ICMP messages, but doesn't encode filtering recommendations. I could imagine adding a table with references ("MAY" or "SHOULD NOT" be filtered, mitigating issues, RFC reference), and asking the working groups that designed those messages to offer operational guidance on filtering them in appropriate RFCs. I'd be a little concerned about the volume of text implied in summarizing a 38 page RFC into a table.
> 
> I'm thinking of a 4890bis that retains the explanations of the recommendations, adds the filtering recommendations to the icmpv6-parameters registry, and requires future additions to the registry to include a justified filtering recommendation to be included in the registry.
> 
>> We're now getting into the discussion that v6ops proposes to have in January.
> 
> Understood.  In my opinion, the document needs at least the review of the more recent options in addition to the errata and new boilerplate, all of which really ought to have WG discussion.
> 
>> BTW, it's not entirely accurate to say that v6ops has developed a consensus towards advancing RFC 4890; several of us are in favor of doing so, and Lee thinks it's a pointless activity, but we have not actually measured the degree to which we have consensus.  What I plan to do is host a discussion on the list in january asking everyone to read the document and comment on it.
> 
> Returning to the registry briefly, if RFC 4890 has been useful, I see a need for a way to update the filtering rules for new ICMP types.
> 
>> I could imagine a survey monkey poll to get specific levels of support on different recommendations...
> 
> - Ralph
> 
>