Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In an effort to prevent IP Source Address Spoofing (RFC 2827) I've enabled reverse path filtering (RPF) on my Cisco ASA 5505.

The topology is aprox. like this. Each segment has its own IPv4 subnet and IPv6 subnet.

           vlan 40 |
  vlan 2           |            vlan 10
outside --------- ASA -------- inside
           vlan 30 |

I've enable RPF like this:

ip verify reverse-path interface outside
ip verify reverse-path interface inside
ip verify reverse-path interface guests
ip verify reverse-path interface dmz

On the outside interface I'm seeing some things being blocked by RPF as expected, such as:

Feb 20 2014 11:25:06: %ASA-1-106021: Deny ICMP reverse path check from <ip1> to <ip2> on interface outside

However on all other interfaces I see dozens of IPv6-ICMP events a minute, like these:

Feb 20 2014 11:27:21: %ASA-1-106021: Deny IPv6-ICMP reverse path check from :: to ff02::16 on interface guests
Feb 20 2014 11:27:21: %ASA-1-106021: Deny IPv6-ICMP reverse path check from :: to ff02::1:ff73:8762 on interface guests
Feb 20 2014 11:27:21: %ASA-1-106021: Deny IPv6-ICMP reverse path check from :: to ff02::1:ffed:4b2d on interface guests

Those IP's appear to be IPv6-multicast related, according to Wikipedia. I'm no expert in multicast.

Why are they triggering the RPF check, and what can I do about them? Is this a misconfiguration on my part or of not, can I somehow stop the flood of alerts?

share|improve this question
Do you have ICMP filtered? IPv6 relies on it to function properly. See – pauska Feb 20 '14 at 14:43
@pauska I allow all ICMPv6 through. – Martijn Heemels Feb 20 '14 at 19:58

The :: address is the unspecified address. It is not often used on the wire, but its use is allowed in certain cases. One example is specified in RFC 3810 section 5.2.13, which explains the packets to ff02::16.

Such packets don't seem spoofed and shouldn't trigger an RPF error. I therefore think this is an implementation bug in the ASA. I cannot be sure though without seeing the actual packets. It is probably a good idea to open a Cisco TAC case for this.

share|improve this answer
Interesting. I'll try to capture a few packets for you. This ASA runs on 8.4 so upgrading to a newer version may be worth trying. I usually avoid that unless there is a pressing need, but I can imagine things have improved since that version, especially in the IPv6 section. – Martijn Heemels Feb 20 '14 at 19:53

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.