IPv6 only Cloudron

[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.

[girish]

@jk said in IPv6 only Cloudron:

possibly because the Docker containers are all IPv4-only.

internally, IPv6 is enabled for containers. Could be some other issue though.

Previously, the biggest blocker was both npm and docker hub not supporting ipv6. Both of these support ipv6 now. I think the biggest blocker is really the UX at this point. Practically all public wifis (cafes, airports) and most home networks still have only IPv4. This makes the server unreachable... I have been working out of a co-working space which doesn't have IPv6 either!

[nottheend]

Thanks for the IPv6 updates.
Surprisingly, there's no widespread IPv4-to-IPv6 routing solution.
With AWS now pricing IPv4 usage since February, the topic is gaining bit traction again.

[girish]

This is implemented in Cloudron 8