I've found vultr.com to have solid IPv6. They give you a true /64 that can (with NDP proxying) be fully routed back into your VPS. It just works.
Does DO really not give you a /64? I see prefixlen 64 on my eth0 on one of my 'droplets'.
Does DO really not give you a /64? I see prefixlen 64 on my eth0 on one of my 'droplets'.
How is that solid IPv6? You can't even trivially subnet it! Sure, it's marginally better than the 16 address madness of other hosters, but it's still terrible. Especially so, given that you need an NDP proxy hack ... WTF?
The NDP proxy hack is easy: https://github.com/DanielAdolfsson/ndppd
See also: https://www.zerotier.com/community/topic/69/default-route-ov...
Linode are the only ones I have seen do IPv6 correctly. I wish they also knew how to do security correctly; unfortunately I can no longer recommend them in good conscience.
As for the NDP proxy hack being easy: Well, sure, there are more difficult things (and yes, I once wrote an NDP proxy deamon myself, which wasn't particularly difficult either). But it still adds complexity, for no real reason. The question isn't whether you can work around this deficiency. The question is: What is the point of this deficiency in the first place?
Plus, you still only have one /64, which is just braindead.
And, with a proxy NDP setup, you are vulnerable to NDP cache DoS: Your upstream router needs to do NDP resolution for each individual address (instead of just the one router address that your prefix is routed to), which enterprising attackers can DoS by simply sending packets to a few thousand to million of your addresses which then will overload the NDP cache of that router, leading to your machine(s) potentially being unreachable.
However, your mistake probably is more in thinking in terms of "number of addresses", as you would with IPv4. IPv6 is meant to be easy to deploy. Part of the specs are mechanisms for automatic address allocation. And one big reason for why the IPv6 address space is so huge in the first place is to enable those, and to thus avoid all the bureaucratic overhead that address exhaustion causes.
As such, it is important that address allocations are standardized, so that software that implements such mechanisms just works. The best-known mechanism probably is SLAAC (stateless address auto-configuration). SLAAC requires a /64 per network segment to work. If you don't have that, you'll have to configure things manually. For no reason at all.
Imagine a world where you would not ever have to manually assign addresses at all. That's kindof the goal with IPv6. Any ethernet segment always has a /64, so there is never any situation where you could connect a new machine and there wouldn't be any addresses available for it. You just plug it in, it performs router discovery, assigns itself addresses, and it just works. If it's supposed to have a DNS name, it might fire off a DNS update to the DNS server to make its addresses known to the world. And all of that without any need for some kind of DHCP server keeping track of assignments.
This is also applicable to virtual machines and containers. A common setup is to bridge virtual machines and containers to the host machine's ethernet interface. In that case, a container isn't really any different from a physical machine plugged into the ethernet, as far as address configuration is concerned. So, if the VM hoster's (virtual) ethernet interface has a /64 with router advertisements, you can simply start stuff in containers bridged to that interface, and they'll automatically have addresses assigned without you having to do anything. So, even if you only have three containers, some fixed allocation of 16 addresses prevents that automatic configuration from working. But also, it's completely reasonable to have more than 16 containers running in a VM, in which case you'd be out of luck with 16 addresses, and would have to start using workarounds like NAT and non-public addresses and stuff that terribly complicate things--again, for no reason whatsoever.
But also, just bridging stuff isn't the only reasonable thing to do. You might want to have a bunch of containers isolated a bit, so you want to have them behind a packet filter. So, you set up a virtual bridge that you add all those containers to, and then you set up routing between that bridge and your upstream ethernet interface. Now, you obviously still want autoconfiguration to work for the containers on that isolated virtual ethernet. But you need a /64 for that. But you also need a /64 for your host, and maybe another bridge with completely unfiltered containers. Now, you already need two /64s. Unless you prefer configuring everything manually, that is.
Also, the long-term perspective should be to even automate the assignment of /64 prefixes to any such subnets that you might configure. In principle, such a mechanism already exist, in the form of DHCP-PD (prefix delegation), but it isn't really used much in data center setups (but, well, IPv6 isn't used much either ...). With that in place, you should be able to simply rent some virtual machine in the cloud, install some "private cloud" software stack, and then be able to have a user interface that allows you to create virtual network segments and filters between them and containers for various applications connected to those segments--without ever having to think about addresses at all, without ever entering any address, without even seeing any addresses. Addresses simply are always available, as many as you need, and there are standardized protocols that take care of assigning unique addresses to everything that needs an address.
Also, as a result of that, it should be outright trivial to migrate everything to a different hoster. Everything should be able to renumber fully automatically to the prefix allocated by the new hoster. You simply shut down your VM, transfer an image to the new hoster, and boot it back up, and it should just work.
Addresses should never be a factor to consider what designing your network/server/hosting setup. If you think something should be in a container, you should be able to launch a container, and it will have an address.