Indeed, the transition to IPv6-only networks is a timely and important step, and this is an interesting approach. In my opinion, NAT64 in combination with DNS64 presents the most practical solution for home networks. This approach can be fully implemented by consumer routers, eliminating the need for any changes to client devices. If router manufacturers were to make NAT64 with DNS64 a default feature or, at the very least, an easily selectable option, it would significantly advance our progress toward widespread adoption of IPv6-only networks.
Not just routers: android phones since 4.3 and iOS 12 both include a CLAT implementation to do just that.
clatd https://github.com/toreanderson/clatd/ is a nice and practical CLAT implementation: it does not "require" dns64 but can use it for single stateful translation instead of double
Windows 10+ has a native 464XLAT implementation for use with cellular networks as well.
Most of the pieces are in place already but not all clients operate the same way. I think there's stil some streamlining to be done before any ISP will bother implementing such technology into their routers.
Windows just nails it. Now that I'm spending most of my time on the desktop with Linux, I've tried to get the same results tere and move to IPv6 only: with clatd it's mostly been a smooth ride.
One small issue: I think T-Mobile is giving /56 but for some reason the Qualcomm 5G card only gives /64 through wwan0.
However, checking the IPv6 returned by qmi with `--wds-get-current-settings` returns a different one each time, so I think the embedded Linux inside the Qualcomm cards does SLAAC and the equivalent of net.ipv6.conf.wwan0.addr_gen_mode=3 to randomize the IID for EUI64
Then add NAT 46, 44, and 66 and give no shits about any nonsense that happens outside your network while supporting any device and allowing people to go ipv6 only at any time.
If v6 people didn't hate nat with the white hot intensity of a thousand suns [1] we could have had a smooth ipv6 path with the only necessary change being on consumer routers.
Meanwhile, one of the most annoying holdouts on the service side is github.com - I've had a collection of v6-only systems for years and github seems to be the one recurring thing that requires bolting on kludge of some sort.
Using LD_PRELOAD for IPv4 seems to me like using the wrong tool for the job.
> "Most of the apps I use support IPv6 but there are some cases when lack of IPv4 connectivity on my machine negatively affects experience."
Just install clatd to get 464XLAT so hardcoded ipv4 get routed to 192.0.0.1 (the clat iface is the default gw for ipv4) which does NAT64 through tayga too.
IMHO the best strategy is a mix of strategies:
- 1. Clatd doing 464XLAT (RFC 6877) so:
- 1.1 Stateful protocol translation (RFC 6146) at CG-NAT64
- 1.2 Stateless protocol translation (RFC 6145) at the UE
- 2. DNS64 (RFC 6147) mechanisms at the DNS server returning padded AAAA for A only entries
The main idea of my experiment was to run IPv6 only setup without any IPv4 connectivity:
sudo ip route get 8.8.8.8
RTNETLINK answers: Network is unreachable
I've been operating IPv6-only networks for enterprise and domestic use since late 2019, with DNS64/NAT64 on the gateway. Since 2021 some networks are behind Starlink CGNAT so I tunnel those networks over Wireguard to the gateway.
Like you I've detected a handful of applications that couldn't cope without local IPv4 - if they couldn't be patched they got dropped.
The issue I do hit - and report - from time to time is services that advertise both IPv6 and IPv4 addresses in DNS but do not respond to IPv6. Those are really annoying and even when I manage to get a response from the admins very rarely do they fix it either by accepting IPv6 connections or dropping the DNS AAAA record.
Another solution when emergency IPv4 is required (e.g. if the gateway has died!) is an IPv4 in IPv6 tunnel on the local network to the local IPv4-only gateway - think Starlink terminal.
This article made me put into a script the code I had for setting those tunnels up to make it easier, and avoid forgetting!
I have idea of even more hostile environment in my mind. My plan for next phase is to get rid of 127.0.0.1 on lo interface. I've tried it once and I had to reboot my machine as all things stopped working.
As another angle to make it even more interesting but on network scale I've implemented option for Unbound to suppress A records even if they do exist: https://github.com/NLnetLabs/unbound/pull/819 and push dual stack apps to be IPv6 only.
I'm using it to run electron-like apps, abusing Bonjour to provide .local domains with reverse (ex: spreadsheet.local could go to 127.1.2.3 if you forge and send the right mDNS packet on port 5353)
Unfortunately, I haven't found a way to do the same in IPv6: fec0::/10 for site-local address precedence 1 was deprecated by RFC3879
For your usecase, if you don't want to be restricted to ::1/128 you could maybe replace the 127/8 by fc00::/7 but it would require setting the link up while I want everything to be automatic
The tnat tool is quite clever. I previously ran a IPv6 only infrastructure and it worked really well, except for some "old" applications written in C which only handled IPv4. Which I had known of this hack.
It's a great tool for sure. I've tried to find approach to patch naughty IPv4 only apps with my own LD_PRELOAD library and during research phase I found tnat64 and it worked exactly as I expected.
> Luckily for us Linux provides exceptionally easy way to intercept some specific library functions using simple dynamically linked library: LD_PRELOAD
Doesn't LD_PRELOAD only work for non-statically linked executables?
These days the default is to dynamically link to libc, because a few parts of the standard library either fundamentally need to use libc, or have benefits from such linking (like supporting NSS based user/group lookup).
However, if you don't need to pull in any c libraries, you can use `CGO_ENABLED=0 go build` to build completely without linking to libc on linux. It is pretty common that applications will do that if they are not using the parts of the go standard library that need libc, and don't pull in C libraries.
Yes, static binaries would require a different hack.
I think something like the tampering feature of strace or a kprobe to intercept the syscall would work.
Does anybody have experience with this behind an ISP CGNAT network that provides IPV6 as well? I'm getting worn down from trying to deal with CGNAT and IPv4 for my homelab...
And please post the results of `dig -t AAAA ipv4only.arpa @$DNS` with $DNS being each of the DNS servers from your ISP:
"Using draft-ietf-behave-nat64-discovery-heuristic, the CLAT discovers the Pref64/n. The CLAT component sends an AAAA query to the DNS64 for the well-known IPv4-only name “ipv4only.arpa”. The Pref64/n is derived from the received AAAA response. The CLAT determines the used address format by searching the received IPv6 addresses for the well-known IPv4 addresses (192.0.0.170 or 192.0.0.171)."
Some ISP provide different pairs of AAAA depending on which of their DNS server you ask (maybe for round-robin load balancing?)
Major question: is something like this feasible with Opnsense as a router, or should I only try it with a Linux solution?
Minor related questions:
* How much does this complicate my firewalling?
* Do I deal with firewalling IPV6 only from the outside world?
* Or do I need to worry about RFC1918 addresses on my LAN "leaking" out to the IPv4 world via the IPv6 connection?
> Major question: is something like this feasible with Opnsense as a router, or should I only try it with a Linux solution?
It should be possible but I'm not familiar with opensense. If you can't use clatd there, you will need some other implementation of 464XLAT.
Then, if you want to offer IPv4 on your network, you'll have to use DHCP on a RFC1918 block (ex: offer IPs in 10.1.2.3) and masquerade to the 192.0.0.1 gateway you've created with your 464XLAT implementation (whether clatd or something else)
Here you'll have to use tayga as you don't seem to have a GW provided by your ISP level3.
> How much does this complicate my firewalling
Not much. The ip4 rules would be as before, but the clat interface would be your default ipv4 route so you'd need to replace all instances of `eth0` or `wlan0` by `clat` in your scripts on the machine running clatd
> Do I deal with firewalling IPV6 only from the outside world?
It depends if you want to firewall IPv6? If you fear some services are reachable by IPv6 while they shouldn't be, use ip6tables. Just remember in IPv6 you should keep icmp flowing as it serves many purposes.
You can also decide to not offer IPv6 at all on your lan (making it IPv4 only on 10.1.2.3, with the packets going to clatd 192.0.0.1 on your router)
> Or do I need to worry about RFC1918 addresses on my LAN "leaking" out to the IPv4 world via the IPv6 connection?
It shouldn't: IIRC 464XLAT implementations will only route non RFC1918 packets. Check the RFCs if you want to be sure, or forge packets to try.
OpenBSD, with PF and Unbound, has excellent NAT64/DNS64 support. Unfortunately, my ISP is still IPv4, but with HE tunnel broker I can at least experiment with an IPv6 only VLAN. Works great on all clients I tested: Windows, Debian, and *BSDs.
BTW, my ISP has been promising a /60 for many months now. Apparently, it's about their "provisioning software" they inherited. Huh, equipment less of a concern in this case.
It does. The problem is, how to find a sufficiently good 464xlat implementation for Linux. I know two: jool (which requires a custom kernel module) and clatd (where I had to report a bug for such an obvious wrong as a deadlock during boot - thankfully fixed now).
