IPv6 filtering

• ipv6 41 IPv6 # IPv6
    • ipv6-route 43 IPv6-Route # Routing Header for IPv6
    • ipv6-frag 44 IPv6-Frag # Fragment Header for IPv6
    • ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6
    • ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6
    • ipv6-icmp 58 IPv6-ICMP icmpv6 icmp6 # ICMP for IPv6
    • ipv6-nonxt 59 IPv6-NoNxt # No Next Header for IPv6
    • ipv6-opts 60 IPv6-Opts # Destination Options for IPv6

Ok filtering ipv6 and ipv6-icmp is understood, it is like ipv4.

But what about the others, should they be blocked, restricted?

Does a ios "deny ipv6 any any" affect them?

Be advised, ICMPv6 is *not* like ICMP in IPv4, and knowing what can be filtered, what to filter, and where to filter it is considerably more complex than in IPv4 - which, given the prevalence of broken PMTU-D alone, is apparently not well-understood in many quarters, heh.

Well we filter icmp due to exploits, if no exploits, then we can let the whole of icmpv6 through. Or is there something terribly dangerous in icmpv6 already?

Also, try to resist popular opinion in outright blocking of ICMP - it's
not really that evil.

~Seth

DO NOT filter IPv6 ICMP like you filter IPv4.

If you do, you will break PMTU-Discovery, Neighbor Discovery,
and RA/SLAAC, all of which depend on ICMPv6.

Owen

I may be dense, networking isn't my primary field (sysadmin).. but isn't ICMP there for a good reason? I.e. congestion control? I've always argued vehemently with PCI-DSS and similar auditors that I will not filter /all/ ICMP traffic on the border.

Paul

Ever since Cisco came out with "IPv6 Routing Header Vulnerability" in 2007
http://www.cisco.com/en/US/products/products_security_advisory09186a00807cb0fd.shtml

I have had the following enabled:

On the protected interface:
ipv6 traffic-filter filter-rh in

ipv6 access-list filter-rh
  deny ipv6 any any log routing
  permit ipv6 any any

and have stopped many pkts that way. I still occasionally see hits in our log from all sorts of newbies who continue to try old bugs.

-Hank

This can bite you in unexpected ways, too. For example, on a Cisco ASA,
if you add a system-level 'icmpv6 permit' line and if this does not
include ND, then you break ND responses to the ASA. This is much unlike
ARP, which is unaffected by 'icmp permit' statements for IPv4. And, the
default with no such lines is to permit all ICMP/ICMPv6 to the ASA. This
seems so obvious in retrospect, but at the time was a bit of a
head-scratcher.

Mark

"Recommendations for Filtering ICMPv6 Messages in Firewalls"

<http://www.ietf.org/rfc/rfc4890.txt>

Have a look at RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls.
   Regards,
     Janos Mohacsi

This can bite you in unexpected ways, too. For example, on a Cisco ASA,
if you add a system-level 'icmpv6 permit' line and if this does not
include ND, then you break ND responses to the ASA. This is much unlike
ARP, which is unaffected by 'icmp permit' statements for IPv4. And, the
default with no such lines is to permit all ICMP/ICMPv6 to the ASA. This
seems so obvious in retrospect, but at the time was a bit of a
head-scratcher.

ARP is a seperate protocol supporting IPv4 ... For IPv6 ND is done
using ICMPv6 messages. A bit confusing transitioning from IPv4/ARP
for sure.