[HN Gopher] Enabling IPv6 support for IPv4 only apps on Linux
       ___________________________________________________________________
        
       Enabling IPv6 support for IPv4 only apps on Linux
        
       Author : pavel_odintsov
       Score  : 78 points
       Date   : 2023-05-01 14:50 UTC (8 hours ago)
        
 (HTM) web link (pavel.network)
 (TXT) w3m dump (pavel.network)
        
       | fghorow wrote:
       | 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...
        
         | csdvrx wrote:
         | 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?)
        
           | fghorow wrote:
           | 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?
        
             | csdvrx wrote:
             | > 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.
        
       | Faaak wrote:
       | 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.
        
         | pavel_odintsov wrote:
         | 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.
        
       | csdvrx wrote:
       | 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)
       | 
       | Suggested reading: https://www.apnic.net/wp-
       | content/uploads/2017/01/IPv6_Migrat...
        
         | pavel_odintsov wrote:
         | 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.
        
           | iam-TJ wrote:
           | 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...
        
           | csdvrx wrote:
           | 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!
        
             | pavel_odintsov wrote:
             | 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.
        
               | csdvrx wrote:
               | 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/PerlPle
               | Bean/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
        
       | narutowindy wrote:
       | Very interesting
        
         | actionfromafar wrote:
         | Emoji on HN?
        
       | realid wrote:
       | 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?
        
         | pavel_odintsov wrote:
         | Great catch. I did not notice it:
         | 
         | dig -t aaaa news.ycombinator.com @8.8.8.8 +short
         | 
         | Returns empty result.
        
       | homero wrote:
       | Doesn't xlat do this?
        
         | ianlevesque wrote:
         | Yes it does. I have no idea what the 'right' way to set that up
         | on linux is though.
        
           | csdvrx wrote:
           | 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
        
         | patrakov wrote:
         | 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).
        
       | jacob019 wrote:
       | 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.
        
         | Spivak wrote:
         | 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/
        
           | csdvrx wrote:
           | This is a link to a thesis. Can you recommend some
           | implementations for linux and talk about your experience?
        
         | csdvrx wrote:
         | 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
        
           | jeroenhd wrote:
           | 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.
        
             | csdvrx wrote:
             | 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
        
             | crest wrote:
             | Recentish macOS versions include 464XLAT as well, but it
             | isn't enabled on WiFi and Ethernet (by default).
        
       | idatum wrote:
       | 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.
        
       | genpfault wrote:
       | > 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?
        
         | 77pt77 wrote:
         | Yes. It should work for most binaries that don't link
         | statically with libc.
        
           | nine_k wrote:
           | The point is that e.g. many programs written using Go are not
           | like that.
           | 
           | They should support IPv6 out of the box though.
        
             | 77pt77 wrote:
             | Go doesn't link against libc?
        
               | jsmith45 wrote:
               | 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.
        
         | rnhmjoj wrote:
         | 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.
        
       | loeg wrote:
       | Still wondering when my IPv4-only ISP will consider starting to
       | offer IPv6 service.
        
         | russdill wrote:
         | I think I heard they promised to start rolling it out around
         | 2012
        
       | darkhelmet wrote:
       | 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!
        
         | pavel_odintsov wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2023-05-01 23:02 UTC)