<p><br>
On Aug 5, 2012 8:00 PM, &quot;Doug Barton&quot; &lt;<a href="mailto:dougb@dougbarton.us">dougb@dougbarton.us</a>&gt; wrote:<br>
&gt;<br>
&gt; On 08/03/2012 05:39, Benedikt Stockebrand wrote:<br>
&gt; &gt; yes, in some cases you may want to filter e.g. routing headers and<br>
&gt; &gt; such.<br>
&gt;<br>
&gt; Do you have references to this issue?<br>
&gt;</p>
<p><a href="http://tools.ietf.org/html/rfc5095">http://tools.ietf.org/html/rfc5095</a></p>
<p>&gt; &gt; More generally speaking, with new ICMP6 types possibly coming<br>
&gt; &gt; up you may want to whitelist rather than blacklist individual ICMP6<br>
&gt; &gt; types/codes.<br>
&gt;<br>
&gt; This is the opposite of what should be done, for 2 reasons. First, you<br>
&gt; should only blacklist things you know you&#39;re having problems with.<br>
&gt; Second, but taking the approach you suggest you miss out if the protocol<br>
&gt; changes and you don&#39;t update your filters.<br>
&gt;<br>
&gt; The whole concept of blanket ICMP restrictions in v4 was bad, doing it<br>
&gt; for ICMPv6 is really bad.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt;     I am only one, but I am one.  I cannot do everything, but I can do<br>
&gt;     something.  And I will not let what I cannot do interfere with what<br>
&gt;     I can do.<br>
&gt;                         -- Edward Everett Hale, (1822 - 1909)<br>
</p>