Do you have some eye defects? I clearly linked to the change log from MikroTik regarding V7.8.
http://forum.mikrotik.com/t/v7-8beta-testing-is-released/163742/234
RFC6204 doesn’t say jack squat about crappy dynamic prefixes. But RFC8978 does, please try to keep up.
Yes, but mostly brain defects!
`
Sorry, my browser did not jump down to the specific post in that very long thread the first time I clicked on your link, before responding.
So instead I saw the changlog for 7.8beta2, because that’s what the thread you linked to was supposed to be discussing, and which lists only the following 3 IPv6-related items, none of which include the one change that the poster you linked to referenced:
`
*) ipv6 - added "pref64" option configuration for RA;
*) ipv6 - limited "hop-limit" parameter value range to 255;
*) ipv6 - made distributed DNS lifetime RFC8106 compliant;
It looks like the 4th "ipv6" change entry you're pointing out silently appeared in the logs for 7.8rc1. I will have to load the latest RC up on a router in the lab and explicitly test for this.
So you didn't read it, then.
`
RFC8978 is mostly an empty advisory document that basically says “dynamic prefixes are kinda bad, but here’s the reasons they might be in use”. Other than to acknowledge that there’s a problem that exists, it’s not really helpful to anybody in this thread, which is mostly discussing the client side, and being a client on the receiving end of such dynamic prefixes. The only mitigation advice they give to end-users is to lower the address lifetimes in the RAs that your router sends out, which…duh? But even if you lower them to the advised 45min/90min values, you’re still likely to have IPv6 internet unreachability issues lasting several minutes after a renumbering event!
The real solution to this is RFC6204 / 7084 (an update of 6204) / 9096 (an update of 7084), which your 8978 even acknowledges in section 4! And which is the very same and very specific feature request we have all been discussing in this thread prior to your arrival.
Finally, I’m sorry to have to be the one to tell you this, but the world will never be rid of “crappy dynamic prefixes”. That’s just reality staring us all in the face.
Interestingly, while the issue remains unresolved for Windows and Mac OS, Android (12) doesn’t seem to have any issue with the “orphaned” IPv6 addresses and seemlessly continues to provide a working IPv6 connection with not a single lost packet during persistent icmp echo reply requests.
Which for me - independently from Mikrotik’s decision not to implement that “invalidation” of old prefixes via router announcements - raises the question why the other operating systems fail to recognize the latest usable address and why they allow to have multiple public addresses on their interfaces then in the first place.
Android has a couple of funny limitations in its network code, maybe the limitation to one active IPv6 prefix is one of them.
It would mean a newly announced prefix automatically replaces all older ones.
Good point and while I get Android’s irony in this case outcome-wise, still I wonder why multiple addresses renders the whole connection useless under Windows and Mac OS then.
Shouldn’t they also fall back to one apparantly usable eventually?
They will. But it takes too long for the users. I can understand that, when your address (prefix) is changing all the time.
In my case it doesn’t, and I have no problem with it on any OS. But for those that have this problem it can be annoying.
Another “similar” Android issue: when you setup an IKEv2 VPN it can accept only a single remote subnet. In RouterOS you can configure multiple subnets in ipsec “mode configs” (as “split include”) but Android will activate only the first and will ignore all others. That makes the split include feature useless for me, I still have to use the “set default route to VPN”.
It does not seem that Android programmers implement standards. They do some quick-and-dirty work that is to their own liking.
I´ve created a feature request at MikroTik about exact this topic (SUP-108243). MT is aware about the problem and pointed out that they are working on it:
So let´s wait for one of the next ROS updates 
Well, there are many things that they are working on, but cannot provide any ETA 
I would say the only positive point is that you did not get a “nobody is asking for that, we won’t spend time on that!” reply.
First of all thanks for @Sob for taking the first (published) swing here at the changing ipv6 prefix and for you @NathanA for creating a robust version of it which implements RFC6204/RFC7084/RFC9096 as it did not peaked anyone interest to provide a solution before, although @IPANetEngineer did provide the command for NAT66.
So my big ask is whether are you @NathanA (or anyone else) willing to create two additional versions of the script: one for NPTv6
and another one for NAT66
in order to avoid the not so convenient effect that the dynamic address and prefix assignment by the ISP changes the addresses in one’s network (so joining “the typical Unix hacker [who] never can remember what the PRINT command is called this week” (Ed Post, Real Programmers Don’t Use PASCAL) one many not know what the IPv6 address of the printer is this day). I do know some of the limitations of ULA and solution for part of it in certain situation.
By the way does anyone know how to subnet in case the ISP only provides a /64 address (for the router) and a /64 prefix (for the network behind the router)?
You cannot subnet a /64. Ask your provider for more space (a /60 or a /56 or a /48).
It could be you already GET more space but have not yet understood how to activate it (with proper DHCPv6 client configuration)…
This request is just as successful as asking the state to lower the standard VAT rate…
I rarely use the world impossible, however in this case I do: no amount of tinkering with DHCPv6 client configuration (prefix-hint and pool-prefix-length parameters) results in different prefix in case the T&C specifies /64 (and more often than not ISPs are not that bad at implementing T&C in case it is advantageous for them).
Ok, but I have read several times on the forum that people got a /64 but when they requested a /60 they got that instead.
(I think sometimes after releasing the previous /64 first)
All ISPs here (that have IPv6) issue a /48 to residential users. I think that is exaggeration to the other end of the scale, but at least I have no shortage.
And it is “fixed” as well (i.e. it only changes when there is a restructuring in the network, not at some interval or on re-connection).
Apparently the original topic discussed here (changing prefix does not result in deleting old prefix at clients) has been fixed in version 7.9beta.
So it could be a good idea for those affected by that to test this version.
It’s fixed, via hack. But still it doesn’t resolve the issue with DNS host names. You need complex DDNS setup for running applications at home.
Static PD is the right way.
What hack are we talking about?
With 7.9beta4, IPv6 now also seems to work in conjunction with cellular ISPs which regularly change the prefix via lte1 without having to reset the clients.
Thanks @Kentzo for creating the scripts for the NTPv6 scenario.