Enabling IPv6 support for IPv4 only apps on Linux | Hacker News Reader

Enabling IPv6 support for IPv4 only apps on Linux

pavel.network

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

Recentish macOS versions include 464XLAT as well, but it isn't enabled on WiFi and Ethernet (by default).

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.

[1] https://lwn.net/Articles/451914/

This is a link to a thesis. Can you recommend some implementations for linux and talk about your experience?

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.

Come on github! It's not that hard!

Yep GitHub is one of the main reasons why I started work on NAT64 box next day after switching to IPv6.

Most of the services I need for work do support IPv6 and the only exceptions is GitHub.

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

- 3. IPv4 embedding into IPv6 addresses (RFC 6052 section 2.2)

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

So I intentionally decided not to have IPv4 connectivity system wide to catch apps with issues in IPv6 only environment and then carefully evaluate issues and report them to authors: https://github.com/mozilla-mobile/mozilla-vpn-client/issues/... https://github.com/signalapp/Signal-Desktop/issues/4121

Dual stack setups tend to hide IPv6 implementation issues and may create illusion that app is IPv6 compatible but in reality it's not.

Clearly my setup is too hostile for home users but as developer I enjoy it a lot.

Oh I may have misunderstood the purpose then!

> Clearly my setup is too hostile for home users but as developer I enjoy it a lot.

If you want to discover which apps need IPv4, that's indeed a great way!

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.

127/8 is fun!

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

See my proof of concept https://github.com/csdvrx/PerlPleBean/blob/main/experiments/... and the IPv6 explanations around line 70

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

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!

https://gist.github.com/iam-TJ/135b47d29bd8ee4e0f3330aef7324...

Kinda sad that https://news.ycombinator.com/ is still only available via legacy IPv4. Any idea who could fix this and enable IPv6 on this site?

Great catch. I did not notice it:

dig -t aaaa news.ycombinator.com @8.8.8.8 +short

Returns empty result.

Still wondering when my IPv4-only ISP will consider starting to offer IPv6 service.

I think I heard they promised to start rolling it out around 2012

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?

Yes. It should work for most binaries that don't link statically with libc.

The point is that e.g. many programs written using Go are not like that.

They should support IPv6 out of the box though.

Go doesn't link against libc?

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.

Honest question:

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

I do. Ask your questions.

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?)

OK, dig responses: DNS1 8.8.8.8 (google, obviously) """ dig -t AAAA ipv4only.arpa @8.8.8.8

; <<>> DiG 9.18.13 <<>> -t AAAA ipv4only.arpa @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19770 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;ipv4only.arpa. IN AAAA

;; AUTHORITY SECTION: ipv4only.arpa. 568 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2022072100 7200 3600 604800 3600

;; Query time: 14 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) ;; WHEN: Mon May 01 14:10:21 EDT 2023 ;; MSG SIZE rcvd: 99 """

DNS2 209.244.0.3 (it's at Level3) """ dig -t AAAA ipv4only.arpa @209.244.0.3

; <<>> DiG 9.18.13 <<>> -t AAAA ipv4only.arpa @209.244.0.3 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14893 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION: ;ipv4only.arpa. IN AAAA

;; AUTHORITY SECTION: ipv4only.arpa. 1481 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2022072100 7200 3600 604800 3600

;; Query time: 10 msec ;; SERVER: 209.244.0.3#53(209.244.0.3) (UDP) ;; WHEN: Mon May 01 14:11:08 EDT 2023 ;; MSG SIZE rcvd: 88 """

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.

Doesn't xlat do this?

Yes it does. I have no idea what the 'right' way to set that up on linux is though.

yay -S clatd (or apt-get install for debian derivatives)

export YOURFAVORITEDNS=2001:4860:4860::6464

drill -t aaaa ipv4only.arpa @$YOURFAVORITEDNS

clatd dns64-servers=$YOURFAVORITEDNS

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

Very interesting 🤔

Emoji on HN?

Reply on news.ycombinator.com