Am I missing something in relation to "Accept Router Advertisements" and Neighbour Discovery?

RouterOS General
1

When I first set up my new RB5009 I was just using the default bridge configuration with no VLANs, and I very easily got IPv6 up and running, pulling a /56 prefix from my ISP and advertising a /64 prefix on my LAN for SLAAC. As per the recommendations I’ve seen on these forums, I did not use the “Add Default Route” setting in the DHCPv6 client, and instead relied on RAs from the ISP (with “accept-router-advertisements=yes”) to create a default route, which all worked fine.

I subsequently decided to set up 3 VLANs, but I only wanted to use IPv6 on one of them, so I disabled the default ND configuration (which was sending RAs on the bridge interface), and I created a new ND configuration just for the relevant VLAN interface.

However, disabling the default ND config resulted in “Accept Router Advertisements” no longer working, and I had to enable “Add Default Route” to maintain IPv6 internet connectivity, so I created a logging rule for radvd, and found it was now continuously logging debug messages saying, “received Router Advertisement on unconfigured ether1”. (It seems my ISP is actually flooding me with 3 RAs per second, but that’s besides the point).

As a test, I then created a second, minimal ND config just for the ether1 interface, and “Accept Router Advertisements” immediately started working again.

Ok, fine, but what I don’t understand is, why do I need ND configured on my WAN interface in order for “Accept Router Advertisements” to work, when RouterOS clearly knows that it’s still receiving RAs on that interface as implied by the log messages? What exactly does it think is “unconfigured” without that? Furthermore, why did running ND on the bridge interface allow everything to work correctly, when ether1 isn’t even attached to the bridge? Is this normal/expected/intended?

To my somewhat ignorant mind, there’s no reason I would need to be sending RAs from my WAN interface in order to process the RAs my ISP is continuously broadcasting to my WAN interface. I’m afraid I don’t get it… :confused:

2

I would not necessarily say that this is some universally-agreed general consensus about best practices. The fact is, neither option is perfect. The “accept-router-advertisements” feature has been a second-class citizen on ROS for quite some time. (I mean, what other feature requires you to reboot the router after changing it?) It has gotten a little better over time, but as I think your post demonstrates, it’s still rough around the edges. It would not surprise me at all to learn that this is simply a bug / oversight, because yeah, I agree it makes zero sense that you’d need to configure an interface to TX RAs in order to be able to receive & act on them on said interface. Also, since “accept-router-advertisements” is a global setting that can’t be applied per-interface, if you have some rogue device on your own network broadcasting RAs, then your router might pick up on them…it’s not going to limit its accepting to just the WAN port.

So if they BOTH happen to work for you, there are enough pros and cons to each that I would find it tough to argue that using “accept-router-advertisements” to learn your ISP’s gateway address is somehow inherently superior to allowing the DHCPv6 client to add a default route for you. If you tried letting DHCPv6 do it, and that happened to result in a default route that worked in your particular case, then great! I would be tempted to just call it good & stick with that. It’s just that DHCPv6 is “dumb” and is merely taking the address of the ISP’s DHCPv6 server and pointing your default route at that, which might not hold true for all ISPs (it’s not uncommon for ISPs to run a DHCPv6 server on a separate host than your direct gateway). So RAs are supposed to be more accurate. But some ISPs might even have broken RA transmit on their side, so that’s not always guaranteed to work, either, even setting aside ROS’s own limitations there. If both options work with your particular ISP, then just pick whichever one has the least downsides for your particular circumstances.

And report the bugs to MT as you run into them. :blush:

3

Haha, yeah, that did strike me as rather odd!


Indeed, I already came across some firewall tweaks to block RAs on unauthorised interfaces, which I figured I’d get around to implementing at some point.


Yeah, as I mentioned, my ISP seems to be flooding me with RAs, but what I didn’t mention was that those RAs are actually declaring an MTU of 8986, which was spamming my ROS logs with warnings about an invalid MTU, (because ether1’s default MTU was 1500), so I had to either increase the MTU to match the RAs or add an exclusion to the logging rules to eliminate the log spam! :laughing:


I absolutely will, assuming nobody else chimes in with some kind of valid explanation.

It’s good to know there’s some merit to my question!

4

It would be nice for Mikrotik to allow configuring the accept router advertisements setting per interface (especially because these devices are mainly routers). In the meantime the firewall can be used to filter them

Also be aware that there was a bug that enabled remote code execution from malformed RAs back in 2023. (Long since fixed.)
https://mikrotik.com/supportsec/cve-2023-32154/