Community discussions

MikroTik App
 
bbs2web
Member Candidate
Member Candidate
Topic Author
Posts: 232
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

[SOLVED] CRS - Hardware offloaded bridge with IPv6 RA guard

Wed Oct 19, 2022 12:21 am

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;
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:
Image



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:
/interface ethernet switch rule
  add comment="Redirect IPv6 - Multicast - All nodes (eg Router Advertisement):" dst-address6=ff02::1/128 \
    dst-mac-address=33:33:00:00:00:01/FF:FF:FF:FF:FF:FF mac-protocol=ipv6 ports="\
    ether1,ether2,ether3,ether4,ether5,ether6,ether7,ether8,ether9,ether10,ether11,ether12,ether13,ether14,\
    ether15,ether16,ether17,ether18,ether19,ether20,ether21,ether22" redirect-to-cpu=yes switch=switch1
  add comment="Redirect IPv6 - Multicast - All routers (eg Router Solicitation):" dst-address6=ff02::2/128 \
    dst-mac-address=33:33:00:00:00:02/FF:FF:FF:FF:FF:FF mac-protocol=ipv6 new-dst-ports=ether23 ports="\
    ether1,ether2,ether3,ether4,ether5,ether6,ether7,ether8,ether9,ether10,ether11,ether12,ether13,ether14,\
    ether15,ether16,ether17,ether18,ether19,ether20,ether21,ether22" switch=switch1
/interface bridge filter
  add action=drop chain=input comment="Drop - IPv6 - Router Advertisement:" dst-mac-address=33:33:00:00:00:01/\
    FF:FF:FF:FF:FF:FF log=yes mac-protocol=ipv6

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?
 
andrejpodzimek
just joined
Posts: 2
Joined: Mon May 01, 2023 10:45 pm

Re: [SOLVED] CRS - Hardware offloaded bridge with IPv6 RA guard

Sun May 07, 2023 1:04 am

So I’m facing the exact opposite problem; my CRS312-4C+8XG drops RA traffic by default, making itself unusable in my network. Almost as if the feature(s) you describe were already enabled by default. Yet this is a pristine setup with no filtering rules.

I had to mark a port (the one to which the router connects) “trusted” to make RAs work … to an extent.
Now that↑ is a problem because
  1. it is undocumented; the documentation merely says that a trusted port status will let server-side DHCP(v4) through (despite having DHCP snooping enabled), about which I could not care less on my IPv4-free network
  2. …oh wait, actually…
  3. there should be an easy way to ban DHCPv4 (or anything IPv4-related) while still allowing NDP, outgoing RA + incoming RS etc.

Sometimes RouterOS looks&feels like stuck in the 90s. It’s 2023 and … how is anything not IPv6-only by default? Just a few RouterOS versions ago one still had to enable an “IPv6” module to get half-baked IPv6 awareness. :( (Not the case any more, fortunately.) The documentation is full of legacy IPv4 examples. This hurts the Internet and keeps the IPv4 zombie half-alive.
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 516
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: [SOLVED] CRS - Hardware offloaded bridge with IPv6 RA guard

Wed Aug 09, 2023 7:09 am

This approach doesn't seem to apply when switch works with VLAN-encapsulated packets as bridge's filter will deal with mac-protocol=vlan.
 
noradtux
newbie
Posts: 39
Joined: Mon May 24, 2021 6:33 pm

Re: [SOLVED] CRS - Hardware offloaded bridge with IPv6 RA guard

Thu Aug 24, 2023 10:34 am

Sometimes RouterOS looks&feels like stuck in the 90s. It’s 2023 and … how is anything not IPv6-only by default? Just a few RouterOS versions ago one still had to enable an “IPv6” module to get half-baked IPv6 awareness. :( (Not the case any more, fortunately.) The documentation is full of legacy IPv4 examples. This hurts the Internet and keeps the IPv4 zombie half-alive.
There are what I consider bugs when dealing with IPv6 multicast if IGMP snooping is enabled. Basically support told me not to use features that mess with multicast if I need that to work.

Who is online

Users browsing this forum: No registered users and 4 guests