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.
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 problem areas are with hosting and corporate networks. The Google numbers are smaller during the week as people use IPv4-only corporate networks.
Still, for a company like discord, not even using host names to allow DNS64 is really sad.
128 is no different to 33 bits, or 32 bits plus extension header in that regard.
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.
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.
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.
Another would be that government customers need to have IPv6-enabled sites. This could get a lot of companies to add IPv6 hosting.
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.
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.
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).
Swap in v4.1-compatible stuff and you'd be done. Sending to short address uses v4, sending to long uses v4.1.
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.
> 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.
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.
This is unlike v6, which cannot address anything inside the v4 space. v6 and v4 are totally separate planes.
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.
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?
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.
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.
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.