I'm tightening up some network-edge filters, and in the process of testing filtering with IPv6, I found that there is a lot of ICMP link-local (fe80: to ff02:: activity at an IX. Is any of this necessary? I am wary of over-filtering that cuts down functionality and doesn't increase security. What of the IANA-reserved IPv6 addresses can be safely blocked on ingress/egress at the network edge?
Hey,
I'm tightening up some network-edge filters, and in the process of
testing filtering with IPv6, I found that there is a lot of ICMP
link-local (fe80:to ff02:: activity at an IX. Is any of this
necessary? I am wary of over-filtering that cuts down functionality and
Dunno, ff02::1 would be very necessary (i.e. ND), ff02:: I have no
idea. But you should do yourself favor, before you drop ICMP packets,
allow ND:
set from next-header icmp6
set from icmp-type router-solicit
set from icmp-type router-advertisement
set from icmp-type neighbor-solicit
set from icmp-type neighbor-advertisement
set from hop-limit 255
set then count icmp:nd
set then accept
It doesn't really matter how many times this is mentioned on how many
forums, people will continue to break IPV6 ND by filtering it
incorrectly. I regularly have customers complaining we've broken IPV6,
when ND stops working, due to implementation change in our end using
different combinations of GUA/LL than what their filter permits. And
customers often remain unconvinced, offering 'it works on N other
providers just fine'. IPv6 is too hard, we don't understand how ND
works.
Not that you should see it over an exchange point, but LDPv6 runs over ff02::2. In case that's your style, be careful not break that on your core-facing side.
Mark.
Hi,
You can check special ipv6 registry from to drop/filter at transit/peering connections: IANA IPv6 Special-Purpose Address Registry
Bogon IP addresses, ipv4 and ipv6 bogon IP Ranges
::/128Node-scope unicast unspecified address
::1/128Node-scope unicast loopback address
::ffff:0:0/96IPv4-mapped addresses
::/96IPv4-compatible addresses
100::/64Remotely triggered black hole addresses
fc00::/7Unique local addresses (ULA)
fe80::/10Link-local unicast
fec0::/10Site-local unicast (deprecated)
ff00::/8Multicast (Note: ff0e:/16 is global scope and may appear on the global internet.)
2001:10::/28Overlay routable cryptographic hash identifiers (ORCHID) -->depreceated
2001:20::/28Orchidv2
2001:db8::/32Documentation prefix
2001::/32Teredo
2001:2::/48Benchmarking
But you should be careful with ND & and link-local addresses like Pete mentioned. And i think it is good practice to drop IP traffic sourced with your own IP addresses against spoofing (unless you have remote sites with your own addresses etc.)
2001::/23 IETF protocol assignments, be careful with what you drop inside this block also.