I am running RouterOS v7 (currently on v7.23). I have a PPPoE connection with IPv6 enabled using DHCPv6-PD. My LAN clients use SLAAC to obtain addresses.
The issue is that when my ISP changes the delegated prefix (common with dynamic PPPoE reconnections), the router does not broadcast an RA (Router Advertisement) with Valid Lifetime = 0 for the old prefix. As a result, LAN clients (especially Windows and mobile devices) retain the old GUA (Global Unicast Address) for a long time, leading to "address accumulation" where multiple stale addresses persist on a single interface.
While I have implemented a custom script to manually broadcast an RA with valid-lifetime=0 for the old prefix upon bound changes, I am seeking confirmation on the following:
-
Is this intended behavior? Since the dynamic prefix is removed from the RouterOS Pool upon disconnection, does the RA service lose the context needed to send a "destruction" notice to clients?
-
Is there a native solution? Are there any settings in RouterOS (other than shortening global ND lifetimes) that force the router to track and revoke expired dynamic prefixes during a prefix change event?
-
Future Updates: Can we expect a more robust mechanism in future ROS v7 releases to handle RA invalidation for dynamic DHCPv6-PD prefixes automatically?
I would appreciate any insights from the community or MikroTik staff on whether this is a known limitation or if there is a more "native" way to handle this without resorting to custom scripts.
Hardware/Setup:
How did you do that?
And RouterOS does deprecated old prefixes afaik.
Is this 100% LLM bot generated?
If you run ipconfig /all on your Windows devices, you'll see that the addresses with the old prefixes are all marked as deprecated. That is as intended by the standard. These addresses will be listed (as deprecated) until the valid lifetime expires. That normally does not cause problems, because those addresses will not be used for new connections. The router (if you have not rebooted it) does the right thing and advertises those old prefixes with Preferred Lifetime = 0 already.
If all that bother you, upgrade to 7.24beta1 (or use a version oder than 7.21), and set the Default Preferred and Valid Lifetime to some small value, like 10 minutes:
And the old deprecated addresses will disappear sooner from the devices.
Section 5.5.4 of RFC 4862:
A preferred address becomes deprecated when its preferred lifetime
expires. A deprecated address SHOULD continue to be used as a source
address in existing communications, but SHOULD NOT be used to
initiate new communications if an alternate (non-deprecated) address
of sufficient scope can easily be used instead.
...
An address (and its association with an interface) becomes invalid
when its valid lifetime expires. An invalid address MUST NOT be used
as a source address in outgoing communications and MUST NOT be
recognized as a destination on a receiving interface.
If the Valid Lifetime is set to days, then you have to accept the fact the devices receiving that information will keep the deprecated address for days. If you don't want that. then make sure that the router does not advertise a too long Valid Lifetime. Before 7.21 and from 7.24 you are able to do that. Between 7.21 and 7.23 you are at the mercy of the advertised Valid Lifetime set by the ISP via DHCPv6.
Thanks for the explanation. As a Chinese user, my English is not very good, so I used an LLM to translate it. I’m not very familiar with the IPv6 Neighbor Discovery (ND) mechanism, so when I first saw such a long IPv6 address list, I thought I had misconfigured something. Since it conforms to the RFC specifications and works correctly, then it should be fine.
