Okay, let’s think through this in detail from all vantage points: a provider-side perspective, a vendor-side perspective, a end-user-side perspective, and then try to tie them all together in to figure out what’s actually possible as well as what might actually matter in terms of user expectations, user experience, etc.
Maybe other providers/netadmins would disagree, but I see no reason for us to ever go out of our way to actively invalidate an address or prefix after a certain amount of time has passed (or whatever criteria). It’s not like we are going, “oooh, you’ve had those addresses for 48 hours now (or a week, or a month, or…whatever); that’s long enough & now it’s time for you to give those up and accept a new prefix.” That just doesn’t happen. As long as your PPP session remains up, your addresses aren’t going to change. Even if that happens to be, say, 2 years. At least in IPv4-land, I frequently see much the same thing with many other providers who standardize on dynamic assignment, where many customers frequently get the same address handed back to them every time they make a DHCP request, even if they let their lease lapse for a little bit. Contrary to popular myth, dynamic addressing isn’t some grand conspiracy invented by ISPs as a way to make our users’ lives more miserable, or to try to extract more money out of them.
If something causes your PPP connection to us to drop, then of course we cannot guarantee that once it has been re-established that you will be able to have the same prefix routed to you. Again, we aren’t against it if it does happen, and we aren’t going out of our way to prevent it, but in an environment where prefixes are assigned dynamically, at least some of the circumstances that determine what address(es) you get assigned upon re-connection are quite outside of our control. Also again, we aren’t doing dynamic assignment for any reason other than that’s the best that our current network architecture can scale to at the present time, while still balancing other considerations such as service reliability and redundancy (for example, we happen to think that if something catastrophic happens on our network, where your two hypothetical choices are going to be wait hours to get reconnected with the same address or wait seconds to get reconnected with a different address, that it’s better if you can get service re-established fast, even if with a different set of IP addresses, than to endure a potentially multi-hour-long outage…fancy that!)
Some of the factors that determine whether we can continue to route the same address(es) to you include things like…well, how does (closed-source, sealed-black-box) RouterOS itself behave? In our experience, if a customer disconnects from a RouterOS access concentrator, then reconnects to the same one a short while later, RouterOS tries its very best to give them back the same addresses they had before, assuming they’re still available. (It seems to try to avoid re-assigning that same address/prefix to another user for as long as it possibly can hold out; if there are new connections coming in and addresses within the pool that haven’t been assigned to anyone yet, it tends to pick those other addresses first, before it reaches back and recycles a previously-assigned address that now just happens to technically be free at that particular moment.) That’s great. However, if it didn’t behave that way…we would have little power to do anything about it ourselves, outside of perhaps getting extremely creative and really MacGyver’ing something up. Again: we are often stuck with the choices that our vendors make for us on our behalf.
Now, let’s consider the circumstance where a customer disconnects from one of our access concentrators (for whatever reason), and happens to re-connect to a completely different one. Maybe you just happened to get assigned a different access concentrator by luck of the draw. Or maybe the concentrator you were connected to moments before isn’t online anymore, because…it took a dirt-nap? the building’s on fire? a fiber trunk link got cut somewhere by a backhoe? Take your pick. It really doesn’t matter the reason. Regardless, in that case, it is literally impossible for us to re-assign the same address(es) to you the customer that you had before…the prefix in question isn’t even being routed to the access concentrator that you’re talking to now. The different access concentrators each have their own completely separate pools of (contiguous) address space that they can assign prefixes to clients from, and now you’re talking to a different one with a completely different set of addresses. Sorry, nothing we can do about that.
That last example shows that the whole “valid prefix grace period” thing is a total pipe dream to begin with. The only scenario in which ANY network operator could conceivably honor that would be if what we are talking about was a CONTROLLED re-numbering event, where they wanted to swap out an entire set of prefixes on a segment of their network for some reason, and had the whole thing planned in advance, likely occurring during a scheduled maintenance window, and could have both old and new address space overlap and be “live” and available from the same gateway, at the same time, for a period of time. That’s just not what we are talking about here. For UNplanned network events, if the prefix is available on the access concentrator when the customer re-connects, they’ll get it back. If it’s not because someone else now has it (their connection’s been down for hours for some reason…power outage / they unplugged their router / whatever), tough luck. If they connect to a completely different access concentrator that doesn’t even HAVE that prefix to hand to them that they want back, tough luck. So, no, there is no real scenario within which it even makes sense for us to try to honor such a “grace period”. The entire concept just doesn’t even make sense in any context where we are talking about completely uncontrolled or unplanned outage events.
So you may be thinking, well, doesn’t that lead to a crappy end-user experience? Here’s the thing: this is entirely no different than the experience they would have had with IPv4 up to this point in history anyway. If there is an unplanned network disconnect/reconnect in an environment where IPv4 addresses are assigned dynamically, nobody guarantees you get the same address back, and nobody expects there to be a “grace period” where you can still use the old address for a bit. And, honestly, even if there was, how many people would that practically benefit in most cases? If the connection outage is long enough, all of their existing TCP sessions that they had established with the old source IP timed out long ago ANYway. Connection tracking tables on gateways & firewalls normally get purged when an IPv4 WAN address changes. This whole dynamic delegated prefix thing is just a slightly different spin on that. From my perspective, RFC 6204/9096 takes care of this problem by informing all hosts on the customer’s LAN that the prefix they were using is no longer available, and should be invalidated IMMEDIATELY. No grace period. Then once the new prefix has been acquired, all of the hosts pick it up via RAs and SLAAC themselves a new address from it. If a connection/flow to something on the internet got interrupted, the software responsible for that flow will have to re-make that connection to the remote host…which is exactly the same thing it would have needed to do if the dynamic public IPv4 address sitting on a NATting gateway had changed. Same-same.
The kinds of end-to-end / ducks-in-a-row testing I’m talking about are about making sure that rolling out IPv6 doesn’t suddenly result in a WORSE experience than what they already had pre-IPv6. Yes, it would be nice if we could also make their experience even better…and anytime we are given the opportunity to do that in a way that makes sense, we take it. But the experience needs at the very least to not DEGRADE below what they are used to having with IPv4 connectivity. So basic things like…computers shouldn’t suddenly lose IPv6 connectivity simply because multicast on (W)LANs is unreliable & IPv6 depends on RAs getting through in order to work at a fundamental level, or leaving the IPv4 firewall rules on their dual-stack-capable CPE (many of which are RouterOS-based) on the “default accept” config, or having IPv6 forwarding perform noticeably worse than IPv4 because RouterOS didn’t have IPv6 Fast Path support until like 5 seconds ago, etc. There are all sorts of NEW problems that IPv6 can potentially ADD to the equation, and we need to unearth what those are, anticipate them, and address them ahead of time, before they inconvenience users.
I don’t think this is a thing, though? Given the way that the whole NDP/RAs/SLAAC system is made to work, I’m not aware of any way that a netadmin can try to “break” it so that it doesn’t work on their network, and make DHCPv6 the only option available to hosts. As far as I’m aware, it is by-definition impossible to make a DHCPv6-only network. That was my point. Your choices are: SLAAC only, or SLAAC+DHCPv6. Android has decided to remove the second choice from their users, and thus also from the network administrators who have to maintain the networks these clients need to connect to.
I’m not familiar with what you are referring to; if you have some resources to point me to, I’d be interested to take a look and see what they are talking about.