IPv6 only Cloudron

[girish]

First up, unbound. In our unbound config, we had disabled ip6 using the do-ip6: no setting. IIRC, we had this because unbound will not start up on servers with IPv6 disabled (in the kernel). Maybe this is a thing of the past by now. Removing the flag makes unbound start.

[girish]

We use api.cloudron.io to query the latest Cloudron release. This domain is IPv4 only. In Cloudron versions before 7.0, we used to use https://api.cloudron.io/api/v1/helper/public_ip to detect the IPv4 address of a server. Adding an IPv6 address to api.cloudron.io would have resulted in an incorrect detection. We use superagent for http requests and afaict there is no way to force it to use IPv4. In versions >= 7.0, we have switched to using https://ipv4.api.cloudron.io/api/v1/helper/public_ip . So, in the next release api.cloudron.io will also have an AAAA record (which also means pre 7.0 installations might break).

[girish]

Docker hub does not support IPv6 out of the box. The default registry is registry-1.docker.io which is IPv4 only. Beta support for IPv6 was announced a while ago. Looks like we have to detect IPv6 only setup and change the registry to registry.ipv6.docker.com .

I have some code like this as a hack:

if ! curl -s --fail --connect-timeout 2 --max-time 2 https://ipv4.api.cloudron.io/api/v1/helper/public_ip; then
    docker_registry=registry.ipv6.docker.com
else
    docker_registry=registry-1.docker.io
fi

...

docker pull "${docker_registry}/${image}"

I think another solution might be to use --registry-mirror mirror.gcr.io in the docker daemon (have to find an alternative to gcr). Haven't tried this out.

[robi]

@girish Cloudron should know if it's ipv4, ipv6 or both and act accordingly, not play timeout games.

[girish]

@robi right... except one can add and remove IPs to a server dynamically. Not sure how we can determine the current status. Maybe some guesses based on the interface configuration.

[robi]

@girish if the network knows, the server can know.

[girish]

Next issue I hit was that npm does not work on IPv6 only networks. https://github.com/npm/cli/issues/2519 , https://www.nico.schottelius.org/blog/nodejs-and-ipv6-only-networks/ and https://github.com/nodejs/node/pull/31567 have more info. Haven't found a solution to this one yet.

[robi]

@girish send it through a 6to4 proxy. Usually the URLs are guessable in advance via a host or domain change.

[girish]

The issue seems fixed in node 18. For node 16, NODE_OPTIONS="--dns-result-order=verbatim" npm install does the trick.

[girish]

https://en.wikipedia.org/wiki/Happy_Eyeballs seems to be some sort of connectivity check standard.

[Plinsboorg]

Hello @girish
Is there any work planned in this direction. I have exactly the setup you've described. Dynamic IPv4 and only IPv6 static. I can assign AAAA DNS record to cloudron IPv6 address but the inhalation stops on waiting DNS of my.mydomain.com.
Could you suggest any workaround or tell me if you're going to continue working on this?

[girish]

@Plinsboorg Dynamic IPv6 and IPv6 static should already work. (This thread was about IPv6 only server, i.e no IPv4 at all). Can you check if your DNS has indeed propagated ? You can check this with host my.mydomain.com . Does this point to your dynamic IPv4 ?

[dimtar]

Also looking at setting up a few ipv6 only instances, keen to hear if anyone has this working 100%

[dimtar]

So I spun up a local virtual machine at my home which has an IPv4 (NAT) and an IPv6 address too. The firewall is set to allow traffic via port 80 and 443 to this box but only for IPv6 because I have no public IPv4 available.

The install was going well until it got to the section where it creates a certificate, it seems like this only works via IPv4 as the log showed the ACME challenge (or whatever its called) failing over and over again.

[jk]

@dimtar To clarify: the VM can make connections to IPv4, but is not accessible inboud from IPv4, only from IPv6?

Could you post the logs regarding ACME? I remember having had issues with that and IPv6 as well (not on Cloudron, but that shouldn't matter...).

[dimtar]

@jk said in IPv6 only Cloudron:

@dimtar To clarify: the VM can make connections to IPv4, but is not accessible inboud from IPv4, only from IPv6?

That's correct, this is just at home with a VM that has IPv4 connection to the internet but is behind a NAT as per standard residential connections. IPv6 is open on the inbound yes.

Spun up a new VM, Cloudron was happy to get the certs but it didn't set any AAAA records only the A record which for NAT reasons isn't correct.
So far its letting me proceed so I will see what I can do. Thank you

[drbigman]

Greetings. Apparently I just fell into same rabbit hole. Im using Cloudron to set up Hetzner VPS with only IPv6 connectivity. Download of cloudron-setup worked well - but execution fails:

##############################################
         Cloudron Setup (latest)
##############################################

 Follow setup logs in a second terminal with:
 $ tail -f /var/log/cloudron-setup.log

 Join us at https://forum.cloudron.io for any questions.

=> Updating apt and installing script dependencies
=> Validating setup token
Could not reach https://api.cloudron.io to complete setup

Is there any reasonable possibilty to work around that? No worries otherwise - then I will buy additional IPv4 from Hetzner, no big deal. Thanks in advance.

[nebulon]

Given our experience with Ipv6, it is not advised to only rely on it. So for a production Cloudron you should also use ipv4.

That being said, it is always good to venture further into ipv6 territory, so given that you apparently can't reach api.cloudron.io I saw that our api server missed the AAAA record. We will set this up to fix this issue at least. But even if that works, as mentioned for the moment make sure to have ipv4 as fallback still.

[jk]

I have tried this a few months ago as well.

The next blocker is that the setup code does some domain IP validation, and refuses to continue of there are no IPv4 addresses available. I worked around it in the setup code of the box project on my machine, but that is of course highly discouraged . Sadly, I lost that code (it wasn't too bad). I'm not entirely sure whether it works with a private IPv4. I haven't tested that. I don't think so though.

Once the box supports primary IPv6, then the rest will more or less work. Because it support IPv6 mostly fine after setup. Thinks like the web front-end, and mail all work with IPv6.

Individual apps may or may not work if they do something other than standard HTTP(S). The OpenVPN app for example does not work correctly yet. At least it does not route IPv6 through the tunnel, possibly because the Docker containers are all IPv4-only.

[jk]

Also, if this gets more development, I'd be quite happy to help test it.