IPv6-only Virtual Servers

I have used the Cloudflare service. I had an issue with their IPv4 -> IPv6 in their Dallas datacenter that got resolved after chatting with their CEO on Twitter. Since then I have always also added an IPv4 fall-back as well.

I can wholeheartedly recommend Cloudflare though :-)

I've tried it for a while, for me it was down about half of the time (error 501/502/522 on CloudFlare), At a certain point, I could access my site from my phone mobile connection, but not from my home connection.

I've opened a ticket and was told that there were some problems with the servers/route (can't remember exactly, sorry) but was not given any ETA.

It was a while ago, and I remember it was during the time CloudFlare was being ddossed, so maybe it's fixed now and it work just fine, but I haven't tried again.

Not ready to share the dev website yet because there are too many things left to do.

And to be honest the multiple VPS providers thing is a ways off and might not happen.

For now it has a command/API endpoint to deploy a VPS (Digital Ocean), another for registering a domain. The idea is that often when you want to deploy a container it is actually a web site/web application or part of one.

And then I have a run command/API endpoint that takes the server name, image or image alias name, and domain name. It will run the image and automatically create a DNS record and reverse nginx proxy (if the container exposes a port using HTTP).

I am also planning on adding a simple way to automatically run and link containers so that you can just add ENV RUNLINK elasticsearch,redis to your Dockerfile and then my run command will pull & run elasticsearch and redis and then run your container and link it. With the new feature in docker you can then access redis for example by specifying redis as the hostname (docker now adds an /etc/hosts line when you link). I will have some default image aliases which are basically a way to shorten an image name to leave out the username/repo and go with a default I have tested or an alias added by the user.

Right now I am thinking minimum of two weeks before I can start beta testing.

No, it's not really a "recommended minimum", it's the size of the allocation for a local network segment, and that is because stateless autoconfiguration uses the last 64 bits of the address, and thus doesn't work with smaller subnets - and making the allocation for a local network segment larger doesn't make sense, as autoconfig can't use it anyhow (and you certainly won't have more devices either).

The recommended minimum for "a network" in the sense of an allocation assigned to a different administrative entity is a /56, so that multiple network segments can be set up without any further administrative overhead and without incentivizing network idiocy like NAT that's been holding us back with IPv4 for far too long already. Unfortunately, many providers seem to not have gotten the memo, allocating all kinds of idiotically small networks, thus essentially breaking IPv6 before it even got adopted ...

edit: I guess I should mention that providers themselves tend to get a minimum allocation of a /32 from their NIC, so they can assign 16 million /56 without running out of addresses (at which point the income generated from 16 million customers presumably should be more than enough to pay for another /32). They are simply majorly wasting address space by not allocating it ...

> The simple reason why they do not give smaller blocks is the VPS company themselves are assigned a minimum of /64 for network purposes. That means they have 4 billion blocks of 4 billion IPs so why be stingy :)

Well, you know, they might end up having half the population of the planet buying servers, and then they'll be sorry they didn't give out smaller alotments...