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.
> The largest problem with this is that that this IPv6 router lives outside of your devices. It lives somewhere at the ISPs infrastructure.
I use my own router which supports NAT64. I use OpenBSD which supports it natively in-kernel, but you can get NAT64 with any competent router software (OpenWRT, pfsense, etc.)
> 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.
Huh? I don't follow what you're saying... websites see an IPv4 address when I connect. I'm using NAT64, after all. It's just the _client OS_ that thinks it doesn't have an IPv4 address. My OS sends traffic as IPv6 to 64:ff9b::/96, but the router turns around and makes an IPv4 request with the IPv4 address I get from my ISP. I have IPv4 at the gateway but nothing else in my network sees it.
> Also, it completely breaks stateless applications.
I don't know what this means but I haven't seen a single broken application?
> 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.
I can NAT inbound IPv4 requests to my internal IPv6 machines too, I don't know what the issue is for you here. I choose not to, since I don't want to deal with it, but the option is available if I want.
> 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 don't know what you're referring to here... it's exactly the same as how NAT works in IPv4. Outbound requests from my internal network are tracked with NAT, and return traffic is rewritten back to the IPv6 address that sent it. There's no difference between that and IPv4 outbound NAT here. I don't know what you're talking about with "tunnels" or anything.
NAT64 is just stateful NAT, exactly the same as IPv4 stateful NAT. It happens to be translating between v4 and v6 as part of the translation, but it’s no different whatsoever from pure-IPv4 NAT in this regard. You can call it “tunneling” if that helps you conceptualize it, sure, but you shouldn’t extend the tunneling analogy to make it seem like it’s conceptually different from IPv4 NAT, because it isn’t.
This phrase:
> 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.
Makes it seem like NAT64 is doing something conceptually different from what we’ve had for decades with every IPv4 network. It’s not.
And when OP says:
> 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
Everything they just said applies to NAT64 too. You can “set up port forwarding” of your public IPv4 address to forward to an internal IPv6 address too. It’s just NAT!
Edit: I think what’s happening in this discussion, is that WirelessGigabit responded to my comment about my home setup, with drawbacks about their T-Mobile setup, which was a bit of a change of subject. It took a few re-readings of their comment for this to become clear. In my toplevel post I’m referring to a scenario where my ISP gives me an IPv4 address, but I don’t have IPv4 enabled in my LAN. (No IPv4 DHCP addresses are being handed out, my router does not have a v4 address on its LAN link.) WirelessGigabit is referring to a setup like in T-Mobile, where they’re putting the NAT64 box somewhere in T-Mobile’s infrastructure, and thus WirelessGigabit has no control over doing things like setting up port forwarding rules, etc. Basically they’re complaining about things I never mentioned about my setup. And as others have pointed out, T-Mobile’s XLAT setup is basically CGNAT by another name, but one where if your use case is pure IPv6, there’s a path to avoiding the NAT issues. This is very different from my case.
Google and Apple have both established an unofficial standard that any middleboxes that keep state (eg. NAT) has to keep a session open for 30 minutes for both TCP and UDP. Anyone that doesn't will have push notifications failing as you've pointed out.
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.
It don't even support dynamically assigned ipv6 address. And ipv6 prefix need to be hardcoded into config. And even worse , ipv6 address(not suffix) is bounded directly to the container at creation time. If your ipv6 prefix changed for whatever reason.(laptop is a thing since 20 years ago, you know) Best you can do is scrap the container and make a new one. I would say keep it experimental at current status is a good decision. It's simply not usable currently.
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.
40-45% of Google traffic uses IPv6. If you are in the US, your mobile traffic is probably IPv6. At home, your ISP likely supports IPv6, you can get by enabling on router or upgrading router.
The problem areas are with hosting and corporate networks. The Google numbers are smaller during the week as people use IPv4-only corporate networks.
Yeah, we need more incentive. Ipv6 is harder to implement yes, it is true, there is no point in denying this and arguing it solves tons of problem (it does). Most companies have ipv4 experience and it's just simpler. There must be some political pressure to make it move. But "hopefully" the economical pressure is starting to build up, a lot of providers are cheaper in ipv6 only configuration.
Still, for a company like discord, not even using host names to allow DNS64 is really sad.
One thing that might help is government regulation that any ISP using CGNAT must offer IPv6. Customers should get public IP address, single IPv4 or /64 IPv6.
Another would be that government customers need to have IPv6-enabled sites. This could get a lot of companies to add IPv6 hosting.
> One thing that might help is government regulation that any ISP using CGNAT must offer IPv6. Customers should get public IP address, single IPv4 or /64 IPv6.
My understanding is they largely do. It's the ISPs that have enough IPv4 addresses that don't feel a need to upgrade, and the website operators who $3/server/month for an IPv4 address is a rounding error.
Some of this is unavoidable while fixing the scaling problems of IPv4. Longer addresses are never going to be preferable for users over shorter addresses, but addresses are necessarily going to be longer than IPv4 if it's going to support more devices.
The existing users that already have short addresses should be able to keep them (ignoring the trailing 0s), and even the newer longer ones don't need to be 128 bits.
::ffff:<IPv4 address> is a perfectly valid V6 address. The problem is not the user facing representation but all the software and hardware implementations, including in middleboxes in between client and server.
128 is no different to 33 bits, or 32 bits plus extension header in that regard.
It's valid but not routable in practice. The Internet collectively didn't choose to map existing IPv4 addresses into v6 or keep the routing unified, that's the problem. It should've been that 1.1.1.1 on v4 now owns 1.1.1.1/32 on v6, so going all-v6 doesn't mean cutting yourself off from v4 hosts. Once v6 was well-adopted, they could start using the longer addresses. Instead, we got two totally separate networks.
This is an "IPv6" network that does not allow for more users. The IPv4 network space is already depleted. This is why mobile ISPs, Indian ISPs etc. are all dual stack with CGNAT for IPv4.
Perhaps you meant to suggest that they should own 1.1.1.1::/64 or 1.1.1.1/128 (or 1:1:1:1::/64)?
Even if it's the latter case, both the actual ::ffff:1.2.3.4 (or it's predecessor ::1.2.3.4) have the problem that some middle box receives a packet for 1.1.1.1::abcd:1234, doesn't understand the header the abcd:1234 portion is encoded in, throws it away, and the router at 1.1.1.1 receives a packet which is destined for some unknown device behind the router with no info for how to get the packet to that device.
Yes, it wouldn't allow more users, which would've been fine back then. They'd focus on getting everyone onto the v6 protocol first, then open up the new addresses for use. That's the transition period that never happened.
The only motivation for the ISPs etc., who you need to get onboard, is to get more users. This is why IPv6 adoption has been soaring in the last 3-4 years when there's large new use cases that cannot economically get addresses in the volume they would require and didn't happen when IPv4 addresses were more freely available.
The only other way to get them to invest in alternatives to IPv4 before IPv4 stopped meeting their business needs would have been via regulation.
We did map existing v4 addresses into v6. They're not two totally separate networks at all.
But the limitations of v4 and of existing v4 devices limit the ways that can work. Reinventing stuff and calling it "4.1" won't change that. You'll still face all of the same limitations.
> They'd focus on getting everyone onto the v6 protocol first, then open up the new addresses for use. That's the transition period that never happened.
That's basically the transition period that _is_ happening, except we aren't delaying the "open up the new addresses" stage -- the new addresses are usable straight away for anything you've migrated.
China has mandated moving to single-stack IPv6 by the end of the decade.
It is not well publicized.
It turns out when you have a government that can tell you "move to IPv6 or we'll have your legs broken and your family thrown in prison" it's a bit easier to get things moving.
When they need to solve the address space crisis, they can make a "v4.1" that's just v4 but with an expanded address space. Existing addresses and decimal format stay; NAT DNS DHCP ARP etc stay mostly the same aside from supporting longer addresses. Cloudflare DNS is still 1.1.1.1, my private ip is 192.168.1.2, public 71.177.17.171, some new ISP hands out 11.127.13.121.143.356 when they run out of shorter addresses, life moves on.
I know v6 supports NAT, but it was basically designed to remove it with the whole random addressing scheme, and that isn't necessary for solving this problem (idk if things were different in the 1990s).
They'd have to expand the header in a backwards-incompatible way, yes. IPv6's issues don't all stem from that. Changing all the existing addresses, adding new special kinds of addrs, trying to ditch NAT, and maybe even changing the human-readable format of addrs created most of this resistance. Asking someone to go v6 is asking for a whole network redesign, with an end result that isn't exactly simpler.
Swap in v4.1-compatible stuff and you'd be done. Sending to short address uses v4, sending to long uses v4.1.
If you expand the header in a backwards-incompatible way, you have to upgrade all the routers and endpoints. You'd need to extend other protocols, like BGP and OSPF, to even route your "v4.1" prefixes. You'd have the exact same dual stack issues as you do with v6.
Why bother? IPv6 is available today and has been here for over 20 years. The truth is it is actually simpler to deploy than v4. For example, the address format makes it easier to understand subnetting (because it's hex.) NAT is an abomination and we should be glad to see it go: end-to-end connectivity is how the internet is supposed to work. I remember the old days (the 90's) where we all had public IP addresses on our desktops. VPNs are much simpler: there's no potential for overlapping RFC-1918 addresses because v6 is globally unique. I could go on.
The only reason v6 is dual stack is because they're changing all the existing addresses and routing. If you're only creating a second header format that everything is updated to support, it can be mostly unified. Routing tables etc would all shared.
> end-to-end connectivity is how the internet is supposed to work
This is the secondary motive of ipv6 that makes it not happen, cause not enough people agree with this statement. Most home and corporate users have little interest in outside connectivity, or when they do, it's easy to forward ports. And it's important how even the cheapest router or least savvy user won't accidentally expose local devices to inbound connections; see another user's note on unsafe defaults https://news.ycombinator.com/item?id=37765946
If you personally would like to go NAT-free on your network, still all you need is plentiful addresses like v4.1, but it wouldn't be the default that everything is optimized around.
> The only reason v6 is dual stack is because they're changing all the existing addresses and routing. If you're only creating a second header format that everything is updated to support, it can be mostly unified. Routing tables etc would all shared.
A new header format is a new version of IP. That's how it was designed. That's the compatibility story of IP. There is no way (there never was a way) to change the IPv4 header format without incrementing the version number. There is no way to not create a "second" stack when you increment the version number. Different versions are always different "stacks". They are always going to have different mechanics and need different hardware.
All the other things that IPv6 changed didn't make it a different stack. Making a version 6 at all made a new stack and all the other things were changed to throw in additional improvements (and make things simpler) since there needed to be a different stack anyway. If version 6 had changed "just" the header it still would have been just as hard to upgrade to, but people would have even fewer reasons to upgrade.
You can call it a separate stack if you want, either way, the difficulty of going v6 comes from having totally separate addresses and routes as opposed to sharing everything. Basically every system out there is already capable of handling ipv6 headers, but they don't use it.
If you increase the size of the address with "v4.1", you have the same situation as v6: a new protocol. How are you going to announce "v4.1" routes without updating BGP? You can't.
You'd update BGP and the routers. They'd support both v4 and v4.1 packets with unified routing. All existing ownership of /32s from ipv4 would get carried over. Say v4.1 addrs are 64-bit max. V4.1 dst=1.2.3.4.53.2.1 could get BGP-routed to a 1.2.3/24 router, routed to a 1.2.3.4/32, to 1.2.3.4.53/40, to the dst. Also, during the transition period, a v4.1 packet addressed to a 32-bit addr would get auto-translated to v4.
This is unlike v6, which cannot address anything inside the v4 space. v6 and v4 are totally separate planes.
BGP was already creaking under exponential growth effects under v4. It was the opinion of engineers deeper in that than me that BGP as it stood wouldn't have supported the weight of routes beyond 32-bits without massive tables that would not scale well at all. BGP was considered to be on the list of things that drastically needed to change as the address space expanded. (Again, you don't have to take my word for it, the IETF notes are of the various debates are generally public and so are the resulting RFCs.)
You are doing a lot of magic heavy lifting in "You'd update BGP and the routers" as if there was a way to do that with a "small point update", especially once you realize how much firmware and hardware was always the issue that needed changing; updating IP was never an easy software-only problem. Just because you think you can imagine it doesn't mean it was technically feasible, especially at internet scale. Engineers spent years exploring options before they arrived at the IPv6 proposals. The space/memory inefficiency of v4 BGP was one of the problems they had to address. Sure, they felt a need to address it with a brand new protocol with less resemblance to BGP than some would have liked, but that wasn't because they were a priori trying to make life more difficult for everyone: they wanted devices to be able to route IPv6 without needing GBs to TBs of RAM just for routes and were afraid that "just use good old BGP but massively extended with a larger address space" was going to go that way and possibly quickly.
I don't mean to downplay the difficulty of supporting longer addresses in these systems, but it's been done for v6 already. That technical challenge has been mostly solved, and an adoption problem has taken its place.
There's no IPv6 adoption problem in the consumer and developing world space. The remaining adoption hold-outs are corporate interests and the reasons for their hold-outs have generally nothing to do with BGP or other dissimilarities between v4 and v6, and everything to do with cargo culting "security best practices", sunk cost fallacy, and kind of generally wealth (massive ancient investments in IPv4 address space, including some ancient early windfalls when companies like Microsoft and GE got /8s just for asking in the right years; for now a lot of corporate America can easily afford to only support IPv4 for "business operations" so long as they don't have to deal with some major consumer networks).
There are major IPv6-only consumer networks (it's now quite common among the mobile carriers). IPv6 routing is starting to be generally faster and more reliable for consumers. Consumers have easily adopted v6 mostly without realizing it. ("Happy Eyeballs", indeed.)
There's no "adoption problem". It is adopted. It is working as intended. Will there be a day that we "turn off v4 for good"? Probably not, but every engineer who helped build v6 should have been well aware of Postel's Law and its many corollaries and the root "Internet law" that "no matter how many networks exist, they will always communicate and cooperate; there are many networks but only one Internet". IPv1 and IPv2 likely will always be the only IP versions to truly die and that will always be an historic accident of when IPv4 was devised while the Internet was still mostly young and "just" a research project among academics. Killing IPv4 was never the goal of IPv6, it had to live side-by-side, and everyone knew it. Is IPv6 a "success" at current adoption rates? Success is subjective. Obviously we disagree on how successful it is/has been. That may not change, because they are and always will be opinions.
Enough things are v4-only that I can't go all-v6 at home, and that's predicated on my home ISP giving a v6 address, which hasn't been a given. V6 does seem intended to replace v4, otherwise I don't see the point; it's preferable to run one stack rather than two, and v4 is the easier choice still.
Why would the point of v6 be to entirely replace v4? That's such an impossible to accomplish goal even if v6 was the most perfect protocol to ever exist and even if you didn't believe that by that point v4 was embedded in so much hardware as to be physically impossible to replace without incredible amounts of hardware recycling problems, including some dangerous deep sea diving and missions to space. Even in your own home you indicate you likely have hardware that you aren't in a hurry to replace.
The point of IPv6 was always to build an internet that could address the next several billion devices. IPv4 addressed way more devices than its developers ever intended and did an arguably above-and-beyond job at addressing the first billion or so. (We can argue for hours though on how hacks like NAT44 have broken some of the original spirit of IPv4, of course, in the course of prolonging its useful device addressing lifespan.) IPv6 is succeeding in that. There are emerging world devices getting addressed that could never afford a cramped IPv4 address. There are nearly as many mobile devices running IPv6-only or IPv6-first as servers in the first couple of decades of IPv4.
Will all of the "first billion" devices move to the new protocol? On the one hand, probably not. On the other hand, does it matter? The dream of the internet was always about bridging a bunch of networks that had no right talking to each other and that many people thought it impossible that they would ever speak common protocols. There's only one internet because no matter how complicated it gets, people are still cobbling together incredible ways for different stacks to talk to each. This is how the internet was built, this is how the internet will always exist. This was true in the era when internet tools were built out of putty around unix-to-unix copy somehow speaking to VAX servers across an Appletalk bridge to a token ring ethernet adapter to a proprietary IBM Mainframe protocol. It is still the case with IPv4 and IPv6 acting as side-by-side "friends" working together for the common good of the internet.
The internet doesn't really care if you only want to run "one stack" instead of two if you are fine that an increasing amount of your traffic is going through the equivalents of an Appletalk bridge, who may start charging for it at some point (or are volunteers running it for fun and might get bored). (I think in this analogy the biggest one of those Appletalk bridges is Cloudflare? Even I can't tell if I'm joking or not. It does explain some things about CF's business model.) It will take decades for it to get to that, though.
Anecdotally, my home ISP grants me an IPv6 allotment and I've noticed quite a bit of traffic using it. It's kind of fascinating because my current Wifi router indeed has some sort of memory pressure issue with some combo of IPv4 BGP routes and NAT44 firewall states and just entirely falls apart routing IPv4 at some point when it has been running for long enough. My previous employer's IPv4-only VPN seemed to especially stress it for whatever reasons, during WFH life, and I'd have to restart the router somewhat regularly for it to start routing IPv4 correctly again. IPv6 traffic just worked even when the router was dying on IPv4 traffic. If I wasn't on my work laptop or trying to use a site like HN or GitHub, I could go sometimes hours to days before realizing IPv4 addressing was broken again. My "prosumer" perspective is IPv6 is the reliable stack I use most often (gaming, lots of daily browsing, key apps I rely on, even many of my consumer devices just quietly falling back to 464XLAT and "Teredo" tunnels and still reaching IPv4 stuff despite my local router falling apart) and IPv4 the increasingly weird and flaky stack. I only know I can point a finger at IPv4 because I'm just enough of a nerd to do small bits of debugging when it happens out of curiosity, but it is an interesting pattern, anecdotally.
Presumably the next several billion devices want to talk to the current ones. There will always be old devices left behind on old protocols, same as how old versions of SSL get rejected everywhere, and they can deal with it via compatibility layers like 4-to-6 NAT.
Upgrading the routers is a monumental task and handling the "transition" when some routers are upgraded with v4.1 and some are not is impossible. What happens during the transition when a v4.1 source tries to send data to a v4 destination? The v4 can't talk back. You can't fit 64 bits in a 32 bit address. This is the same problem as with v6.
Right, it only converts to v4 if both src and dst are 32-bit, which is fine in v4.1 too. Everyone can adopt v4.1 hardware/software without even thinking about it but hold off on using >32-bit addrs until they feel like enough peers are on v4.1. Yes it's only a one-way compatibility, but that's way better than v6 which is incompatible both ways, creating gridlock.
If you really want extra compatibility, idk if this is a good idea but it's an option... Go v4.1 using up to 40-bit addresses for now (but leave room for more). Translate a v4.1 TCP/IP packet with a 40-bit src and 32-bit dst to v4, truncating the last 8 bits of the src IP, provided the last 8 of the src port matches them. IPv4-only dst can respond fine. When that /32 v4.1 router receives the v4 response, set the last 8 bits of the dst IP to the last 8 of the dst port. So it's kinda like NAT except translating to a public /40 IPv4.1 instead of a private IPv4. Actual NAT on the /40 addrs gets the remaining 8 bits for the src port. And you just speak v4.1 without all this if the dst is >32 bits.
I think you underestimate the complexity of deploying a new protocol like that.
Also, you know NAT64 exists, right? You can have a v6 only network connecting to v4 hosts. Is that not enough compatibility if you don't want dual stack hosts?
I can't tell you the man-hours, but I can tell you it'd be easier than ipv6. And yes I'm aware that you can give a "v6 only network" a v4 address, which means you're still on ipv4.
- enough addresses for everyone on the planet, but we can't freely give out permanent static allocations to everyone because it would explode the routing tables
- so we never got our permanent roaming addresses we were promised
- NAT66 exists
- IPv6 was (still is?) a moving target for implementors
IPv6 to me is an example of "not letting a good crisis go to waste." The real problem was running out of addresses, but the solution got lots of less necessary changes bundled into it, rather than just adding more address space.
"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.
Yeah I don't get it. If you need to access IPv4 for legacy reasons then dual stack seems like the solution here. Yes it's a lot of overhead since you have to deal with an IPv4 and IPv6 routing table. AFAIK Windows has had both enabled by default for a long time.
This is actually a very good workaround/transition mechanism, because it lets you go fully IPv6 native, keeping the translation layer for things that absolutely must use IPv4.
And after transition is done, in theory, all you’d do would be turn off the translation box. In practice you’ll have to keep it up until the end of days, but that’s a separate matter.
An average user is not expected to do that. But I understand there are mobile operators out there who have been doing this (instead of NAT) for a while because they don't have IPv4 addresses for every consumer subscription? Wasn't T-Mobile US one of them? (Not living in the US.)
An average user shouldn't be able to find hardware not supporting IPv6, because it shouldn't be allowed to be sold. (And soon, hardware supporting IPv4.) Just like it happened with digital TV standards.
In home network single $70 USD device with 2 daemons running may be clearly too much but for corporate or even office network it's just one more box in addition to dozens of network devices.
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 don't think openssh upstream would accept a patch that makes ssh interpret ipv4 addresses as anything other than ipv4 addresses, and who wants to carry such a patch downstream forever?
Maintaining your own patchset for your personal use is usually not a good use of your time and expertise.
Every time someone runs a linter over upstream, you're going to have to remake that patch. Sure, it's only 20 mins... But that multiplied by every bit of software you patch and every release, and you quickly realise that a huge chunk of your life was wasted doing what is effectively busywork.
Instead, contribute your time and efforts back to upstream, and now your efforts can help millions of people not just one. If others do the same, you'll see far more improvements to the software you use than you alone could ever write and maintain.
I just don't think it's a good use of OP's time - effectively developing and maintaining software for 1 user.
One main benefit of software/computers/the internet is that work done by one person can benefit millions - thats what sets us apart from cavemen who had to do everything for themselves, and got a worse quality of life as a result.
This bogus assumption is the whole problem with the "upstream or nothing" attitude.
You're letting a single project -- and usually a single individual -- be the gatekeeper between you and the entire remainder of humanity. That is stupid.
And if you're happy to take on that work (and the associated risk) forever, go for it. For others, hacks like tnat64 work fine. They also work for lots of programs, where patching each one individually to somehow detect that it's behind NAT64 and behave differently is a lot of work!
This method could apply to other tools with the same IPv4/IPv6 behaviour, without further modification. Changing the behaviour in the utility directly would only fix it for that one utility meaning that to fix another you need to do the same work again. It is perhaps also safer than modifying such a core component as SSH: if you introduce a bug the trick can be easily disabled until fixed, if you accidentally break SSH you might cause yourself significantly more hassle.
> This sort of negates that advantage
LD_PRELOAD trickery doesn't negate the advantage of having full source access, patching SSH would also have been a perfectly valid option, but is perhaps a better tool for this particular job.
For another use of the trick see https://github.com/mariusae/trickle (the project looks stale, though that may be because it is properly done and there have been no security/other bugs to fix in recent history) which slips its own functions in the call chain to apply user controlled (rather than firewall/routing level) throughput shaping to utilities that don't offer it out of the box.
Isn't having the source available only the advantage it has over Windows? For most people the advantage is probably, as 'bcantrill once said, that they can Google their stacktraces.
Plenty of people aren’t that concerned about building stuff from source, even when they are running on Linux.
Often, proprietary third-party code doesn’t have source available at all.
Having an additional way to effect changes in behavior without recompiling an application hardly negates the benefit you described. They don't say the _cant_ or _couldn't_ change the source themselves either. And what you described is hardly the main advantage of Linux, FreeBSD enables that _much_ easier.
Try actually recompiling something nontrivial but open-source, and getting the exact binary you already have, the one which you know works but just needs the one modification you want.
You'll quickly discover that "open source" doesn't make everything easier.
This way works with any binary. Your idea of patching the source would have to be done to every single program that uses the network that you want to work like this. Really this should just be a part of the OS though.
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.
Did you try just dup2()'ing a new socket file descriptor over the old socket file descriptor? Probably it bring other kinds of problems, but would be interesting to hear what they are.
Yep. You lose sockopts (trivially restorable), async ownership (less trivially restorable, but with some kernel patches, it’s possible), and epoll registration (which omg, wtf.).
The other problem is that we found runtimes that would immediately send data after a non blocking connect (or receive data), and you needed a way to kick these off again. It was really a nightmare to restore all that state in a running socket.
The real solution was to add a new address family, and patch the kernel (as opposed to a module), that could dynamically switch back and forth (think AF_KCM). Unfortunately, I never got around to that.
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.
> What's the benefit of DHCPv6 over SLAAC (genuine question, never looked into DHCPv6 at all)
In corporate-y environments it allows for easier tracking of user-MAC-IP mappings for auditing purposes. If you use SLAAC there is no auto-logging as the client simply picks an address itself.
One way to do tracking with SLAAC could be to SNMP scrape/trap ipNetToPhysicalTable of RFC 4293. Another would be 802.1X or MAC authentication (interim) accounting via RADIUS (RFC 2866).
The DNS bit it's not true: there's RFC8106 [1] for this and it's widely supported. You can set a list of DNS servers to use (RDNSS) and a domain suffix for resolving unqualified hostnames (DNSSL), exactly as for DHCP.
I think SLAAC's /64 limit functions as a "trojan horse" forcing ISPs to give everyone at least 64 bits of address space. Most would allocate /112-/128 per customer if it were slightly easier.
Designing the internet with lots of unused space at the edges will probably be useful in 100 years.
Regardless of the /64 limit, I expect DHCPv6 will win out in the consumer side (with ISPs giving customers pre-configured wifi routers with DHCPv6 already configured). SLAAC is both very complicated, and its privacy extensions are anyway not something ISPs have been friendly to even if it weren't such an extra hassle.
> and its privacy extensions are anyway not something ISPs have been friendly to
That is an argument for forcing ISPs to support SLAAC, so it's difficult to bill a customer based on the number of devices in their home. ISP-friendly often means user-hostile.
If ISPs can deploy device-counting DHCPv6, then router manufacturers will respond with IPv6 NAT, and then the IPv6 landscape will be as shitty as IPv4.
Device counting has always been possible with IPv4 routers, and yet I don't know of a single ISP which does this.
To be clear, I'm talking of ISP-provided (usually wifi) routers, which at least in my country are extremely common. Those could receive an IPv6 prefix and do DHCPv6 inside your own network.
The concept of an IPv4 NAT router exists today because people in the '90s wanted to connect multiple devices without permission from their ISP. SLAAC lets you extend a network without permission using ND Proxy, whereas DHCPv6 IA_NA can only be extended using NAT.
So I think SLAAC is good because ND Proxy is less evil than NAT.
NDP doesn't impose any restrictions on IP addresses, it uses special prefixes anyway.
EUI-64 is a part of SLAAC, not NDP.
Finally, NDP is not really any more secure at least than ARP (at least not if you don't implement SEND as well, which I'm not sure if anyone does, at least in consumer networks). Not sure about reliability or scalability either.
Name and shame the ISP! And update your DHCPv6 Prefix Delegation request for a larger prefix (try /60, that seems to be a common supported PD size for most at home ISPs).
> I recently had to setup a non-encrypted website because I have a few old devices that can no longer do HTTPS.
That sounds like they haven't been updated for TLS>1.1 – if that is the case then rather than going all the way down the HTTP you could enable TLS1.1 (and maybe 1.0). It is open to POODLE/BEAST/others that way, but still have some protection and the site's configuration differs less from the rest of your infrastructure.
Unless the site is completely internal only of course, in which case just sticking with HTTP may be less faf.
No, that is the problem. They worked with less and less websites until there were none left. I needed to install some packages, which I could just put on my own server.
And I have an old Blackberry Bold that now show current electricity prices, so I know when to starte my washing machine. That can also run on own webserver.
Technically the certificate issues are separate from the protocol versioning. It's just that clients that don't support TLS 1.2 often also don't support sha2 certificates or may not have a path to validate certificates from currently available CAs (although you can usually push through that; no protocol support and no cert signature support is not a user bypass prompt)
As a side note, barely anything supports TLS 1.1 but not TLS 1.2
I feel the exact opposite. I've recently been experimenting with ipv6 only via NAT64/DNS64 and run into the same problem (with steam trying to connect out to hard-coded ipv4 addresses).
I started to look into CLAT and really didn't want to have to go through the hassle of a whole new virtual interface with routes etc, when one single app can't just pass a couple different args to connect().
I actually had thought about trying to write something exactly like this myself.
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.
There's virtually nothing on this, I guess nobody cares enough about IPv6 to spend time to actively remove IPv4 on their home. I did it, mostly for fun and because I hate managing a dual stack: I have been running a 100% IPv6-only network at home for a couple of years, now.
It works by having several IPv6-only subnets and a dual stack router (running openwrt) that performs stateful NAT64 [1] using Jool.
This allows to access both the IPv4 internet and local IPv4 islands[2] (basically old devices like printers).
There's no DHCP or NAPT involved: the router gets a /56 prefix from the ISP and performs prefix delegation, so every device does SLAAC and assigns itself a fully routable IPv6 address.
For DNS I use dnscrypt-proxy2: it's very easy to set up and it can do DNS64 and static hostnames mapping. Since prefix is stable, I just assign names to the stable EUI-64 addresses of the hosts I care about. Alternatively you can use bind for DNS64 and mDNS if you don't like manually assigning names. There's also a script to automatically assigns names based on ICMPv6 neighbours discovery [3].
I also host some services on the IPv4 internet from IPv6-only hosts: for this you need the NAT64 equivalent of port forwarding, which is setting up static BIB entries [4].
There's absolutely _no_ good reason to do that if you're only facing the internet with a single IP on your router as a NAT gateway, except to make your life hell. Only thing that may be worth doing is parting ways with the one internet-facing IPv4 and relying solely on IPv6 there, but that's mostly up to your ISP and their own infrastructure. Even if you were to 100% NAT your IPv4 LAN to IPv6 WAN, and your ISP still dedicated your router a public IPv4, it'd benefit no one.
Why wouldn't you be able to disable IPv4 in the router ?
Also, isn't trying to run both IPv4 and IPv6 inherently a security issue coming from the complexity of dealing with two overlapping networks with very different logic ?
It depends on your ISP, but providers are slowly switching to IPv6-only connections to their customers. The customer's router converts v4 to v6, and a translator at the ISP converts back to v4.
If you do the 4-to-6 translation on your own machine, your local router doesn't need to know about v4 at all. This is already happening with mobile networks.
I'm 100% the opposite. Define everything ipv4, turn off ipv6 and have one set of private ip addresses, one set of firewall rules and NAT at the firewall/router.
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.
Android has had support for IPv6 since at least 2014, and there are plenty of mobile networks which are IPv6-only and work just fine with Android phones doing CLAT.
The only thing missing is DHCPv6, and that's a deliberate decision - albeit a somewhat controversial one.
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.
IPv6 has been silently growing. If Hacker News supported IPv6, there is a good chance you would be accessing it with IPv6. The problem is that may have hit a plateau with the easy migrations. The issue is that there is no incentive for most businesses to make switch.
I was thinking that there should be movement that IPv6 is the new default protocol. That includes requesting IPv6 from sites. Also, lots of docs on how to enable IPv6 with routers, program to label gear as IPv6-ready, and persuading manufacturers to enable IPv6 by default.
Finally, have best practices for IPv6 on corporate networks. With NAT64, it is possible to have IPv6-only network with IPv4 on the edge. I think it needs docs that describe how to do it, and lots of work in changing opinions of network engineers.
All of the best practices seem to be in place in the consumer space. Several major consumer ISPs (mobile carriers) are IPv6-only and there hasn't been that much trouble. iOS requires IPv6 support in App Store certification because of this.
The trouble is definitely corporate networks. Changing opinions is hard, especially when network engineers have sunk cost fallacies and bad security training to worry about. Probably the only thing that's going to start making a difference for corporate networks is to let IPv4 costs continue to increase until enough corporate accountants start to notice that in financial reports and start to ask hard questions. Too bad there's no easy way to associate a market cost to 10.0.0.0/8 somehow.
Possibly never, because security. NAT at least tries to hide insecure IoT device on your grandma's wifi.
shodan.io has support for ipv6. With ipv4 you're somewhat restricted to devices that get public ip (corporate networks) or devices that drill a hole (uPnP/port forward). IPv6 devices are publicly visible by default and you need to manually setup firewall to filter this out (not trivial - especially for UDP and ICMP)
Every firewall I’ve dealt with since forever has default deny on inbound traffic, state full allow for outbound connections. Regardless of NAT or not, and regardless of how cheap it is.
Name one vendor? I can name you 3 that don't. Zyxel, Ubiquiti, Mikrotik. Also anything wrt based (eg. dd-wrt).
In fact one of the warnings on dd-wrt official IPv6 tutorial:
""" Keep in mind it can be dangerous to enable IPv6 without also having a firewall on each client that handles IPv6 packets, or having ip6tables on your router to filter incoming connections. ip6tables is NOT included by default with DD-WRT, which means your clients will be directly exposed to the Internet once you have enabled IPv6. """
Ubiquiti do -- and it's very nice to be able to punch holes in it when I do want to let HTTPS traffic in to specific addresses, rather than need to try to shoehorn everything onto a single IPv4 address.
IPv6 support is sufficiently widespread that pretty much the only place I can't access IPv6-only services from is the office :P.
This is my concern too. NAT is nice because it's stupid and secure by default. No matter how you misconfigure it, the router simply doesn't know where to forward inbound packets to, unlike a firewall which has to actively block. My assumption for routers is that they won't handle firewalls right, especially the many cheapo ones.
It's not actually secure; your router will route inbound packets to whatever IP is in the packet's destination header, and that can be a machine on your LAN. This remains true whether or not you're applying NAT to your outbound connections.
If anything, NAT makes you less secure by tricking you into a false sense of security.
(It's also worse if you're deliberately running servers, because it catastrophically reduces the search space needed for a hostile actor to find those servers via network scanning. At least, it does on v6 -- on v4 the search space is already too small to be a relevant factor.)
The routers. My ISP can't route dst=192.168.1.2 to anywhere, and even if someone managed to splice the packet in between my router and the ISP, my router won't take that dst. That address doesn't exist on the WAN.
Okay, but since that's RFC1918 you'll need to give me access to your immediate upstream network in order to send the packet to your router. How do you want to do that?
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.
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.)