Theoretical Deployment: IPv6-Only VPS

[moranbw]

I'm experimenting with your clatd project, as I'm developing some hobby projects in some cloud VPSs that are IPv6 only (they're a little cheaper). I was originally just using the public NAT64 service at nat64.net, but found that things we're a bit slow when making lots of requests (though it did "work").

So I thought maybe I could install something directly on my server, which is what led me to clatd (it seems to have the simplest config). Really I just want to access IPv4-only APIs and sites (i.e. GitHub) from my IPv6-only VPS,

Installing and configuring clatd, things seem to work well when pointing my resolv.conf towards the services at nat64.net. But this leads me to two questions:

1. How is having clatd in the mix any different than what I originally configured (resolv.conf pointing towards nat64.net servers).
2. Can clatd enable me to use Google or Cloudflare's DNS64 servers? I'd like to rely on them due to proximity / reliability. If clatd uses TAYGA under the hood (which I understand does NAT64), shouldn't this work?

Thanks in advance.

[toreanderson]

Hi Brian.

You will need some kind of IPv4-to-IPv6 translation service between your VPS and GitHub in order for communication to be possible. This is most commonly a NAT64 instance.

Google and Cloudflare's DNS64 service do not include NAT64 service. They will synthesise IPv6 AAAA DNS responses for IPv4-only hosts using the NAT64 translation prefix 64:ff9b::/96 (which is the "default" NAT64 prefix defined by RFC 6052). So in order for you to be able to use Google/Cloudflare's DNS64 service, someone else (e.g., your VPS provider) needs to operate a NAT64 instance that is configured to use 64:ff9b::/96 (and their network must be set up to route packets destined for that prefix to the NAT64 service, of course).

So to answer your second question: if you have access to a NAT64 service using 64:ff9b::/96, then yes, you can use Google/Cloudflare's DNS64 with clatd. If you don't have any access to such a NAT64 service, then no, you cannot use their DNS64 (with or without clatd). The easiest way to test if you have access to such a NAT64 service is to try to communicate with an IPv4 address directly without using DNS64, e.g. HTTPS towards 140.82.121.4 which is GitHub:

$ nc -zv 64:ff9b::140.82.121.4 443
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: TIMEOUT.

As you can see, I got no responses, meaning there is no such service available for me to use.

As for nat64.net - they actually offers both a DNS64 and a NAT64. Checking their DNS64 responses I can see that they are actually using three different public prefixes (thus reachable over the public Internet):

$ dig @2a00:1098:2c::1 github.com. AAAA +short
2a00:1098:2b::1:8c52:7903
2a00:1098:2c::5:8c52:7903
2a01:4f8:c2c:123f:64:5:8c52:7903

Repeating the connectivity test using those prefixes, I can verify that they all work:

$ nc -zv 2a00:1098:2b::1:140.82.121.4 443
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Connected to 2a00:1098:2b::1:8c52:7904:443.
Ncat: 0 bytes sent, 0 bytes received in 0.10 seconds.
$ nc -zv 2a00:1098:2c::5:140.82.121.4 443
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Connected to 2a00:1098:2c::5:8c52:7904:443.
Ncat: 0 bytes sent, 0 bytes received in 0.12 seconds.
$ nc -zv 2a01:4f8:c2c:123f:64:5:140.82.121.4 443
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Connected to 2a01:4f8:c2c:123f:64:5:8c52:7904:443.
Ncat: 0 bytes sent, 0 bytes received in 0.09 seconds.

That's why nat64.net works. The difference between using nat64.net with and without clatd, is that clatd will give your VM a local private IPv4 address which can be used by applications. That is, with clatd, you can communicate directly with 140.82.121.4.

You cannot do that without clatd, in that case you need to communicate with the generated IPv6 equivalent address, e.g., 2a01:4f8:c2c:123f:64:5:140.82.121.4.

Is that a problem? Depends on which applications you are running. Some applications do not use DNS, or do not support IPv6 sockets. If you are using such applications, clatd can help. If on the other hand all of your applications use DNS and support IPv6, then you don't gain much from clatd. I hope that answers your first question.

[toreanderson]

By the way, I see from your profile that you are based in the US. That is likely why you perceive nat64.net as slow, as all the three NAT64 instances appear to be located in Europe (the 2a00:1098: ones are in the UK, while the 2a01:4f8: one is in Germany).

Therefore, a single round-trip between your VPS (assumed to also be in the US) and an IPv4-only site hosted in the US will have to cross the Atlantic four times. That will of course add a significant amount of latency and performance degradation.

[moranbw]

Thank you for the detailed response, @toreanderson!

Would something like Jool be a more appropriate tool? This doc seems to be what I'm trying to achieve? https://nicmx.github.io/Jool/en/node-based-translation.html

Also as an aside, I was able to get clatd and TAYGA to compile and run on Alpine...not sure if you'd be open to a PR that integrates (some) of this into your Makefile or perhaps an OpenRC script.

[toreanderson]

Jool (configured as a «Node-Based Translator» according to the link you provided) and clatd do exactly the same thing – they provide the applications running on the host with a virtual network interface with a local IPv4 address. This is the so-called «CLAT» in the 464XLAT architecture.

Neither Jool nor clatd provides the «PLAT» (a.k.a. the NAT64 gateway); this function must exist somewhere else in the network, and needs to have both IPv4 and IPv6 Internet connectivity in order to be a bridge between the two.

The main difference between Jool and clatd is that installing and configuring Jool is a bit more complicated than it is for clatd, since you need to download and compile a third-party kernel module and then run quite a few commands in order to get everyting running. clatd, on the other hand, tries to auto-detect everything and Just Work™ out of the box.

The downside of clatd is that the translation engine is a TAYGA process running in user-space process while Jool runs in kernel space. I would therefore expect that Jool would provide better performance than clatd/TAYGA, but the difference is probably not noticeable if you are just using it to do an occasional git pull from GitHub.

It would be likely possible to extend clatd to support using Jool as a translation engine instead of TAYGA.

I am of course open to PRs.