Coming from the Apple ecosystem, this is solved on macOS/iOS by a native implementation of 464XLAT on the device (particularly the CLAT relay part.)
If you have a working NAT64/DNS64 setup, macOS can make a AAAA (ipv6 DNS) request to ipv4only.arpa, and observe the form the result comes back as, in order to learn the IPv6 prefix used for IPv4 compatibility on the network (eg. 64:ff9b::/96), and if it's not given an IPv4 address via DHCP, will set up a local interface at 192.0.0.1 that is the default route for all IPv4 traffic. Anything sent to this interface will translate the address to the corresponding IPv6 compatibility address and send it to your IPv6 router (which should use NAT64 to send it to the destination.)
In this sense, you don't need any IPv4 infrastructure at all in your network (no DHCP, etc) and all traffic on your LAN will be IPv6, but IPv4-only apps (including those that hardcode IPv4 addresses and try to connect to them) work fine.
A quick web search says that linux has a similar thing implemented as a userspace daemon (clatd) which presumably does something similar, and importantly doesn't rely on LD_PRELOAD hacks like this article suggests (LD_PRELOAD doesn't work with static binaries like those written in Go, for instance.)
The largest problem with this is that that this IPv6 router lives outside of your devices. It lives somewhere at the ISPs infrastructure.
And this causes a massive headache when it comes to systems that track you based on your IPv4 address. For example there are applications that track you by your IP address. And if you want to opt-out they refuse because the IPv4 address you give them is owned by T-Mobile.
Also, it completely breaks stateless applications.
When you have an IPv4 <> IPv4 UDP tunnel you can just send traffic. If one device is behind NAT you set up port forwarding. It'll work today, it'll work tomorrow, and in 2 years.
The tunnel that the NAT64 system sets up is time-bound. So while outgoing traffic re-establishes the route, incoming traffic is not stateless. It stops.
I have this issue with WireGuard and iOS. The iOS implementation sadly prefers A over AAAA. So when I'm on 5G it connects over a NAT64 route, but due to the NAT64 route dropping after x time push notifications break. When you then turn on the phone, some traffic re-establishes the NAT64 tunnel and all of the sudden you get a whole bunch of notifications.
Thank you for sharing! Yes, macOS has such logic and it works just fine. The main issue from clatd that it's pretty tricky to setup and it emulates presence of IPv4 on machine which is not very desirable as it tends to hide issues with other tools.
My plan was to explicitly disable IPv4 connectivity for machine and hide it from other app but keep it active for subset of well known broken tools and then fix them one by one and switch to IPv6 only setup.
Would be interesting to know which applications actually have problems with v6 - the example with directly using a v4 IP is more a user error, not an application issue.
I pretty much stopped submitting patches enabling v6 functionality to various projects back in 2005 as everything I cared about was working at that point. (Side note, I was just trying to search a few of those - but seems that period pretty much doesn't exist in search engine caches anymore. I knew the state of preserving internet history is bad, but I didn't expect it to be _that_ bad)
Docker's support for IPv6 is really poor. Basics are still gated behind the "experimental" flag, and there are bugs that have been open for years preventing very common configurations from working.
The folding@home client, for example, is written in C with a "does everything" library (called cbang if I recall correctly). The library only uses sockets with AF_INET and thus it doesn't work even with AAAA records..
There seem to be hard cuts in search returns at 5 and 10 years, it's been really difficult to find anything from before 2012 without incredibly specific searches. Lots and lots of link rot too so it's hard to say how much of that is google/bing/etc.
If I don't have IPv4 connectivity, yet a 6-to-4 gateway exists and I have IPv6 connectivity, and some app tries to use IPv4, then clearly the gateway should be used.
How about some sysfs config option that says "redirect ipv4 to 6to4 gateway if no default ipv4 route exists", enabled by default.
Yeah I agree this does seem like something that really ought to simply be configurable out of the box with options for transparently handling both 6-to-4 and 4-to-6 when the appropriate services are discoverable or configured on the network.
The top level reply here discussing how MacOS handles it seems like something that should be able to be recreated with iptables, but when searching I am extremely surprised to discover that Linux does not seem to have the ability to do anything similar. It seems most solutions focus on using socat in userspace to proxy data between the sockets which is not really a practical solution.
> How about some sysfs config option that says "redirect ipv4 to 6to4 gateway if no default ipv4 route exists", enabled by default.
There are various 6to4 on-ramps that solve this. Popular ones are NAT64/DNS64, 464Xlat, and DS-Lite. In my experience, DS-Lite works nicely with v4-only apps/services or v6-only apps/services.
I'm of the opinion that IPv6 is old enough that the fact we have not hopped to it yet means its not happening anytime soon. I wanted it back in 2008 when I first learned about it, and I know its older than that (90s iirc) so its either going to come one day "abruptly" by force and break half the internet, or people will do hacks to maintain IPv4 as is.
I think the only way IPv6 will ever become mainstream is if either the EU or US Congress pass a bill making it the preferred IP standard.
"The WordPress.org systems team DO have IPv6 plans, but at present there are higher priority tasks and there's no widespread requirement for IPv6 connectivity."
Its not possible to run a WordPress instance and auto-update with IPv6-only and without any kind of adress translation.
The main advantage of Linux over other systems is that its available from source and thus can be patched and recompiled easily. Here we see someone using LD_PRELOAD to patch the behavior of a binary, because they rely on distributions pre-compiled packages without means to change the source code themselves. This sort of negates that advantage, right?
I made a Terrible decision of a project at Netflix. The idea was that you could swap out an IPv4 (AF_INET/SOCK_STREAM) socket with an AF_INET6 one.
Turns out actually doing this with the Linux kernel is exceptionally difficult. You can swap out the underlying sk, but doing it safely is damn near impossible because the two data structures aren’t really built like that.
One day, I’d love if someone added the ability to swap Unix sockets for TCP sockets at runtime to the kernel — for other reasons.
No one is debating it's not ready for production use. It's just that it's a lot easier to configure clients in dual stack than do a 6 to 4 translation.
Super cool! I tried doing a pure IPv6 network a little over a decade ago; Maybe I’ll try it again. Though, my cheap IoT devices likely still need IPv4… but perhaps not internet connectivity. It might be fun to explore just how much IPv4 continues to be ingrained into cheap Things (eg: Arduino WiFI?) There always seems to be a long tail of small places where IPv4 pops straight back into the equation.
Does anyone have a good write up of taking ones home network and going 100% ipv6 including dealing with iot devices that can't? I am thinking of doing it but I have a huge mix of devices from linux to windows and servers.
I moved to a new place ~600 meters away and had to go from having IPv6 over FTTH to IPv4 over copper. It's been over 6 months but I still can't get over it.
Instead of doing something like `export A="64:ff9b::"` and then using `ssh $A1.3.3.7`, it's apparently much easier to install a new software package and do `export LD_PRELOAD=/the/new/package` and hope it doesn't break anything...
I think retrofitting IPv4-only apps for IPv6 compatibility might be a short-term fix. It could be more forward-thinking to focus on developing new apps with inherent IPv6 support to prevent accruing technical debt and facing complications tied to maintaining outdated IPv4-only applications.
So when and how will IPv6 become the absolute standard? I presume an act of government law would do it, otherwise, if tech companies got together to force the change en masse, that would also do it.
I don't understand why IPv6 has not become more prevalent over the coming years. Seems like we're taking baby steps and growing in our dependence on IPv4 IPs, although based on other comments here it sounds like at least Linux and Mac have a way to handle this transparently, not sure about Windows.
Not directly related, Recently I was looking at Hetzner cloud and noticed IPv6 only server instances are cheaper, can I use such service to serve my back-end while front-end is hosted on CF pages? I think IPv4 only hardware are rare these days, Am I wrong?
(BTW sorry for my dumb questions)
CF is capable of reverse proxying onto a v6-only backend server. I'm not very enthused by how much of the Internet is hosted behind Cloudflare, but they're certainly convenient for this exact use-case.
[+] [-] ninkendo|2 years ago|reply
If you have a working NAT64/DNS64 setup, macOS can make a AAAA (ipv6 DNS) request to ipv4only.arpa, and observe the form the result comes back as, in order to learn the IPv6 prefix used for IPv4 compatibility on the network (eg. 64:ff9b::/96), and if it's not given an IPv4 address via DHCP, will set up a local interface at 192.0.0.1 that is the default route for all IPv4 traffic. Anything sent to this interface will translate the address to the corresponding IPv6 compatibility address and send it to your IPv6 router (which should use NAT64 to send it to the destination.)
In this sense, you don't need any IPv4 infrastructure at all in your network (no DHCP, etc) and all traffic on your LAN will be IPv6, but IPv4-only apps (including those that hardcode IPv4 addresses and try to connect to them) work fine.
A quick web search says that linux has a similar thing implemented as a userspace daemon (clatd) which presumably does something similar, and importantly doesn't rely on LD_PRELOAD hacks like this article suggests (LD_PRELOAD doesn't work with static binaries like those written in Go, for instance.)
[+] [-] WirelessGigabit|2 years ago|reply
And this causes a massive headache when it comes to systems that track you based on your IPv4 address. For example there are applications that track you by your IP address. And if you want to opt-out they refuse because the IPv4 address you give them is owned by T-Mobile.
Also, it completely breaks stateless applications.
When you have an IPv4 <> IPv4 UDP tunnel you can just send traffic. If one device is behind NAT you set up port forwarding. It'll work today, it'll work tomorrow, and in 2 years.
The tunnel that the NAT64 system sets up is time-bound. So while outgoing traffic re-establishes the route, incoming traffic is not stateless. It stops.
I have this issue with WireGuard and iOS. The iOS implementation sadly prefers A over AAAA. So when I'm on 5G it connects over a NAT64 route, but due to the NAT64 route dropping after x time push notifications break. When you then turn on the phone, some traffic re-establishes the NAT64 tunnel and all of the sudden you get a whole bunch of notifications.
[+] [-] pavel_odintsov|2 years ago|reply
Thank you for sharing! Yes, macOS has such logic and it works just fine. The main issue from clatd that it's pretty tricky to setup and it emulates presence of IPv4 on machine which is not very desirable as it tends to hide issues with other tools.
My plan was to explicitly disable IPv4 connectivity for machine and hide it from other app but keep it active for subset of well known broken tools and then fix them one by one and switch to IPv6 only setup.
[+] [-] e61133e3|2 years ago|reply
[+] [-] finaard|2 years ago|reply
I pretty much stopped submitting patches enabling v6 functionality to various projects back in 2005 as everything I cared about was working at that point. (Side note, I was just trying to search a few of those - but seems that period pretty much doesn't exist in search engine caches anymore. I knew the state of preserving internet history is bad, but I didn't expect it to be _that_ bad)
[+] [-] josephcsible|2 years ago|reply
[+] [-] Faaak|2 years ago|reply
[+] [-] yetanotherloss|2 years ago|reply
[+] [-] nova77hn|2 years ago|reply
[+] [-] dementik|2 years ago|reply
[+] [-] londons_explore|2 years ago|reply
If I don't have IPv4 connectivity, yet a 6-to-4 gateway exists and I have IPv6 connectivity, and some app tries to use IPv4, then clearly the gateway should be used.
How about some sysfs config option that says "redirect ipv4 to 6to4 gateway if no default ipv4 route exists", enabled by default.
[+] [-] p1mrx|2 years ago|reply
[+] [-] gorkish|2 years ago|reply
The top level reply here discussing how MacOS handles it seems like something that should be able to be recreated with iptables, but when searching I am extremely surprised to discover that Linux does not seem to have the ability to do anything similar. It seems most solutions focus on using socat in userspace to proxy data between the sockets which is not really a practical solution.
[+] [-] ignoramous|2 years ago|reply
There are various 6to4 on-ramps that solve this. Popular ones are NAT64/DNS64, 464Xlat, and DS-Lite. In my experience, DS-Lite works nicely with v4-only apps/services or v6-only apps/services.
[+] [-] yrro|2 years ago|reply
[+] [-] the8472|2 years ago|reply
[+] [-] xerces8|2 years ago|reply
[+] [-] kuon|2 years ago|reply
[+] [-] giancarlostoro|2 years ago|reply
I think the only way IPv6 will ever become mainstream is if either the EU or US Congress pass a bill making it the preferred IP standard.
[+] [-] johnklos|2 years ago|reply
[+] [-] zajio1am|2 years ago|reply
[+] [-] VoodooJuJu|2 years ago|reply
[+] [-] maltris|2 years ago|reply
https://meta.trac.wordpress.org/ticket/3090
"The WordPress.org systems team DO have IPv6 plans, but at present there are higher priority tasks and there's no widespread requirement for IPv6 connectivity."
Its not possible to run a WordPress instance and auto-update with IPv6-only and without any kind of adress translation.
[+] [-] maltris|2 years ago|reply
[+] [-] johnklos|2 years ago|reply
This is sad, but not surprising.
[+] [-] heartjudytenuta|2 years ago|reply
[+] [-] blueflow|2 years ago|reply
[+] [-] sargun|2 years ago|reply
Turns out actually doing this with the Linux kernel is exceptionally difficult. You can swap out the underlying sk, but doing it safely is damn near impossible because the two data structures aren’t really built like that.
One day, I’d love if someone added the ability to swap Unix sockets for TCP sockets at runtime to the kernel — for other reasons.
[+] [-] trustingtrust|2 years ago|reply
No one is debating it's not ready for production use. It's just that it's a lot easier to configure clients in dual stack than do a 6 to 4 translation.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] imoverclocked|2 years ago|reply
[+] [-] red_trumpet|2 years ago|reply
When I disabled IPv4 a few weeks ago, I couldn't use: HN, GitHub, Reddit, Discord, Duckduckgo.
[+] [-] nelgaard|2 years ago|reply
I recently had to setup a non-encrypted website because I have a few old devices that can no longer do HTTPS.
IPv4 on local networks will probably exist for a very long time.
[+] [-] usr1106|2 years ago|reply
[+] [-] chungy|2 years ago|reply
In the example, 64:ff9b::103:307 is equivalent. A more complicated example might be akin to 64:ff9b::198.51.100.231, equivalent to 64:ff9b::c633:64e7.
[+] [-] pavel_odintsov|2 years ago|reply
[+] [-] g232089|2 years ago|reply
[+] [-] zekica|2 years ago|reply
[+] [-] sschueller|2 years ago|reply
[+] [-] xerces8|2 years ago|reply
(they say my or most ISP can enable ipv6 on reuest; country : Slovenia, year : 2023)
[+] [-] unmole|2 years ago|reply
[+] [-] simiones|2 years ago|reply
[+] [-] pavel_odintsov|2 years ago|reply
[+] [-] loondri|2 years ago|reply
[+] [-] BlueTemplar|2 years ago|reply
[+] [-] WorldMaker|2 years ago|reply
In general, consumer apps and consumer APIs are being developed with IPv6 support.
The new apps to name and shame for not natively supporting IPv6 in 2023 are mostly corporate and Big Enterprise.
[+] [-] giancarlostoro|2 years ago|reply
I don't understand why IPv6 has not become more prevalent over the coming years. Seems like we're taking baby steps and growing in our dependence on IPv4 IPs, although based on other comments here it sounds like at least Linux and Mac have a way to handle this transparently, not sure about Windows.
[+] [-] nerdyadventurer|2 years ago|reply
[+] [-] Dagger2|2 years ago|reply
[+] [-] cramjabsyn|2 years ago|reply