IMO, its a bug but yes perhaps a current RouterOS limitation – only MikroTik can confirm.
I have many clients not all windows clients, many Apple and Linux … all exhibit this strange behavior after a ISP CPE reboot and the only FIX is the one that I mentioned earlier.
Yes on the router. But make sure your clients are correctly setup as well.
So I have 3 OSes on my clients, iOS, Windows and Android. I cannot disable “privacy extensions” on iOS nor on Android, and on Windows, if it’s disabled, router discovery would also be disabled. On RouterOS, I unchecked “Advertise MAC address” which I assumed will help with this “privacy extensions” issue.
When they are somehow configured for DHCPv6 (unusual!) it will not work.
And iOS, Android and Windows all support SLAAC out of the box, I don’t see config problems on client devices on IPv6.
Also Android is… Android: https://www.nullzero.co.uk/android-does-not-support-dhcpv6-and-google-wont-fix-that/
I connected an Android phone, went immediately to network info and saw only IPv4. Ran test-ipv6.com and no IPv6. Looked in the router and saw others with active IPv6 connections in IPv6->firewall->connections. I was puzzeled, and in a hurry.
Later checked again and IPv6 was fine. That is when I did a trace and saw it comes up only on the first RA received, not immediately on connection.
The phone is supposed to send a Router Sollicitation when it connects, but either it does not do that or it is not received/processed correctly.
That may actually be related to Multicast filtering in the switch.
So clearly, I’m not the only user-facing IPv6 issues on MikroTik and also other brands. What’s really the cause here? I mean, it’s a major problem that is seemingly ignored by the vendors.
It not working for all devices has to be some issue with RA not being processed correctly, they are being sent.
Having 20 dead addressses after one day can only be explained by privacy extensions being enabled, google how to disable it.
Your local systems remembering old prefixes after the ISP has changed them can be considered a RouterOS bug or at least limitation.
(it should send an RA with the old address and zero lifetime when it withdraws the old address to set the new one, but it doesn’t)
Privacy extensions cannot be altered on Android/iOS, and even if we could, this seems more like a dirty hack than a proper IPv6 solution/implementation.
Another small hack I came up with is to reduce the preferred and preferred-lifetime & valid-lifetime to 2 hours in ND>Prefix, it seems to work and forces the client devices to refresh IPv6 addresses every two hours or at least drop whatever it used after 2 hours, but again this is dirty and not a clean solution and I’m not sure if it’ll work well in the long-run.
However, I’m really frustrated that only 3 devices at any point of time is receiving IPv6 addresses to begin with. My RouterOS and client devices configuration all looks good to me. My email to MikroTik is still left without a reply for now.
I am glad to know this issue isn’t isolated only to me. I kept thinking it was my config or something. Somebody should file a bug report on this.
Check my previous reply, I have come up with a small hack that seems to work-around this issue
Also, I’d like to emphasise that this issue isn’t limited to MikroTik, the same misbehaviour occurs on many generic and popular consumer routers.
DarkNate … that’s a nice hack 
I am not able to change this under Winbox … how did you do it using CLI?
You need to disable DHCPv6 Client/IPv6Address first, set up ND>Prefix. Then it’ll automatically allocate the values you set when DHCPv6 client is restarted. I used Winbox.
Thank You
I am operating a couple of WiFi networks at company locations where 200-500 clients are connected every day (Android, Apple, Windows, ChromeOS etc) and out of those I see maybe 3-10 that are not actively using IPv6. Maybe they have disabled it somehow.
But then, we do not have dynamic prefixes. One location has completely fixed addresses, two others have DHCPv6 PD setups like you have but the ISP always returns the same prefix, so the addresses never change.
At one of the locations we recently observed 2 issues:
From then on, IPv6 works fine on this location as well, but I observed the RA issue when debugging it. This however does not affect the usual users who are connected several hours and get their IPv6 setting after one or two minutes.
I still plan to trace the Router Sollicitation situation. I guess it maybe filtered somewhere outside the MikroTik router, or maybe it is not even sent at all by some devices.
I think we should try to contact MikroTik about these issues, as there’s no way the users can work-around this. I’ve emailed them, it would be great if more than one user does the same thing.
It also looks like the mangle rules for tcp-mss-clamping aren’t required anymore: http://forum.mikrotik.com/t/the-deal-with-change-mss/109071/1
MikroTik is not interested in IPv6 issues. Their customers never ask for it, they say.
It also looks like the mangle rules for tcp-mss-clamping aren’t required anymore
This very likely only is true for IPv4.
… who’s wondering ?
we have IPv6 running for over 10 years in the provider-production-environment … but who’s using ? in EMEA or AMER (without BETA-Feeling) ?
Noises heard: it’s running big time in the “chinese-internet” (and they wanna be part of the standardization-process … [they invented the loo-paper .. so … why not ??] )
… BUT probably (“wise-guys”-thinking in mind) … it’s skiped … and we proceed with v8 … or vX : )
What? Your English is R.I.P.