Check what addresses are assigned to your LAN bridge interface and if they have advertise enabled.
If it's deprecated, it may be leftover from a previous configuration.
/ipv6/address/print
Flags: D - DYNAMIC; G - GLOBAL, L - LINK-LOCAL
Columns: ADDRESS, FROM-POOL, INTERFACE, VRF, ADVERTISE, VALID, PREFERRED
# ADDRESS FROM-POOL INTERFACE VRF ADVERTISE VALID PREFERRED
0 G 2a01:36d:1000:8e4::/64 ipv6pool ether1 main yes
1 DL fe80::x:x:x:x/64 wireguard1 main no
2 DL fe80::x:x:x:x/64 pppoe-out1 main no
3 DG 2a01:36c:1000:8e4:x:x:x:x/64 pppoe-out1 main no 23h50m28s 3h50m28s
4 D ::1/128 lo main no
5 DL fe80::x:x:x:x/64 ovpn-out1 main no
6 DL fe80::x:x:x:x/64 ether1 main no
7 DL fe80::x:x:x:x/64 ether5 main no
8 DG 2a01:36c:1000:8e4:x:x:x:x/128 pppoe-out1 main no
At some point since the router last booted the ISP gave you the prefix that is now deprecated, which was replaced by your current prefix, probably because of a wan reconnect or something, and now it's advertised as deprecated so that the clients won't try to use it anymore.
What's the issue?
My issue is, that I cannot find this prefix in the router any more, in my interpretation should not be advertised. I already did dhcpv6client release/renew, disable/enable, global address disable/enable, I simply do not see why would the old prefix still be there in the router and advertised…
If it was there it wouldn't be advertised as deprecated, it was there at some point though.
I don't know for how long MikroTIk advertises deprecated prefixes though, they added this in recent versions and I didn't study the behaviour enough, yet.
You shouldn't care about it.
The “deprecated” advert means “this address used to be valid but now it isn’t anymore”.
Clients systems should use that to erase it from their config. Unfortunately, buggy client systems exist that do not check this field and use it as “preferred”…
Probably a reboot of the router, or elapse of the usual valid time (24h in your case?) will make it go away.
From that version, the lifetime values you set in the default settings are ignored, and the lifetime is taken from the pool, which in turn gets the values from the ISP DHCPv6 lease (binding).
I've complained about this change in the RC thread, because the problem is even worse when the router is rebooted.
I've also suggested multiple times that they use the smaller value between the default that we set on the router and the value sent by the ISP as lifetime used by the advertisements, but alas, it was in vain.
Not yet, but definitely will as soon as I have the time. It instantly breaks my rustdesk system. I do update my ddns, but even if I have a powershell script to remove all other ipv6 addresses, they crawl back later…
Addresses marked as Deprecated are not supposed to be used by systems and/or programs. Probably some bad programming there. idk. MikroTik does the job of marking them as deprecated.
The bug report I was talking about was about the inability to override the ISP provided lifetime.
No, I did not submit a support ticket. Apparently, the beta & RC threads are supposed to be read by some MikroTik staffs, and we are supposed to raise any issues encountered with the version being developed in those threads. But for this case, they probably won't consider changing the introduced behavior.
In that thread I also suggested the real fix for the problem (bad preferred prefix after reboot) V7.21rc [testing] is released! - #41 by CGGXANNX, that even got 12 "thumb-ups", but MikroTik seem not interested by that idea either.
The problem is only bad for Windows clients (I don't know about Apple devices though), Linux and Android, although listing multiple IPv6 addresses as preferred, will pick the more recent address for new connections and has no connectivity issue (unlike Windows).
When I was hunting down a problem, I found that old versions of Windows and also Windows PE had a problem, but current updated versions did not. I do not know if the Windows PE included on Windows 11 install CDs has been fixed by now. Usually a worse problem with Windows is that it takes IPv6 addresses from other VLANs, when you have plugged a Windows PC in a port that has the default network untagged and other networks tagged. That is because of the stupid way of handling VLANs in Windows.
Yeah, that is due to the default settings of the network adapter drivers. But if the "Priority & VLAN" setting is set correctly in the adapter driver properties, then it filters out the tagged VLANs fine.
On Windows I normally enable the Hyper-V Platform (which BTW is also possible for the Home Edition), then let Hyper-V take over the network adapters. With Hyper-V virtual switches / adapters full support for tagged VLANs is available.