The following is a functional solution to emulate IPv6 Router Advertisement (RA) Guard (rfc6105) from rogue routers on a per interface basis, similar to how DHCP snooping works for IPv4.

The following document is most probably the best I came across whilst trying to find something to explain why we were after this feature. Key take aways;

• You should filter IPv6 RAs, even if you don't run IPv6
• I believe the following to eloquently be compliant with the 'original' RFC (6105)
• My understanding of the superseding RFC (rfc7113) simply required the bridge filter rule to be a logging rule. We throw away the entire packet based on ipv6-multicast destination and MAC address, irrespective of fragmentation
• Commands work on both RouterOS 6.49.6 and 7.5

Reference links;

• https://zivaro.com/securing-ipv6-on-a-l ... ss-network
• https://www.rfc-editor.org/rfc/rfc6105
• https://www.rfc-editor.org/rfc/rfc7113

The following was vetted on a MC-LAG pair of CRS354-48G-4S+2Q+ devices and CRS326-24G-2S+ access switches. The CRS354 were running RouterOS 7.5 and the CRS326 were running RouterOS 6.49.6. The core comprised of two CRS354 switches where these had a distributed LACP between them, downstream CRS326 were single units where two ports on that router uplinked to a port on each CRS354. The topology of the MC-LAGs running to each leaf essentially follows the following structure:




IPv6 Router Advertisements are sent in two ways, the first via a periodic (random interval as long as 5 minutes) multicast announcement to the 'all nodes' address and the second via a unicast response to a router receiving a multicast announcement from a client device where this sent to the 'all routers' address. The following filters include a list of interfaces on the routers from where not to learn IPv6 prefixes or gateways. Router Advertisements ingressing via a non-trusted port (to borrow from the DHCP snooping terminology) would be redirected to the CPU, which then lets the input bridge filter rule drop the message whilst logging it. Router Solicitations ingressing via a non-trusted port would be redirected to egress via a statically configured uplink interface.

NB: It's not currently possible to create switch rules to egress a packet via multiple uplink interfaces, ether23 was chosen but we would really like MikroTik to expand on this capability, at least for multicast packet delivery.

The result is that whilst a rogue IPv6 RA could lurk on the network, it should never receive a router solicitation message nor be able to propagate a router advertisement message on a periodic basis.


IPv6 All nodes multicast address: ff02::1 destination MAC: 33:33:00:00:00:01
IPv6 All routers multicast address: ff02::2 destination MAC: 33:33:00:00:00:02


In the following example a 24 port CRS326 has ether23 and ether24 configured as a LACP uplink (trusted) bond interface. We subsequently include all other ethernet interfaces to apply filtering on:
Wish list:

• Perhaps MikroTik could possibly integrate this by allowing bridge port members to have an option to enable 'IPv6 RA Guard'.
• Allow dynamic interface membership by adding/removing active bond interfaces as bridge port members
• Allow the packet to be forwarded out multiple interfaces, possibly on an active/backup basis depending on port status?