Subject: [v6ops] RFC 4890 ICMPv6 Filtering Recommendations to BCP?

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

This is to open a discussion regarding the promotion of RFC 4890 (https://tools.ietf.org/html/rfc4890) to BCP. It is not a true working group last call; it may be a lead-in to a relatively quick RFC 4890 bis.

There are three edits that would need to be made: 
- the document states, on its title page, that it is "informational", and needs to state that it is "best current practice". 
- There is also one erratum (http://www.rfc-editor.org/errata_search.php?rfc=4890). 
- There have been several new ICMPv6 message types defined since it was written.

On the third point, I will forward a brief interchange I had with Ralph Droms.

I would like everyone, please, to read the RFC, my interchange with Ralph, and the documents he points to, and comment on three questions:

1) Do you, or do you not, agree that this document should be promoted to BCP from a status perspective? (not from a "who cares" perspective - those that care, care, and those that don't, don't).

2) Do you believe that there are additional changes that should be made in such advice, especially regarding the points Ralph raises? If so, please identify them and suggest text or support text someone else proposes.

3) On Ralph's point regarding putting filtering advice in the IANA registry (http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml), any way we record them, there needs to be guidance to the effect that RFC 4890bis needs to be updated whenever someone creates a new ICMPv6 message type. That could be done in an RFC, the indicated IANA registry, some other registry, a wiki, or something else. What is this working group's opinion on maintaining the currency of the advice?

This discussion ends on February 1. At the end of that, I hope to be able to say what the recommendations of this working group are. What we will need then, or by then, is a document editor for the indicated document.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 3 Jan 2013 08:15:32 -0800

Fred,

Something that has always bothered me about RFC4890 is the
following text of Section A.2:

   "If a network chooses to generate packets that are no larger than the
   Guaranteed Minimum MTU (1280 octets) and the site's links to the
   wider Internet have corresponding MTUs, Packet Too Big messages
   should not be expected at the firewall and could be dropped if they
   arrive."

This seems to preclude PTB messages reporting a size smaller
than 1280, which are necessary to ensure proper operation of
IPv6, e.g., per the final paragraph of RFC2460, Section 5.

My recommendation is that the RFC4890, Section A.2 text be dropped
when preparing the (bis) version for publication as a BCP.

Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fred Baker (fred)
> Sent: Tuesday, January 01, 2013 11:00 AM
> To: [email-masked]
> Subject: [v6ops] RFC 4890 ICMPv6 Filtering Recommendations to BCP?
> 
> This is to open a discussion regarding the promotion of RFC 4890
> (https://tools.ietf.org/html/rfc4890) to BCP. It is not a true working
> group last call; it may be a lead-in to a relatively quick RFC 4890 bis.
> 
> - the document states, on its title page, that it is "informational", and
> needs to state that it is "best current practice".
> I would like everyone, please, to read the RFC, my interchange with Ralph,
> and the documents he points to, and comment on three questions:
> 
> 1) Do you, or do you not, agree that this document should be promoted to
> BCP from a status perspective? (not from a "who cares" perspective - those
> that care, care, and those that don't, don't).
> 
> 2) Do you believe that there are additional changes that should be made in
> such advice, especially regarding the points Ralph raises? If so, please
> identify them and suggest text or support text someone else proposes.
> 
> 3) On Ralph's point regarding putting filtering advice in the IANA
> registry (http://www.iana.org/assignments/icmpv6-parameters/icmpv6-
> parameters.xml), any way we record them, there needs to be guidance to the
> effect that RFC 4890bis needs to be updated whenever someone creates a new
> ICMPv6 message type. That could be done in an RFC, the indicated IANA
> registry, some other registry, a wiki, or something else. What is this
> working group's opinion on maintaining the currency of the advice?
> 
> This discussion ends on February 1. At the end of that, I hope to be able
> to say what the recommendations of this working group are. What we will
> need then, or by then, is a document editor for the indicated document.
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Sander Steffann <[email-masked]>
Date: Thu, 3 Jan 2013 17:26:19 +0100

Hi,

> when preparing the (bis) version for publication as a BCP.

+1

This advise will cause problems with (atomic) fragment requirement in RFC2460 section 5, so it should not be in a BCP.
Sander