Another possibility: use two devices. One running newest ROS version as border gateway (which is realistically the target for CVE-2023-32154 related attacks) and the other running whatever ROS version works for your wireless (and doesn’t have to accept RAs because you use IPv4 for management) …
In a reasonably configured ISP network, no device at all would require to receive RAs. If it uses that, it will get only a /64 and you will run into problems when routing a local network anyway.
(as demonstrated by the people here who write “my ISP gives me only a /64”)
Even when you really need RA to get an IPv6 address from the ISP (or more correctly: the prefix and gateway), you still are not likely to be vulnerable because attacks would have to come from the ISP router itself, not the internet. And of course they could come from the devices on your LAN, because RA enable cannot be configured per interface.
So when you more or less can trust your own devices, the risk of attack is not very high, and for most people it can be zero when they did not tinker with their IPv6 settings.
But this fix for an issue that nobody in my network can/will exploit is more important than stable WiFi, please understand. /sarcasm
How so?
One of ISPs around here are delivering internet “natively”. So the router is configured to request a prefix using DHCPv6 client (ISP is handing out sensibly large /56 prefixes). And then router receives its upstream gateway via RAs (sent out by ISP’s router; BTW, it’s a link-local address as it should be). How would things work without the later? (Without relying on iffy “add default route” feature of MT’s DHCPv6 client)?
Another ISP uses PPPoE and with that one reception of RAs is indeed not needed.
When using DHCPv6, the router can get its gateway via that. Nothing iffy about that. It does not need a RA receiver to receive a link-local address, that is assigned automatically derived from the MAC. The RA receiver is only required to set a global address on the link, which isn’t required as you correctly indicate.
The only thing iffy is when routers are configured to get their default gateway both via PPPoE and DHCPv6. And unfortunately most “standard recipes on the internet” tell you to do that.
In v6 the BFD logged messages using the facility “bfd”. So I added that to the logging to get informative messages about bfd dead link detection.
In the current version it does not seem to log anything, neither from bfd nor from bgp. I only see the lower uptime of the BGP session (and that only after hitting F5).
Please add some logging or document how logging can be enabled/seen in the current version.
I’m trying to find a reference to a document describing how DHCPv6 distributes gateway information … but could not find any such document. The best I could find is some 10+ years old draft proposal for DHCPv6 extension which doesn’t seem to be finished nor accepted as formal RFC.
@EdPa Reference this item I missed the first time reading thru. - *) wireguard - retry “endpoint-address” DNS query on failed resolve
First thanks for listening and actually responding to input. Now just do the same for zerotier Cloudflare tunnel as an options package! 
Does this replace the need for scripts, to keep wireguard running not stuck, in case the “Server” is in the middle of an IP change, or power interruption etc… and its taking some time to resolve the IP address??
We noticed the same thing while running some lab tests. It doesn’t have to be a detailed user guide, just a very brief summary would be enough to start with.
prefixcount about ipv6 sessions go grazy after a while
RouterOS v7.10rc1 has been released
http://forum.mikrotik.com/t/v7-10rc-is-released/166964/1