Indeed. It sends RA with the DNS server address.
But there is more trouble. I decided to cleanup my /ipv6 nd config by copying the existing "all" configuration for the specific interfaces where I want to have IPv6 announces only, then I disabled the "all" entry. But it continues to send the old RA on interfaces that now have no explicit config anymore.
Okay, thank you for all the information now. I am pretty sure the issue would be already resolved through support channel, but anyway - the problem is clear now. We will try to figure out if we can somehow differentiate "old config where option advertisement was not expected without additional configuration" from "new configuration where options must be advertised even without prefix configuration" and advertise options only if that is manually forced by "prefix" (including "none") configuration or if this is a new router (reset configuration, installed in factory with 7.23 or later).
pe1chl - What exactly is being sent? I assume you either advertise prefix with lifetime 0 or DNS server with lifetime 0. Great! I presume you want to "remove" DNS server/prefix from clients when you "remove/disable" it on your router. Advertisements do not only advertise new stuff, they also advertise - hey, delete the old stuff, it is not actual any more. Again - packet capture would tell us more than a thousand words.
It sends the same thing as what it was sending to "all" before: an RA which includes MTU, a DNS server with our own address (which I had configured before for "all") with lifetime 1800, and and the DNS server with the local address with lifetime 0.
But I think when I disable nd on "all" it should at most send all lifetime 0 info and best it should stop sending that after the lifetime. I will keep checking to see if it goes silent after some time.
Edit: it keeps doing this. Probably requires a router reboot, I have seen that before with nd changes.
Edit again: I found it was my backup router (on which I did not disable "all" entry yet) which was sending those RAs. Still I think (like @CGGXANNX ) that it should be easier to have things like in the past, where an interface with no ipv6 address with advertise=yes option will not send RA at all.
Thank you.
In my case, as I wrote, I did not create any support ticket because I was not affected. But also because I thought that the release thread was monitored by MikroTik. Nowadays, even if the MikroTik programmers don't have enough time to look at every single post, you can still easily use any of the LLM assistants to give you a summary of the problems by given them the forum release thread URL. Here is an example:
https://share.gemini.google/IHjn4LYBR8Cy
As you can see, the RA problem, including the Rogers Modem Issue which is caused by the exact same RA issue, is listed in the summary.
From the items listed, you've implemented fixes for the "App export" problem and the "Duplicate MAC Detection Bugs", if I remember correctly.
Just a side note that might be good to know: if you ask an LLM to search through a thread in Discourse, it will usually only check a few pages in most cases. You have to explicitly require that all pages be read and analyzed, something like this:
Analyze this entire Discourse thread across all pages, not just the first, and summarize the main topic and key issues grouped by theme, including post numbers, official staff responses, proposed workarounds, and overall consensus. Keep it factual and concise, and avoid speculation.
Undisclosed PPP CVE (dominant topic)
ppp binary diff between versions to locate the fix themselves, arguing MikroTik's silence helps attackers more than disclosure would.IPv6 Router Advertisement regression (major ongoing bug)
advertise=no is set, because the default /ipv6 nd entry got advertise-dns=yes starting in 7.21 upgrades.advertise-dns=no on the default ND entry, or a factory reset also fixes it (since resets default to no).OSPF "duplicate config" bug
Other reported issues
no such item (/interface/wifi/get; line 457) after upgrade from 7.23.1.example.com.) fails; unclear when this broke (somewhere between 7.15.3 and 7.16.1).General sentiment: most simple/home configs upgraded cleanly, but heavy criticism was directed at MikroTik's lack of transparency around the CVE disclosure process.
There's one more potential issue lurking here - if device has its' own DNS servers set to ones accessible from management network only, it will start to advertise these (as only ones it knows) on all interfaces - including to devices which might be unable to access them at all. Here's where default setting "advertise-dns=yes" for all interfaces will start to create additional problems.
please,do not !!!
if, else, but ... what if, then, elseif, ...
no, damage is already done
and no, it is NOT normal to use 3, yes, 3 different screen to adjust RA
ipv6/address advertize
ipv6/nd/interface
ipv6/nd/prefix
you need to jump betwen these window, then try, guess,test,try again ...
an in the end, you will fire up tcpdump to see what RA is sent
no, you made a problem which is clearly induced by bad design
is there a knob "send RA" ?
no, users need to do if/then/else in their head and remember whicho option will trigger something hidden
please
now is time to redesign IPv6 cli/gui
and make clear options
and some logic, if you enable DNS, then "send RA" knob wil be turned on to user have clear idea what is going on
It would be better if the content of the table was moved to /ipv6/nd/ra because it only needed for the handling of incoming RS and outgoing RA. Putting it at the top level /ipv6/nd is quite missleading. The content of the table is not needed for the NS and NA parts of IPv6 Neighbor Discovery to work normally. It also has nothing to do with accepting incoming RA, which has the separate options under /ipv6/settings.
Also, as @pe1chl wrote above (and I had support tickets about this in the past too), the interface setting of the entry should accept interface lists. Currently there are configuration where disabling the default interface=all entry is not possible, because there are dynamic interfaces created by PPP for example where you cannot add static /ipv6 nd entries in advance. Here would interface lists be much more suitable.
yes, same problem, but i solved (very intuitive 
) with PPP up/down script, which enable RA on dynamic incoming VPN interface, because i need to give /64 for each l2tp user
and, no, i will never ever in my life enable *ALL stanza
once in lifetime is enough, looking with tcpdump on MGMT vlan to see 40 MT device wildly sending RA ...
+1
We found that in /routing/bgp/advertisements the peer field shows id numbers (in red) that appear to be incorrect and do not resolve to matching names
Now, after A LOT of time the peers names appeared! I don't know exactly after how much time but for sure at least half an hour!
Please send us supout rif file if you can reproduce problem after the reboot! Send to our support portal, not here please.
Here we go again.
RB5009UPr+S+
router was rebooted without proper shutdown, probably kernel failure
Automatic supout.rif file generated due to service malfunction, please contact MikroTik support and supply the generated file
SUP-219533
Hanging rest-api user bug is still present, opened SUP-219529.
I made this edit to my article above, this post is only to make that visible to those following the thread.
RB5009. I worked as expected for IPv4 but it completly break my ipv6 setup.
I correctly get IPv6 prefix from ISP and all interface correctly get IPv6. However, traffic destined to internet just loop between 2 random physical interfaces (while I only use vlan). Downgrade fix the issue. I guess this is related to the RA that some mention but the packet capture showing an infinite loop on random physic interfaces is really strange.
*) lte - fixed cases where EC25-EU and EG25-G boards would receive packets with missing last 4 bytes;
I hope this finally fixes the issue i have been having with my KNOT Embedded LTE4 for months where the link drops for 3 seconds up to 5 times a day
I had a similar issue when upgrading from 7.19.x. In my case, it was the instance that was creating problems. The workaround for now, in my case, is to delete the instance prior to the upgrade and then recreate a new pair of instances after the upgrade; otherwise, the router remains in a loop. Reported to support.
Regarding the "security issue": I said it here ( Cve-2025-10948 - #80 by mrtn ) and I need to say it again:
Mikrotik’s response to this security issue is not what I expect from a vendor that develops security-critical devices. It harms trust into the products, especially when using them in production environments (which I don’t do so far, partly for reasons mentioned above).
I like Mikrotik for multiple reasons, but your handling of security is seriously eroding trust. Please improve that.