Hi. I use an ISP that advertises a /64 IPv6 prefix to my router (hEX S), so to get devices connected to the internet, bridging the WAN interface with the LAN interfaces is needed, with "Use IP Firewall" enabled for the bridge to protect the network. Also, IPv6 DNS info is advertised through DHCPv6 from the ISP's router, and allowed through the firewall. While this configuration isn't a problem for most devices, Android (still) doesn't support DHCPv6, but it does support RDNSS, which leads me to suggest implementing ND Proxy (RFC 4389). This would allow sending out Router Advertisements, allowing RDNSS to work, which in turn allows devices like Android which don't support DHCPv6 to use IPv6 DNS servers. I understand this technically wouldn't be the ideal IPv6 configuration, but neither is my current network configuration.
Your consideration is much appreciated!

+1 !!

advertise-dns=yes option on IPv6 ND is already present from years...

advertise-dns=yes option on IPv6 ND is already present from years...

`
You don't understand the original question.

User's ISP only gives out /64, via SLAAC. But ISP RAs do not contain DNS information. Instead, ISP offers DNS information via DHCPv6 info.

Since RouterOS does not have ND-Proxy, user is forced to bridge all IPv6 frames from WAN to LAN. This means user is at the mercy of the ISP's router, which as previously mentioned does not send RAs with DNS info. Setting "advertise-dns=yes" on user's own router won't fix anything, since the MikroTik router is not the device generating the RAs for the /64 on the user's LAN to begin with!!!

The problem could be solved if RouterOS had ND-Proxy support. Then user's router wouldn't have to bridge WAN and LAN together. Instead, user could add matching /64 on LAN that exists on WAN, run DHCPv6 client on RouterOS to get DNS information from ISP, then pass it on to his Android SLAAC hosts using the "advertise-dns=yes" option that you mentioned. And ND-Proxy would take care of sending neighbor discovery responses for hosts on user's network back to ISP's router.

Without ND-Proxy, only option is to bridge. Which is an absurd thing to ask a "router" to do. At that point, why have a router to begin with? Just replace it with a cheap switch.

You might argue that user's ISP is "doing it wrong", but there are always going to be ISPs that do things less than optimally. It should be the job of MikroTik to include as many tools in RouterOS as possible to allow the user to be able to creatively work around issues like this. A perfect example of a very common situation that could lead to a similar problem is if you wanted to use a mobile (3GPP / LTE / 5G) hotspot, but have a MikroTik router sit in between your mobile and your hosts for whatever reason. And the particular mobile will only present itself as an ethernet interface. Virtually all 3GPP operators only do /64 allocations (though they would advertise DNS in RAs so the ugly bridging hack wouldn't be a problem; however this would still mean that you couldn't use your router AS A ROUTER when it came to IPv6).

RouterOS IPv6 implementation and feature-set is still frustratingly immature, in A.D. 2022.

+1
A lot of ISP here only provides a /64 block wich is a nightmare to route.

Going to +1 this as well.
Are there any plans regarding this?
It is a feature really needed and provided by most other routers. Currently I have to use a seperate OPNsense router just for the IPv6 side because I can't do it with Mikrotik...

+1

I have long wished that Japanese ISPs or network specifications would support this nd-proxy, as there are many opportunities to use it.

Because of this problem, I continue to not recommend it to Japanese users.

Btw u can hit up feature requests on the ticket system.
Which will actually be seen by employees compared to the forum.

I have requested Proxy-ND "for capsman" in march and have received

"Your feature request regarding Proxy-ND has been noted."

I remember raising this point before, but apparently it wasn't in my prior reply to this thread (from 3 years ago...). So it bears repeating here:

The craziest part of this is, RouterOS actually HAS an NDP Proxy. It's just that it is ONLY available if you configure IPv6 over an LTE connection!

If you connect an LTE modem to a MikroTik router, and if you get a /64 from the LTE network, then the MikroTik will add an address from that /64 to whatever you set as your "IPv6 interface" in your APN configuration, and proxy NDP between your LAN and your WWAN! This works even in RouterOS 6, and is nothing new.

So they already went to the trouble of building the NDP Proxy feature, but for some inexplicable reason, they only expose it to you when you have an LTE connection, provided by an LTE modem that you have directly plugged into the router (via USB or mPCIe slot). Makes no sense! Please just let us configure it on ANY interface, the same way we already can with proxy-ARP!!

Madness...

I remember raising this point before, but apparently it wasn't in my prior reply to this thread (from 3 years ago...). So it bares repeating here:

The craziest part of this is, RouterOS actually HAS an NDP Proxy. It's just that it is ONLY available if you configure IPv6 over an LTE connection!

If you connect an LTE modem to a MikroTik router, and if you get a /64 from the LTE network, then the MikroTik will add an address from that /64 to whatever you set as your "IPv6 interface" in your APN configuration, and proxy NDP between your LAN and your WWAN! This works even in RouterOS 6, and is nothing new.

So they already went to the trouble of building the NDP Proxy feature, but for some inexplicable reason, they only expose it to you when you have an LTE connection, provided by an LTE modem that you have directly plugged into the router (via USB or mPCIe slot). Makes no sense! Please just let us configure it on ANY interface, the same way we already can with proxy-ARP!!

Madness...

I didn't know it had been implemented that long ago.
If it had been, I would have been able to recommend it to more Japanese users, since IPoE-like services were started in Japan about 10 years ago.

Well, when I asked support about it at the time, they were lamenting the lack of response...

I too hope to be able to set it up on other interfaces as soon as possible.

I remember doing a bunch of testing of IPv6 over LTE on ROS a year or two ago, and coming away with the distinct impression that it had to be proxying NDP; however, in fairness, at this moment I cannot recall the specifics of how or why I concluded that. I just discovered RFC 7278, and I suppose it's possible that they could be implementing this instead. RFC 6459, which discusses how IPv6 is typically deployed on 3GPP networks, in section 5.3 suggests the possibility of using an NDP proxy to extend the single /64 that is SLAAC'd to the 3GPP client ("UE") to a different network segment, such as a LAN that sits behind, say, a mobile hotspot. And that's the only suggestion that original RFC makes for how a mobile hotspot might be able to "share" its IPv6 address space in the (likely) scenario that it has not been delegated any additional (and larger) prefixes. 7278 appears to be a later document to offer an alternative to implementing an NDP proxy. So I will have to dig my LTE test bench back out of mothballs, and re-test...

At the risk of being an idiot online: for these sorts of residential connections, why not just use IPv6 NAT? (With non-ULA internal addressing...) While it's not absolutely technically the cleanest, but neither is not delegating at least a /56 (or lately a /60) proper according to recommendations.

why not just use IPv6 NAT? (With non-ULA internal addressing...)

If not ULA (which is obviously undesirable due to how most client network stacks treat them), then what IP space would you suggest such a set-up use?

why not just use IPv6 NAT? (With non-ULA internal addressing...)

If not ULA (which is obviously undesirable due to how most client network stacks treat them), then what IP space would you suggest such a set-up use?

That was what the "..." part was about. I'm quite sure that you are aware of all the discussions around this aspect of IPv6 addressing, and I'm not going to address these. I just can't understand the reason for all the strange implementations ISPs come up with. (And "strange" barely begins to describe my general annoyance.)

Short answer: the proper solution is to get a PI prefix. The free and quick way is to simply get one from a tunnel broker.

I just can't understand the reason for all the strange implementations ISPs come up with. (And "strange" barely begins to describe my general annoyance.)

At least when it comes to 3GPP networks, changes on such large networks (and the devices that connect to them) seem to move at the Speed of Slow(tm). As can be seen when perusing the relevant RFCs and 3GPP standards docs, initially LTE did not support any IPv6 deployment model other than a single /64 announced to a mobile device via RAs (SLAAC)...no DHCPv6 support whatsoever, so no PD. Even if a mobile network operator theoretically tried to fire up a DHCPv6 server and could manage to get proper multicast flow happening all the way between it and LTE UEs over their network core, no standards-compliant LTE UEs were even running a DHCPv6 client on their WWAN (and to this day, Android doesn't run one AT ALL ...not even over WiFi), so such an exercise would be fruitless. So network operators' hands were tied. PD over LTE and 5G-NR became possible with 3GPP Release 10, but it takes a while for everyone to upgrade both the networks and the UEs to support these things. It would have been better if DHCPv6 was an integral part of IPv6 over LTE from the beginning, but we can't go back in time now to change that. (And Google still stubbornly refuses to integrate a DHCPv6 client into Android, soooo...)

Lots of people like to lay the blame of the slow pace of IPv6 adoption and of how it is getting rolled out at the feet of network operators, when there is plenty of blame to go around, with a good portion of it belonging to the people drafting the standards, as well as freaking device manufacturers' v6 stack implementations and (lack-of-)feature-sets. Which just brings us right back around to the original subject of this thread, heh.

Short answer: the proper solution is to get a PI prefix. The free and quick way is to simply get one from a tunnel broker.

Not sure what part of the world you live in, but while PI is relatively easy to get outside of North America (at least allegedly / or so I've been led to believe), ARIN (to their own shame) just isn't really set up to deal with non-corporate entities. As a result, trying to get PI allocation from them is both a hassle, as well as more expensive than most individual end-users are willing to put up with. So PI just really isn't a thing here.

Even if it were, you have to convince your ISP to announce & route it for you. Perhaps if ARIN were more like RIPE, this would be a more culturally-normal thing and thus easier to get ISPs here to agree to. As things stand, that's not the case.

And sure, you can get a block from a tunnel broker, but those tend to be treated as PA, and you may not have success getting LoA from the tunnel broker operator for you to pass on to your ISP in order to authorize them to announce it from their AS. And as awesome as these tunnel broker services are and as great a stop-gap as they have proven to be, being permanently stuck with tunneling all of your IPv6 traffic back to the broker network is not any way to live...certainly not in a civilized society.

EDIT: I suppose in retrospect you meant that you could get either PI or statically-assigned PA from SOMEplace, and then just use that as the GUA space on your LAN that you are NAT66'ing with. Sigh...yeah, I guess that would work. What a series of crap hoops for a single end-user to have to jump through, though. So much for plug-and-play and having things "just work". Comparatively, simply adding proxy-ndp to the freaking router would be a way way way way better experience.

At least when it comes to 3GPP networks, changes on such large networks (and the devices that connect to them) seem to move at the Speed of Slow(tm). As can be seen when perusing the relevant RFCs and 3GPP standards docs, initially LTE did not support any IPv6 deployment model other than a single /64 announced to a mobile device via RAs (SLAAC)...no DHCPv6 support whatsoever, so no PD. Even if a mobile network operator theoretically tried to fire up a DHCPv6 server and could manage to get proper multicast flow happening all the way between it and LTE UEs over their network core, no standards-compliant LTE UEs were even running a DHCPv6 client on their WWAN (and to this day, Android doesn't run one AT ALL ...not even over WiFi), so such an exercise would be fruitless. So network operators' hands were tied. PD over LTE and 5G-NR became possible with 3GPP Release 10, but it takes a while for everyone to upgrade both the networks and the UEs to support these things. It would have been better if DHCPv6 was an integral part of IPv6 over LTE from the beginning, but we can't go back in time now to change that. (And Google still stubbornly refuses to integrate a DHCPv6 client into Android, soooo...)

That's certainly true. I'm not sure that treating a mobile device as a singular endpoint is the worst thing. Of course this does not allow for the broadband over 3/4/5G scenario, which should obviously be handled in some other fashion.

Lots of people like to lay the blame of the slow pace of IPv6 adoption and of how it is getting rolled out at the feet of network operators, when there is plenty of blame to go around, with a good portion of it belonging to the people drafting the standards, as well as freaking device manufacturers' v6 stack implementations and (lack-of-)feature-sets. Which just brings us right back around to the original subject of this thread, heh.

There is certainly a lot of blame to go around. (Actually this is the discussion that I wanted to avoid, but I'm getting in the mood for it ) Here goes my entirely subjective account of the ipv6 project. (The things I say here cannot always be backed up by references, they're more feelings about general attitudes of the participants.)

Chapter 1. We're running out of addresses. The global BGP table is growing. Whatever shall we do????

"We could just make the addresses longer. Let's say from 32 bits to 64. We're not even running out of MAC addresses (48 bits) of which many more are being allocated, so it should be enough. Let's leave everything else as it is."

Now this could have been adopted and it would have probably become ubiquitous quite fast. I'm not advocating that this would have been the correct thing to do. But it was a possible choice.

"Nah, there are many things we should do differently such as..." was the choice that was actually made. Many things were reformed, including:
* Let every device have its own properly routable address - restore end-to-end connectivity. While I appreciate the general idea of the "correctness" of this approach, the world pretty much got used to NAT, port forwarding etc. Generally this has resulted in no marked improvement for the end user.
* Let's do ARP as a proper IP protocol. Okay.
* Let's have link-local addresses. Okay.
* Let's do SLAAC - no state has to be maintained. Okay.
* Let's propagate basic information about the network in RAs. (MTU, gateway, DNS) Okay. Actually nice.
* Let's do away with fragmentation and make PMTUD mandatory. Actually nice.
... and many more.

Add to this that the IETF - while publishing superbly thought out standards that we rely on every day - has a sort of "let them eat cake" attitude towards everyday users. ("Just request a PI and publish it to your peers so that they route it towards your AS." "But, but... I don't really have peers, I have an ISP, the only one in my area.")

Chapter 2. Let's implement this.

It was initially suggested that dual stack would be deployed and we would slowly migrate to it. And it was actually a pretty good idea. However for many reasons this did not materialize:
* The sheer number of differences meant that this was not simply a coexistence of protocols, but a coexistence of *networks* that happen to use the same hardware
* There was no real pressing need to implement it. Everyone was basically happy with the status quo.
* This lead to non-existent vendor support, or to support that only existed on paper but was practically unusable. Not that there wasn't equipment that supported it fully and correctly, but ipv6 could only work if *every* piece of the network supported it.

Chapter 3. We really want to/have to deploy it. CGNAT and other technologies are expensive, broken, etc. IP addresses are becoming an expense.

"Okay, what should we do."
"Let's enable some easy migration strategy."

And this lead us straight to one of the current problems. I invite anyone to *just list* the transition technologies in play all over the world.

Chapter 4 is yet to happen. We are here now.

So altogether I'm clearly not saying that everything wrong is to be attributed to network operators, or more specifically to ISPs. But a lot are.
* ISPs do have ASes (or are a significant enough part of one to have their voices heard) and getting ipv6 allocations is neither hard not expensive. Were they to allocate the recommended /48, /56 or /60, 99% of their users would be happy. Disregarding what technology they use to do this, it is definitely in their power to do so. Many don't.
* Many ISPs actually allocate the prefixes dynamically, in the sense that it actually changes depending on "things". Again, this is a major problem for many users, and one that is absolutely in their power to solve. Many don't.

Short answer: the proper solution is to get a PI prefix. The free and quick way is to simply get one from a tunnel broker.

Not sure what part of the world you live in, but while PI is relatively easy to get outside of North America [...]

EDIT: I suppose in retrospect you meant that you could get either PI or statically-assigned PA from SOMEplace, and then just use that as the GUA space on your LAN that you are NAT66'ing with. Sigh...yeah, I guess that would work. What a series of crap hoops for a single end-user to have to jump through, though. So much for plug-and-play and having things "just work". Comparatively, simply adding proxy-ndp to the freaking router would be a way way way way better experience.

That's what I meant. And for all of the above reasons in effect this is what is going to happen, because quite simply as long as there is no RFC1918 alike in ipv6, multi-wan (with normal ISPs), site-to-site tunnels (for places that get their prefixes dynamically changed around), or private DNS will not happen - so some fairly typical stuff will simply not work.

And it is as it should be, for having an RFC1918 alike in the ipv6 address space would invite the wrath of the God of Address Assignment and the Goddess of End-to-End and surely the earth under our feet would be caused to tremble, the sky to turn dark, our fields left barren; leaving us to cast our weeping eyes upon the coming of the end of days in despair of that which our irreverence has cost us all.

It turns out that there is a lot that I agree with you on...and some that I don't.

I'm not sure that treating a mobile device as a singular endpoint is the worst thing. Of course this does not allow for the broadband over 3/4/5G scenario, which should obviously be handled in some other fashion.

I get the historical reasoning, but the trouble is, from the network's perspective, a UE is a UE is a UE, and a given SIM card could be inserted into any "class" of device, and even be swapped between devices from time to time. The same SIM card that is in a "phone" one minute could be in a "MiFi" the next. On top of that, virtually all smartphone operating systems these days allow you to use your phone AS a mobile hotspot, so the lines are rather blurred. Is it a "singular endpoint", or is it a "router"? Maybe it's both, and the separate categories don't make any sense any longer. In fact, any of the already-deployed "singular endpoints" were all just a download away from becoming a "router", even if when initially released they lacked the feature...the only thing needed to become a packet forwarder/gateway is a sufficiently powerful enough CPU, the right code running on that CPU, and at least two network interfaces...and to be a cellular-based one, one 3GPP WWAN client interface and one of any other kind (WiFi, USB Ethernet dongle, etc.).

It's all just software, after all.

There is certainly a lot of blame to go around. (Actually this is the discussion that I wanted to avoid, but I'm getting in the mood for it ) Here goes my entirely subjective account of the ipv6 project.

[snip much of overall good synopsis]

Now this could have been adopted and it would have probably become ubiquitous quite fast. I'm not advocating that this would have been the correct thing to do.

You might not be willing to go out on that limb, but I will. This is *absolutely* the road that should have been traveled.

the world pretty much got used to NAT, port forwarding etc. Generally this has resulted in no marked improvement for the end user.

I'm neither rabid pro- or anti-NAT. I can see the arguments for both, and am rather indifferent to the whole thing. For the most part, I'm satisfied with knowing that we will eventually (for the most part) no longer be having hosts masquerading behind other addresses once IPv6 has finally penetrated everything.

I *do*, however, predict that there *will* be more lapses in security that happen as a result of a growing number of IPv6 hosts that are not being put behind a NAT, though. I know, I know: "NAT is not a firewall", "security through obscurity is not actual security", etc. ...spare me. Yes, it's true that if you have a hypothetical gateway that is performing NAT but is *not* properly firewalling unsolicited inbound traffic (something you are unlikely to encounter with the average consumer gateway, but certainly could be accomplished with RouterOS if you actually wanted to!), all it would take to talk to hosts on the "LAN" side of that gateway from the "WAN" side is knowing what RFC 1918 range they're using internally. But the thing is, even if you had a specific target in mind, since no RFC 1918 space is going to leak from any AS (and even if it did, most other ASes will filter out the announcement anyway), and since networks even intra-AS are not going to have the particular 1918 prefix of the user whose LAN you want to infiltrate in their own tables, you practically have to be the target's direct neighbor on the same ISP to even have the chance to attempt that. Certainly you can't do that "over the internet". The same cannot be said for a world without NAT and where everything is "end-to-end" addressable...you make a tiny mistake in your firewall rules in that world, and you will probably live to regret it, fast. But make the same mistake in a world with NAT, and you likely would never know.

I admit I am also ever so slightly sympathetic to the view of NAT as more of a "PBX" type architecture / solution than it is an actual security mechanism. Not all of the phone extensions in an organization necessarily needs to have public DIDs, nor is that always desirable. Sometimes some phones should be forced to have incoming calls going through the central switchboard, it's nice to be able to be allowed to freely address them internally without regard to some external convention, and there should be a clear demarcation between what is the public network, and what is YOUR network.

* Let's do SLAAC - no state has to be maintained. Okay.
* Let's propagate basic information about the network in RAs. (MTU, gateway, DNS) Okay. Actually nice.

These two together I have actually grown to actively dislike. (I had an open mind at the beginning, and am still willing to be won over to them, but so far have not been impressed as the practical reality of the situation has made itself more manifest over time.) At first, the promise of stateless sounded great. You mean devices can just assume their own address & I don't have to maintain complicated centralized systems to assign and track them? Great! But scalability and administration/maintainability I think have proven to be problems. And I also think that this whole SLAAC thing has come to be something of the poster child representing the larger problems that have been the real cause behind the lack of quick IPv6 adoption around the world.

In IPv4 land, DHCP becoming ubiquitous was a sort of blessing in disguise, not a burden that now needs to be shucked. Even just on a small residential network, the fact that a DHCP lease is typically relatively long, and that practically-speaking the entry tends to persist in the lease table for as long as the client is actually connected to the network, makes it really easy for somebody to look at it at a glance and KNOW what is on that LAN. Especially for network / help desk people, this is a boon. It sure beats browsing through ARP caches, that's for sure!

Yet in IPv6 SLAAC land, we are now reduced to what is effectively the equivalent of browsing through ARP caches again. ND entries can expire rather quickly, and it's hard to know if you actually have a complete picture of the active hosts on a network simply by looking at that. (It also took RouterOS FOREVER to add any adjustable neighbor table expiration/timeout dials to their IPv6 settings!! It wasn't possible to make this longer until VERY recently!)

Being able to centrally control things from one location has other advantages, too, like being able to reserve "sticky" addresses that you want certain hosts to always use, for whatever reason. Yes, you could argue it is best practice to do that kind of thing within the settings of the host itself, but especially if you are support / help desk for someone else, being able to do that all from one location without needing direct access to the device ITSELF in order to change the configuration within it is nice. Not to mention that if it's something with a real crappy admin interface (who wants to type out the last 64 bits in hex of an IPv6 address on a resistive touch screen on some janky office printer?), you get to avoid that, plus the experience is consistent from device to device. And finally, maybe the host in question moves on and off your network & also visits different networks, where it wouldn't be appropriate for it to try to use your reserved address...you only want it to do so WHILE it is on your network.

"Well sure," you say, "but that's not taken away from you, since DHCPv6 exists. So if you really have those needs, use that!" Except that for all intents and purposes, DHCPv6 is treated by a lot of clients/hosts as "optional". Android, as I have mentioned before, is the biggest offender here. (It also didn't help that RouterOS for the longest time did not even have a DHCPv6 *server* that would run in anything except PD mode, even though its DHCPv6 *client* supported requesting single addresses...ARGH. I'm glad to see that it looks like they have finally addressed this.) And if you can't use the central management tool for 100% of your hosts, then...what's the point?

The RA mechanism of SLAAC that's built on the back of NDP also was not really thought through very well, as was discovered shortly after people started trying to run IPv6 on WiFi networks. It certainly was one of the first experiences *I* had when I started dabbling with IPv6 on my LAN many moons ago, and it left a bad taste in my mouth. So, apparently, when a client first brings up a network interface, it can transmit an active Router Solicitation (RS). The RA that is transmitted in response to that is sent *unicast* back to the client who solicited it. But after that, the client has to depend on hearing *multicast* RAs transmitted by the gateway at fixed intervals...there's no affordance in the RFC given to the host to actively re-solicit an RA again in the future. On WiFi, both broadcast and multicast frames are treated differently by the AP than unicast frames are...and most notably, they can be lost in the air. If things are especially bad, it's possible that your client could be in a position where it can't hear the majority of broadcast or multicast being transmitted by the BSS. I experienced this, and wondered why in the heck my IPv6 on some clients would work great upon initial connection, only for it to stop working some time later. Turns out, after timing it, it was because the Valid Lifetime included in the last RA it heard had been reached. And since it hadn't heard another RA to refresh that lifetime value, it expired its SLAAC addresses.

The solution that AP vendors have come up with? There's now a setting on virtually all of them one can enable which will convert one IPv6 MLD frame to multiple unicast frames, one independently sent to every actively associated WiFi client on the BSS. Now, I know with v4, IGMP proxies have been a thing for a while, so this concept in general is not actually anything new. But applying it to this kind of problem is (and is a terrible hack, to boot)...after all, ARP and DHCP both are transmitted as broadcast, and both are used over WiFi seemingly with no issue, so how is THAT possible? Well, because they actually behave in reasonable ways and do reasonable things, like retry a request if they fail to get a response. Geez louise, what a concept...I mean, wouldn't it be nice if, when an IPv6 host with a SLAAC'd address is finding itself nearing the end of its addresses' valid lifetimes but hasn't heard a multicast RA for a while, maybe just MAYBE it could ACTIVELY try to re-solicit another RA, rather than just shrug its shoulders, go "well gee, I guess there must no longer be any IPv6 gateways hanging out on this network...oh well", and sit there like an idiot?

Anyway, circling back to the "DHCPv6 vs. SLAAC wars", it is my view that the attitude of influential people like those on the Android development team exemplifies why IPv6 has failed so hard to reach majority penetration in any reasonable amount of time: there is a rather vocal contingent of those with influence in the IPv6 ecosystem that are zealots/idealists, and who will insist that you must deploy IPv6 their way, or not at all (or that if you deploy it but do so in what they deem a "subpar" fashion, they will publicly berate you). If it were up to them, Android will never get a DHCPv6 client, and router platforms like RouterOS would never have NAT66 or a DHCPv6 server that is capable of anything but DHCPv6-PD. Given the differences in the v4 and v6 paradigms, IT admins see (what seems to them to be) the vast amount of work required to implement the IPv6-side of a dual-stack network, and as a result it gets deprioritized. Because they are being told they have to start from scratch on many things and aren't just allowed to roll out IPv6 reachability across their *existing* infrastructure in the same way they already deal with IPv4, v6 roll-out gets delayed within their org again and again & the can gets kicked down the road.

Turns out if network operators must up-end all of their existing infrastructure in order to implement IPv6 the "ideal" way, and if you dictate to them that the "ideal" way is the ONLY acceptable way, then what ends up happening is that it either takes people longer, or they give you the finger and don't do it at all. And when this happens world-wide, you don't get the nice snowball adoption effect everyone was hoping for.

Chapter 2. Let's implement this.

[snip]

Yes, all of this is true, but let me also add that when your vendors introduce IPv6 support into their gear via software updates, but it does not rise to the level of having feature-parity with the IPv4 stack on the same product, and you are dependent on some of those features, this ALSO causes a delay in adoption. I can't count the number of times we, as largely a MikroTik shop, wanted to roll out IPv6 much earlier, but were constantly hampered by LACK OF FEATURES in RouterOS that we took for granted on the IPv4 side, and that if we wanted our network & our customers' experience with the IPv6 side to not suck, needed to happen first before we could start pushing it out.

So altogether I'm clearly not saying that everything wrong is to be attributed to network operators, or more specifically to ISPs. But a lot are.
* ISPs do have ASes (or are a significant enough part of one to have their voices heard) and getting ipv6 allocations is neither hard not expensive.

Of course getting an allocation from your RIR is not hard! The hard part comes when you try to make it usable to your end-users on the last mile, over the network that already exists, with the gear you already spent $$ on and deployed, which already actively serves thousands of paying customers!!!

Were they to allocate the recommended /48, /56 or /60, 99% of their users would be happy. Disregarding what technology they use to do this, it is definitely in their power to do so. Many don't.

As established already with the LTE/3GPP example, it is NOT always in their power to do so.

The reason I've been able to speak to this issue is that I work for a small, regional ISP; our network has grown up very, erm, "organically" over the years, and even on the last mile side runs a hodge-podge of access technologies, including fixed wireless (of many different vendors), fiber (both GPON and active ethernet), and even our own private (not attached to outside networks / no roaming) 3GPP network, for fixed access (non-mobile). Our 3GPP network vendors' products do not support prefix delegation. It is unclear whether they ever will. So it is out of our hands! Furthermore, although we would have LOVED to, the particular regulatory environment here surrounding the specific radio band that we deployed the LTE network in basically makes the possibility of using MikroTik as LTE UE completely impractical. So, we have to buy and deploy CPE from our 3GPP network vendor (high-gain dual-pol panel antenna on the outside, ethernet cable coming inside that plugs into end-user's own router). And since we have deployed many MikroTik hAP-class devices as the end-user gateway sitting behind those LTE UE's, but we have NO ABILITY to do IPv6 PD to them, THIS is why I am fired up about things like the lack of proxy-ndp in RouterOS! We can't do our IPv6 roll-out over our 3GPP network without this feature! (Or at least, cannot do it in a scalable and practical way.)

If our vendors don't act, we can't act. And we also can't afford to rip-and-replace everything with somebody else's gear every time one of them fails to act, either. It seems the only leverage I have is to resort to public begging.

* Many ISPs actually allocate the prefixes dynamically, in the sense that it actually changes depending on "things". Again, this is a major problem for many users, and one that is absolutely in their power to solve. Many don't.

This is another area where I am going to have to push back. This narrative that dynamic prefix allocation is "the devil" is just another manifestation of gatekeeping IPv6 idealism/zealotry/ideology/what-have-you. Sometimes it is necessary. Just because you don't know the reasons why a given network might have deployed that way, does not mean that they didn't have a good reason.

In our case, our non-3GPP side of the network, for better or worse, still relies on PPPoE. (Just...don't even start...not in the mood ) If we were running pure IPoE then perhaps we could give everyone a static PD while also not completely blowing up our IGP tables by using VRRP for redundancy between customer gateways / access concentrators, but instead what we have are multiple PPPoE concentrators that are geographically diversified yet all exposed to the same underlying VPLS mesh, where a given customer will likely connect to the one with the shortest RTT (== closest), but could in theory end up connecting to any of them. And if one of our POPs drops offline, then everyone's tunnels will get picked up by a different access concentrator at a different data center. If we gave everyone static PD allocations with this architecture, we would have to carry EVERY customer's individual prefix in our IGP, instead of aggregating the announcements per POP/concentrator. That didn't scale in IPv4 with single /32s which is why customers *by default* get a dynamic (but public/routable!) v4 address, and it doesn't scale in IPv6, either.

If you are a customer of ours, you will get a dynamic prefix by default. If you want a static, just ask. No problem. If only the people who actually want or need one have one, that kind of extra prefix load is manageable. My bet is that vast majority won't know and won't care.

But when people just insist out of ignorance that "all ISPs should be providing static PDs at all times to everyone by default! And they better be /48s, too, by golly!", they are just continuing to perpetuate the whole "if you don't roll it out on your network in whatever way *I* deem to be the perfect, ideal way, all other considerations be damned, then just forget it" mindset. And all that leads to is no deployment. As the saying goes, don't let the perfect be the enemy of the good. Would you rather have access to the IPv6 internet now but (in your estimation) imperfectly, or do you NOT want any access to IPv6? Because if we have to wreck out our entire network in order to re-build it from scratch such that we can deploy IPv6 in the so-called "ideal" way, well, then you are going to be waiting a lot longer before you see any IPv6 from us.

Sigh. And people wonder why it's 2025 and IPv6 still hasn't made the kind of traction that they expected it to by this point.

(Well, it felt good to get that rant out; heh.)

I get the historical reasoning, but the trouble is, from the network's perspective, a UE is a UE is a UE, and a given SIM card could be inserted into any "class" of device, and even be swapped between devices from time to time. The same SIM card that is in a "phone" one minute could be in a "MiFi" the next. [..]

It's all just software, after all.

Yep. Should have been solved (like there are framed routes in ipcp).

You might not be willing to go out on that limb, but I will. This is *absolutely* the road that should have been traveled.

I think *most* of the ideas were okay and *many* of them were sensible. (Like doing away with fragments, etc.) I do think they went a bit overboard in that basically everything was up for reform. It's the "force everyone to the one true way" mentality that you later expound on that I really don't appreciate.

I'm neither rabid pro- or anti-NAT. I can see the arguments for both, and am rather indifferent to the whole thing. For the most part, I'm satisfied with knowing that we will eventually (for the most part) no longer be having hosts masquerading behind other addresses once IPv6 has finally penetrated everything.

I *do*, however, predict that there *will* be more lapses in security that happen as a result of a growing number of IPv6 hosts that are not being put behind a NAT, though. I know, I know: "NAT is not a firewall", "security through obscurity is not actual security", etc. ...spare me.

We know the usual arguments around NAT as well. While the statements made are usually true, from an end-user perspective they constitute nothing more than sleight of hand. Most users will be behind a gateway that performs connection tracking and disallows incoming connection tracking by default. So what do we (not) gain:
* Conntrack still has to be done with the associated processing and memory footprint Hardware accelerators for this will still be ubiquitous. Yes, we don't have to rewrite addresses - but this is has negligible effect.
* Because conntrack is done, VRRP, etc. will still have to have synchronized conntrack tables
* Incoming connections still have to be authorized administratively (we have a filter rule instead of a nat one)
* And just as bonus: all hell breaks loose when your delegated prefix changes.

However by being aggressive about having no nat we lose the ability to have fully user defined addressing (which may be important for a number of legitimate reasons). I also think that this slowed adoption significantly.

These two together I have actually grown to actively dislike. [...] And I also think that this whole SLAAC thing has come to be something of the poster child representing the larger problems that have been the real cause behind the lack of quick IPv6 adoption around the world.

In IPv4 land, DHCP becoming ubiquitous was a sort of blessing in disguise, not a burden that now needs to be shucked. Even just on a small residential network, the fact that a DHCP lease is typically relatively long, and that practically-speaking the entry tends to persist in the lease table for as long as the client is actually connected to the network, makes it really easy for somebody to look at it at a glance and KNOW what is on that LAN. Especially for network / help desk people, this is a boon. It sure beats browsing through ARP caches, that's for sure!

I don't think you lose that much with the trend of MAC address randomization... But this does exemplify exactly the mentality of pushing change on the users, which definitely slowed adoption significantly.

I like to compare this to when AS numbers were extended. (Okay, the markets in which it happened are very different.) No one seems to remember it as some sort of trauma - it was simply implemented. It's much easier to get someone to add a few hundred lines of code to their existing implementation while maintaining the overall concept of DHCP than it is to get them to accept a totally new paradigm.

"Well sure," you say, "but that's not taken away from you, since DHCPv6 exists. So if you really have those needs, use that!" Except that for all intents and purposes, DHCPv6 is treated by a lot of clients/hosts as "optional". Android, as I have mentioned before, is the biggest offender here. (It also didn't help that RouterOS for the longest time did not even have a DHCPv6 *server* that would run in anything except PD mode, even though its DHCPv6 *client* supported requesting single addresses...ARGH. I'm glad to see that it looks like they have finally addressed this.) And if you can't use the central management tool for 100% of your hosts, then...what's the point?

I get the impression that many of the standards including various transition technologies, DHCPv6 actually assigning full addresses etc. were added in some sort of scurry to try to push at least some measure of adoption. I think we have to face the fact than regardless of its technical merits, as a project ipv6 was a failure.

Anyway, circling back to the "DHCPv6 vs. SLAAC wars", it is my view that the attitude of influential people like those on the Android development team exemplifies why IPv6 has failed so hard to reach majority penetration in any reasonable amount of time: there is a rather vocal contingent of those with influence in the IPv6 ecosystem that are zealots/idealists, and who will insist that you must deploy IPv6 their way, or not at all (or that if you deploy it but do so in what they deem a "subpar" fashion, they will publicly berate you). If it were up to them, Android will never get a DHCPv6 client, and router platforms like RouterOS would never have NAT66 or a DHCPv6 server that is capable of anything but DHCPv6-PD. Given the differences in the v4 and v6 paradigms, IT admins see (what seems to them to be) the vast amount of work required to implement the IPv6-side of a dual-stack network, and as a result it gets deprioritized. Because they are being told they have to start from scratch on many things and aren't just allowed to roll out IPv6 reachability across their *existing* infrastructure in the same way they already deal with IPv4, v6 roll-out gets delayed within their org again and again & the can gets kicked down the road.

I actually have mixed feelings about the Android thing. On one hand this exemplifies the attitude of "we know better" often exhibited and rightly criticized. On the other, if one actually reads the standards around ipv6, it is pretty clear that the preferred method of address assignment is SLAAC, and as an implementer you can't just disregard what you're implementing - so in this sense it is the correct thing to do, even if SLAAC is deficient.

Turns out if network operators must up-end all of their existing infrastructure in order to implement IPv6 the "ideal" way, and if you dictate to them that the "ideal" way is the ONLY acceptable way, then what ends up happening is that it either takes people longer, or they give you the finger and don't do it at all. And when this happens world-wide, you don't get the nice snowball adoption effect everyone was hoping for.

Exactly.

Of course getting an allocation from your RIR is not hard! The hard part comes when you try to make it usable to your end-users on the last mile, over the network that already exists, with the gear you already spent $$ on and deployed, which already actively serves thousands of paying customers!!!

[...]

* Many ISPs actually allocate the prefixes dynamically, in the sense that it actually changes depending on "things". Again, this is a major problem for many users, and one that is absolutely in their power to solve. Many don't.

This is another area where I am going to have to push back. This narrative that dynamic prefix allocation is "the devil" is just another manifestation of gatekeeping IPv6 idealism/zealotry/ideology/what-have-you. Sometimes it is necessary. Just because you don't know the reasons why a given network might have deployed that way, does not mean that they didn't have a good reason.

To be fair provider technologies pushed today have the ability to delegate static addresses/prefixes usually via transporting data and control traffic separately and over some sort of overlay. Of course expecting everyone to shell out for these and rearchitect their network is not especially nice. (And faking ignorance and then calling them evil for even daring to bring this up is just overall nasty.)

But NAT is evil and can't even be used as a temporary measure.

Sigh. And people wonder why it's 2025 and IPv6 still hasn't made the kind of traction that they expected it to by this point.

(Well, it felt good to get that rant out; heh.)

Well... exactly.

Yep. Should have been solved (like there are framed routes in ipcp).

IPCP itself doesn't really know about "framed routes", which is just an implementation detail on the PPP server side. (And it actually is a long-standing pity both that IPCP can't tell the connecting client what IPv4 CIDR prefix it might be getting "delegated", necessitating that the end-user just "knows" what those addresses covered by the Framed-Route are [so in this respect, PD through DHCPv6 has got IPv4 beat, hands-down], and also that IPCP cannot inform the connecting client of specific routes that it should install on *its own* end, requiring hacky solutions like scripts on the client side that have prefixes hard-coded in them, or ...*barf*... RIP. But I digress.)

In fact, the larger problem here, when it comes to the "pure-IP" generations (4G/5G) of 3GPP networks specifically, is that GTP seems to be not merely just a simple wrapper around garden-variety PPP. Given how traffic is tunneled and state is signaled through different "interfaces" within the core, as well as how address tracking/mapping is done within most 3GPP EPCs/cores, in the same way that IPv6 PD isn't a thing (or, at least, wasn't until roughly 5 minutes ago, counted in "mobile network" years ), pointing whatever IPv4 CIDR prefixes that you want to route at individual UEs also typically isn't a thing (barring vendor-specific extensions that you can't count on being present in any 3GPP core that you might sit down to work on). If it's standards-compliant and nothing more, then it's one IPv4 address per bearer, period. No "framed routes" for you! Thus a NAT44 on the LTE client side (one that is serving up a "hotspot", or otherwise acting in the capacity of a fixed broadband connection) is simply an unalterable reality for 99.9% of the user-base.

[...] from an end-user perspective they constitute nothing more than sleight of hand. [...] So what do we (not) gain:
* [yup!]
* [yup!]
* [yuuuup!]
* And just as bonus: all hell breaks loose when your delegated prefix changes.

I'm actually sufficiently satisfied that this has been addressed well enough (at least on the SLAAC side) through mechanisms such as RFC 6204. Though this is something that RouterOS (in)famously took until v7.9 in A.D. 2023 to actually support, lol. And so had to be worked around via complicated scripts prior to that (still thankful ROS even has this sweet scripting mechanism to begin with, to be perfectly clear!) Of course, this still requires that your WAPs be configured to proxy MDP and convert to unicast, so your wireless clients can be guaranteed to even hear the signal that instructs them to invalidate the expired prefix to begin with.

I realized just now that I'm actually not sure, though, how well the DHCPv6 server handles this scenario. Guess I'll add that one to my ever growing list of things to lab...

All of these things also just speak to how you need to have all of your IPv6 ducks in a row end-to-end for this to work and be a satisfying experience for the end-users whose networks and connectivity you are responsible for. It would be irresponsible to just flip the IPv6 switch on across the entire network without first testing all of these factors all the way from the network core to the customer-side of the last mile, finding fixes or work-arounds for all of the contingencies you run into ahead of time, etc. Because WHEN (not if) customers start experiencing problems, with them unaware that you started serving them IPv6 reachability or even knowing what that is or that it is even a thing, you need to be able to support them! Blithely turning it on and breaking people's networks or "quality of experience" in the process is a recipe for disaster.

However by being aggressive about having no nat we lose the ability to have fully user defined addressing (which may be important for a number of legitimate reasons).

Yes...my "PBX" analogy/argument.

I don't think you lose that much with the trend of MAC address randomization...

Perhaps. But DHCP clients still do more often than not tend to transmit some kind of hostname along with their request, which can often give you a clue as to what you might be looking at. (Though I will note that I have seen a trend where devices likely to do MAC randomization, like smartphones, are also moving more and more towards not including a hostname as well.)

I actually have mixed feelings about the Android thing. [...] if one actually reads the standards around ipv6, it is pretty clear that the preferred method of address assignment is SLAAC, and as an implementer you can't just disregard what you're implementing - so in this sense it is the correct thing to do, even if SLAAC is deficient.

I think you misunderstand. My problem is not that they implemented SLAAC, which is clearly a mandatory thing for a client to implement. My problem is that they didn't ALSO implement DHCPv6, and steadfastly refuse to extend Android to add support for it, "out of principle". SLAAC and DHCPv6 is not an either/or thing. In fact, DHCPv6 in single-addressing mode still depends on the RA mechanism (flags are set in the transmitted RAs to inform hosts that there is a DHCPv6 server on the network that they can or even should reach out to). There are even many scenarios wherein a host will both generate a SLAAC address *and* also obtain one via DHCP, which is a perfectly legitimate config.

To be fair provider technologies pushed today have the ability to delegate static addresses/prefixes usually via transporting data and control traffic separately and over some sort of overlay. Of course expecting everyone to shell out for these and rearchitect their network is not especially nice.

I think you are just re-making / re-stating my point for me.

IPCP itself doesn't really know about "framed routes", which is just an implementation detail on the PPP server side. [...]

Well, I'm not very knowledgeable about last mile technologies. Of course I know that IPCP only handles addresses. I have the impression that usually when a static subnet is routed, usually it is administratively configured. (I also recall that Microsoft pushed DHCP to be done after IPCP, as I believe they still do for L2TP/IPSec - I know, a whole different can of worms.) What I see around (and again, I know very little about how this is done elsewhere) is that for IPv6, DHCPv6-PD follows - with ipv6cp only handling iid.

* And just as bonus: all hell breaks loose when your delegated prefix changes.

I'm actually sufficiently satisfied that this has been addressed well enough (at least on the SLAAC side) through mechanisms such as RFC 6204.

[...]

All of these things also just speak to how you need to have all of your IPv6 ducks in a row end-to-end for this to work and be a satisfying experience for the end-users whose networks and connectivity you are responsible for.

This is (mostly) solved for RAs. Even if the (I seem to remember 2h) grace period is maintained on end-user devices:
* connections still break after that
* does the provider side maintain the route for this suggested grace period?
* if the provider does not maintain the route, does it (just for fun) reassign the same prefix to someone else?
* if the prefix changed dynamically, and you configure site-to-site tunnels, the routing protocols must maintain the route for the suggested grace period - is this commonly implemented?
* if dns is involved, it has to be updated (okay maybe not a big deal, but still it is a nuisance)

So not only does everyone have to keep their ducks in a row, but everyone must march in lockstep (provider, client, routing, dns, client devices), even regarding suggested timeouts, for thing to sort of work out.

I think you misunderstand. My problem is not that they implemented SLAAC, which is clearly a mandatory thing for a client to implement. My problem is that they didn't ALSO implement DHCPv6, and steadfastly refuse to extend Android to add support for it, "out of principle". SLAAC and DHCPv6 is not an either/or thing. In fact, DHCPv6 in single-addressing mode still depends on the RA mechanism (flags are set in the transmitted RAs to inform hosts that there is a DHCPv6 server on the network that they can or even should reach out to). There are even many scenarios wherein a host will both generate a SLAAC address *and* also obtain one via DHCP, which is a perfectly legitimate config.

This was my very subjective take on this. I see the people most clamoring for dhcpv6 on android are the ones who want networks where slaac addresses don't actually work. I think they should. And (again, this is only my perception) I think this is what is behind the resistance wrt dhcpv6 on the Android dev's side. (Of course I have nothing against optional dhcpv6, especially for pd.)

To be fair provider technologies pushed today have the ability to delegate static addresses/prefixes usually via transporting data and control traffic separately and over some sort of overlay. Of course expecting everyone to shell out for these and rearchitect their network is not especially nice.

I think you are just re-making / re-stating my point for me.

One of the nicest compliments to receive I try not to be totally unreasonable.

One interesting thing that I have seen/heard indications of is that in China there is a push to make CPE devices directly participate in the overlay via L2TP (with increased MTU of course). This may actually solve a lot of problems, enable cheaper and more generic network deployments and actually support gradual migration. Is this really a thing? Is it taking off elsewhere?

This is (mostly) solved for RAs. Even if the (I seem to remember 2h) grace period is maintained on end-user devices:
* connections still break after that
* does the provider side maintain the route for this suggested grace period?
* if the provider does not maintain the route, does it (just for fun) reassign the same prefix to someone else?
* if the prefix changed dynamically, and you configure site-to-site tunnels, the routing protocols must maintain the route for the suggested grace period - is this commonly implemented?
* if dns is involved, it has to be updated (okay maybe not a big deal, but still it is a nuisance)

So not only does everyone have to keep their ducks in a row, but everyone must march in lockstep (provider, client, routing, dns, client devices), even regarding suggested timeouts, for thing to sort of work out.

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.

This was my very subjective take on this. I see the people most clamoring for dhcpv6 on android are the ones who want networks where slaac addresses don't actually work.

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.

One interesting thing that I have seen/heard indications of is that in China there is a push to make CPE devices directly participate in the overlay via L2TP (with increased MTU of course). This may actually solve a lot of problems, enable cheaper and more generic network deployments and actually support gradual migration. Is this really a thing? Is it taking off elsewhere?

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.

i agree with your arguments about renumbering and why it's not practical to preserve addresses/prefixes in some scenarios, especially for smaller ISPs and ones that have grown their networks organically. One thing I would like to point out however, is that not preserving the allocation and allocating it to another client are different things, and the latter can be done with much less effort than the former.

Maybe it was not well articulated, but my point was that with the apparent insistence of the architects of ipv6 on carrying the prefix allocated by the provider into your network, the end-user in the cases I outlined is actually worse off than with ipv4. With an ipv6 prefix change, my connections fully internal to my network will be broken. If my connection is through a site-to-site tunnel - as long as the VPN connection is reestablished - it can survive an (external) ipv4 address change, with an ipv6 prefix carried into the network it can't survive a prefix allocation change. If I use DNS internally, I don't have to change records with an ipv4 address change.

In this sense, ipv6 (as it should be done) does put additional onus on the provider. I can't read the standards and recommendations any other way than that there is a hidden assumption that the allocated prefix will change at most in the event of a major natural disaster.

With regard to the slaac/dhcp Android thing. Again, this is very subjective, but the way I read one of the longest threads on the subject on the Android dev mailing list, many of the most aggrieved people were the ones using "next generation firewall" appliances (such as FortiGate, Palo Alto, etc.) that do things like filter connections unless the address was provided by them via DHCP. (And yes, these are also the firewalls that don't allow an outgoing connection to an IP unless it was obtained through their DNS, man in the middle TLS connections, etc.) These people also made claims such as (paraphrasing - but believe it or not, not that much) "no responsible admin worth their salt would allow devices to use this [SLAAC]"

So technically SLAAC occurs (because it's client-side, there's nothing that can prevent it) however packets are discarded, so in practice devices that only support this will not work.

And I believe that Android devs were against this, not against using dhcpv6-pd on their provider side connections. Maybe the two got unfairly lumped together?

EDIT: With regard to the CPE L2TP thing: I'll be sure to pass along anything interesting if I come across it.

With an ipv6 prefix change, my connections fully internal to my network will be broken.

My hunch is that even those in the IPv6 idealist camps would say this isn't the case, since if you are using it "as intended", you will have multiple addresses per interface, and that intra-LAN, your hosts should all be using link-local, or ULA, or something else to talk to each other. The GUA addresses are intended for internet communication. In fact, I've seen it argued that the proper way to do internet connection failover with IPv6 (when you don't have your own independent address space) is to announce the prefixes you have received from BOTH of your internet providers to all of your LAN hosts. Your LAN hosts will then SLAAC addresses for themselves from *both* prefixes. One of the two default routes that they install into their own tables will have a higher priority / lower cost than the other. When your primary connection goes down, your hosts will then send internet traffic out the secondary gateway, while also switch to sourcing traffic from their secondary address.

Hey, I'm just the messenger.

the way I read one of the longest threads on the subject on the Android dev mailing list, many of the most aggrieved people were the ones using "next generation firewall" appliances (such as FortiGate, Palo Alto, etc.) that do things like filter connections unless the address was provided by them via DHCP.

[...]

And I believe that Android devs were against this, not against using dhcpv6-pd on their provider side connections. Maybe the two got unfairly lumped together?

Even if I may disagree with the actions taken by said admins, ...it's their network. How arrogant is it of the Android network stack engineers to dictate how everybody's networks should work, and what their policies should be? If your interpretation is correct, then Android devs are throwing the baby out with the bathwater, merely because of what some netadmins MIGHT do. Shameful.

My hunch is that even those in the IPv6 idealist camps would say this isn't the case, since if you are using it "as intended", you will have multiple addresses per interface, and that intra-LAN, your hosts should all be using link-local, or ULA, or something else to talk to each other. The GUA addresses are intended for internet communication.

Hey, I'm just the messenger.

The problem is of course source address selection. It has changed once in 2012, and there are again standards track changes (that would elevate ULAs above IPv4, or at least above RFC1918). It changes roughly once every 10 years, and that's not an eternity in networking protocols. The only good side is the forethought put into things like suggesting that the hosts should allow the user to change address selection preferences. Good luck with that.

Even if I may disagree with the actions taken by said admins, ...it's their network. How arrogant is it of the Android network stack engineers to dictate how everybody's networks should work, and what their policies should be? If your interpretation is correct, then Android devs are throwing the baby out with the bathwater, merely because of what some netadmins MIGHT do. Shameful.

Well, again, they say that ipv6 basically expects slaac to work for endpoints, so if it's not working on your network that's not their problem. I generally dislike the fact that an app cannot be installed for it without rooting though.

I think the more general problem is that no one is actually interested in what the ipv6 gurus have to say anymore. Many think they had their chance, and sadly this increasingly includes me.

The problem is of course source address selection.

When a host has more than one address, to my knowledge, most hosts that have a direct presence/address-assignment within the same prefix as the destination they are trying to reach will properly source from the address they possess within that same subnet/prefix. So, trying to talk to link-local will result in your host sourcing from its link-local. If all of your LAN hosts in the same broadcast domain / VLAN have ULA from the same prefix, they'll all source from their ULA address when talking to somebody else on the LAN at *its* ULA address. Et cetera.

The ambiguity with sourcing when a host has multiple addresses tends to arise when something between your host and the destination has to gateway your traffic. For most residential/SMB network, this is not going to be an issue. I could see how this could get sticky, though, for larger LANs with multiple segments or VLANs.

The other thing that occurs to me about this whole topic is that, even if the whole "graceful prefix transition" bit of IPv6 could actually be depended upon for most changes, it still isn't really *that* helpful. What if you are in the middle of a transfer of an extremely large file that is going to take multiple hours to complete? It is no comfort that you have, say, a 2-hour grace period before you have to vacate the old prefix if you still have 8 hours remaining on this transmission. And that doesn't change regardless of whether that transfer is between you and another host on the internet, or between two hosts on your LAN. So, another argument in favor of not relying on GUAs (at least PA ones) for intra-LAN comms...

It has changed once in 2012, and there are again standards track changes (that would elevate ULAs above IPv4, or at least above RFC1918).

That's a tangentially-related-but-different subject. (Though not one that is any less important, to be sure.) We were talking about source address selection, but you suddenly shifted gears to destination address selection, which also includes the additional spin of *protocol* selection if you are in a dual-stacked environment. The whole matter of which *destination* address to use can only come into play if the host making the connection even knows that there are multiple possibilities in the first place, which in turn implies some sort of directory lookup / abstraction system (DNS) that is being used which can inform the host about those different options. So we are suddenly talking about a lot of different things!

The context up to this point also (at least as I took it) included the implication that whatever hypothetical intra-LAN session we are talking about is explicitly an IPv6 exchange. If it is explicitly IPv6, then how certain IPv6 prefix classes are prioritized relative to other IPv4 prefix classes when a host is trying to choose what *destination* to talk to doesn't factor in...that decision already got made a long time ago (either someone typed in a raw address, which locks the protocol in, or the protocol choice got made when the answer to the DNS query was returned). On the sourcing side, it's kind of a non-sequitur to talk about...you could *theoretically* have one host with multiple IPv6 addresses source its traffic from any of them when talking to another IPv6 host, but a dual-stacked host is obviously not going to source from any of its IPv4 addresses when trying to talk IPv6 to another host.

Well, again, they say that ipv6 basically expects slaac to work for endpoints, so if it's not working on your network that's not their problem.

Sounds like you're saying they want to have it both ways: it's "their problem" (or at least they consider it "their business") that your network only work the One True Way(tm), but not "their problem" that their product becomes useless on anybody's networks who won't comply with their demands. Got it.

I don't think the Android guys are coming at this from a position of strength here, myself. IT departments typically have a lot of say in what devices can or cannot be used on the networks they support. On top of that, when it comes to mobile platforms, Apple (as much as it pains me) IS in a position of strength and are much harder for IT to say "no" to, due especially to their popularity in the C-suite. So if iPhone has DHCPv6 support, Android doesn't, IT isn't going to budge on their position that it's DHCPv6 or take a hike, and everybody at the company wants corporate to issue iPhones ANYWAY...

...then it sounds like Android deployments at corporations and universities are going to be few and far between. And if Android doesn't work well on their network, that's "not their problem" & door's to the left. Cuts both ways.

I generally dislike the fact that an app cannot be installed for it without rooting though.

I...have no idea what you're talking about here? Now you've completely lost me.