My provider gives dynamic ipv6 prefix on every router reboot - but routerOS 7.21.3 don’t deprecate old (before router reboot) prefix for all network clients. So, I have to restart (network at least) on every PC/smartphone in my network after router reboot. Other manufacturer’s router deprecates it ok, mikrotik - not. Will it ever be fixed?
I can't answer that. Could you get a static IPv6 from your ISP? There is no reason these days for providers not to give a static and a /56 or even a /48 on IPv6.
1 Like
Example 6: DHCPv6 Status Change Script from https://mikrotikdocs.fyi/ipv6/ipv6-dhcp-client/ might be something you are looking for.
1 Like
Very useful...
[...]
# Add custom actions here
[...]
# Add recovery actions here
[...]
You didn't specify how the devices get IPv6... Anyway paste this on Router CLI:
/ipv6 nd prefix default
set preferred-lifetime=45m valid-lifetime=1h30m
These are the recommended values... in "various places"...
I don't know how often your router reboots, if that doesn't work, reduce the times...
More like a example. You can run script from scheduler with start-time=startup argument
How do they do it... when they're off?
Or do they do it before they restart... But how do they know you're about to unplug the power cord?
If you mean the simple "reboot" command...
You didn't specify which device you're referring to. Is it just a router and an access point? Does it do something else?
Maybe when you restart the other router... Does it also restart the Wi-Fi?
All the logical details are missing.
This is because of a change introduced in 7.21:
I've raised the issue in that thread multiple times, and also suggested a couple of solutions for MikroTik to implement:
-
Simplest is to consider the global lifetime settings too and advertise the smaller value of the global setting and the lifetime stored in the pool. User can then workaround by setting smaller global lifetime values.
-
MikroTik change RouterOS to properly store old prefixes at reboot to deprecate them after reboot if no longer available, similar to how DHCP server remembers dynamic leases. V7.21rc [testing] is released! - #41 by CGGXANNX.
But MikroTik seem to ignore all that in the RC thread. I was too lazy to create a support ticket, maybe you can create one?
1 Like
Problem is loosing previous prefix on reboot. It have to be saved and marked deprecated after getting new one - in case it changed.
I have pppoe on hap ac2 + switch before my pc.
@horizn thanks for posting the link to https://mikrotikdocs.fyi
I've bookmarked the site, it really looks useful!
Support answer:
Hello,
Thank you for contacting us and for your suggestion. Yes, at the moment "old prefixes" are maintained in RAM only and are lost after a reboot.
We will consider improving this procedure in the upcoming RouterOS releases.
Regards, Mārtiņš S..
1 Like
Good catch!
I agree, it’s precisely router responsibility to remember what routes it advertised prior to reboot (graceful or sudden) and issue deprecations as necessary upon boot. It appears currently RouterOS is in violation of RFC 9096 - Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events:
When a CE router provides LAN-side DHCPv6 (address assignment or prefix delegation), then:
The CE router SHOULD record, on stable storage, the DHCPv6 address and delegated-prefix bindings corresponding to the LAN side.
If the CE router finds that the prefix to be employed for address assignment and/or prefix delegation has changed (e.g., upon a crash-and-reboot event) or the CE router receives DHCPv6 IA Prefix options with 0 lifetimes, the CE router MUST:
In Replies to DHCPv6 Request, Renew, and Rebind messages, send IA Address options or IA Prefix options (as appropriate) for any address assignments or prefix delegations for the stale prefixes. The aforementioned options MUST be sent with both the "valid-lifetime" and the "preferred-lifetime" set to 0, for at least the "valid-lifetime" originally employed for them, or for a period of ND_VALID_LIMIT if the recommended lifetimes from Section 3.4 are employed.
Initiate sending Reconfigure messages, if possible (i.e., client requests Reconfigure support and the CE router offers it), to those clients with address assignments or prefix delegations for the stale prefixes.
RouterOS is missing the send-reconfigure command under /ipv6/nd
If I'm not mistaken, "send reconfigure" is a DHCPv6 feature, not one of SLAAC/RA. The DHCPv6 server in RouterOS supports "send reconfigure" already, however, clients must support that too (most don't).
There is parity between DHCPv6 clients and SLAAC provisioned clients: send-reconfigure in SLAAC context is unsolicited RA that lists prefixes with lifetimes of 0. Such command would allow a RouterOS user to circumvent current implementation limitation with a script.
You’re right that it’s not exactly send-reconfigure in DHCP context, but I think is acceptable to keep API simple.
FWIW here is a relevant IETF discussion for curious souls:
- https://mailarchive.ietf.org/arch/msg/ipv6/InAdD_3BQ18YxsKUyqQNqfodPjk/
- https://datatracker.ietf.org/doc/draft-ietf-6man-slaac-renum/13/
Claude Opus 4.6 Extended Thinking Summary
1. Multi-router links are a first-class scenario
IPv6 was designed so that multiple routers can legitimately advertise different prefixes on the same link. Router A might advertise 2001:db8:a::/64 while Router B advertises 2001:db8:b::/64. If either router could send an RA that means "only my prefixes are valid, discard everything else," it would inadvertently flush the other router's perfectly valid prefixes. There is no authority hierarchy among ND routers on a link — each router only has authoritative knowledge of its ownprefixes. A "flush all" semantic would require solving the problem of which router is authoritative for the entire link, which the protocol deliberately avoids.
2. The "S" in SLAAC means something
SLAAC is fundamentally stateless from the router's perspective. The router doesn't track which hosts have which addresses. A "this RA is the complete truth" flag would shift SLAAC toward a stateful model where the router is expected to maintain a comprehensive view of what the link should look like. As Fernando Gont himself noted in the mailing list when reviewing proposals that added state to SLAAC routers, this represents a fundamental change to the protocol's architecture. The working group has historically resisted turning SLAAC into something resembling DHCPv6.
3. Security and robustness concerns
A "flush all non-included prefixes" flag would be an extremely powerful denial-of-service vector. A single rogue RA (which is already a known threat per RFC 6104/6105 on RA guard) could instantly wipe out all address configuration on a link. The current additive model limits the damage a rogue RA can do — it can add bogus prefixes, but it can't unilaterally destroy legitimate ones. The existing zero-lifetime deprecation mechanism requires the attacker to know which specific prefixes to target.
4. Backward compatibility is a hard constraint
As discussed extensively on the 6man list, any new RA flag or option would be ignored by existing hosts. An unmodified host receiving an RA with a hypothetical "authoritative" flag would simply process the PIOs normally and ignore the new semantics. This means you'd have a split-brain situation where new hosts flush their state and old hosts don't, which is arguably worse than the current problem since it makes network behavior unpredictable and hard to debug.
5. The IETF chose to solve it differently
Rather than adding a flush mechanism, the working group pursued two complementary strategies, reflected in RFC 9096 (router-side) and the ongoing draft-ietf-6man-slaac-renum (host-side):
On the router side, RFC 9096 focuses on prevention (short capped lifetimes via ND_VALID_LIMIT/ND_PREFERRED_LIMIT) and explicit deprecation (zero-lifetime PIOs for known stale prefixes, stored on stable storage). The philosophy is that if lifetimes are kept short enough (90 minutes), the damage window from a crash-and-reboot is bounded even without any explicit flush.
On the host side, the slaac-renum draft (which has progressed through many revisions and is now at version 13 as of early 2026) works on improving how hosts react when they detect stale configuration — for instance, by using ICMPv6 error code 5 ("source address failed ingress/egress policy") as a signal to re-solicit RAs and reconfigure, as Christian Huitema and Ole Troan discussed in the thread.
The IETF consensus effectively landed on: the lack of a flush mechanism is a deliberate design trade-off that preserves multi-router compatibility, security robustness, and the stateless nature of SLAAC, even though it makes the flash-renumbering problem harder to solve.
Right, but normally if the router could remember the old prefixes, and knows that the old prefixes are now deprecated, then we don't really need an explicit "Send Reconfigure" button like on the DHCPv6 server side, because the default RA Interval will ensure that the information about the deprecation is sent out after a few minutes (default RA interval is 200-600s).
I’ve been using RouterOS long enough to appreciate manual triggers 
@KuDeSnik33ra Take a look at /tool/traffic-generator, perhaps you could have a script to dump current prefixes to permanent storage every minute or so, and then upon boot compare and inject RA with necessary depreciations?
Before 7.21 I could live with a 10 minutes broken IPv6 period (when the router reboots and gets new prefix but doesn't know the old prefix) because I just reduce the global prefered-lifetime and valid-lifetime to 10 minutes. So the RA interval being max 600s is ok enough for me.
But with 7.21 that workaround with reducing the global values no longer works, because the prefixes are now advertised with the lifetime from the ISP, and in my case it's 5 hours 
. So I really need MikroTik to implement the "remember prefix on reboot" functionality soon.