Apologies for the long delay in answering: Comments below - updates in new -01 version appearing shortly. /Elwyn Rémi Denis-Courmont wrote:
RFC2463 explicitly requires that undefined informational messages are silently dropped. Responding to error messages with an error message would not be clever. There are a couple of other cases where it might be possible, but on due consideration, I think that, on security grounds, dropping is the right answerLe Mercredi 26 Avril 2006 21:58, vous avez écrit :Per the WG decision in the meeting last month, I am opening a working group last call on the filtering document http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6- filtering-recs-00.txt "Best Current Practice for Filtering ICMPv6 Messages in Firewalls"A few minor notes:1/ The specification does not seem to consider what should be made with filtered packets, and seems to assume they will be dropped. In some case (such as the _currently_ undefined ICMP codes), it might be nicer, so long as the local policy permits, to cause the firewall to craft an Administratively prohibited error or something like that (à la “ip6tables -j REJECT”), maybe... though I guess some kind of rate limiting would obviously be required in that case.
2/ When I see sample rules like these: “ # Deny icmps to/from link local addresses ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP”... I'm becoming worried that the forwarding/routing software from Linux IPv6 stack actually let this packets through by default (particularly the first rule). I'm pretty sure the first one is redumdant, and I hope the second one is also. That's not to say firewall admin should not use them for the sake of verbosity and/or quietness of mind, but it might be worth adding a comment that these are already sort of built-in.
Done.
By the way, if anyone can confirm that these rules are actually redumdant...I don't think this requires any action. The draft recommends never dropping Echo Requests or Echo Responses.3/ I believe filter Echo requests is fairly lame, and I did complain that Teredo needs it to work at all. Now Teredo is mentioned and Echo requests were promoted from "Should not be blocked" to "Must not be blocked" :) Some other yet-to-be-defined protocols/schemes might also rely on incoming Echo requests to not be firewalled, and I surely hope not so many company and SOHO firewalls will block IPv6 echo requests, as IPv4 echo requests.... but as far as Teredo is concerned, only Echo requests coming from the Teredo prefix (2001:0::/32) needs to be passed (and of course Echo replies, only the other way).
/Elwyn
Regards,