If any "new" computer technology has been around even half as long as IPv6 ( https://en.wikipedia.org/wiki/IPv6_deployment#Major_mileston... ), with even a tenth of the "you gotta start using this!" push from the Big Boys - and yet still is very widely avoided/resisted, and the older-tech alternative commands a price premium due to widespread demand...gosh, that "new" technology must absolutely suck, eh?
The things that IPv6 would enable (direct end-to-end connectivity) is now seen as a negative by the industry that has since pivoted on rent-seeking, walled gardens and restricting user's potential. The industry is now even legally making money on many things that would've been considered outright malware just a decade ago.
People being able to host things themselves, or local-first apps that communicate directly without the need for any middlemen is a negative for the industry. The industry wants there to be a technical need for a middleman, so they can provide that and seek rent over it.
There is no user-level demand for IPv6 because the industry is no longer making any apps/devices/services that would take advantage of end-to-end connectivity (even if it was available now - let's say in a hypothetical world where IPv6 adoption is 100%) since it's more profitable not to, so as a result there is no pressure on ISPs to offer it.
I suspect that if IPv6 limited itself to just increasing the size of IP addresses, IPv4 would largely be a distant memory by now.
Nah, the problem is ipv6 has been designed by a commitee for a lot of enterprise-ish features so the hobbyists have taken a look and postponed setting it up internally for when they have absolutely no choice.
I've asked for simple ipv6 tutorials in discussions on HN and elsewhere and whatever I got pointed at was always longer than the article we're discussing and incomplete.
Basic set up of ipv4 for a home network can be explained over just one pint. Looks like you need two barrells for ipv6.
Sounds a bit over the top. Can you name some examples?
Consumer routers still suck regarding IPv6. Last time I tried setting up IPv6 on my wan I got a /128 which is utterly incompetent.
No service wants to cut off access to the ipv4 customers so they've made things just work. We have only recently hit address exhaustion (relative to IPv6 age).
No one wants to jump first and there is no government mandate for support.
I don't know who you think the big boys are, but it's not like Google or Meta have throttled ipv4 services or put banners on their site warning users they are on a legacy protocol.
The important part is the delegated prefix, which you normally get via DHCPv6-PD and should be at least a /56.
I recall reading about Facebook's internal IPv6 migration for their data centers and the problems they ran into. The two that stuck out the most to me and which I still remember details for are:
1. The PHP function developers used to convert an IPv4 address into an integer to store into a database or something. It didn't work in IPv6, meaning the code broke badly when it was considering an IPv6 host. They kept asking developers to stop using it, but new code kept getting added which used it. Eventually the decision was made that 'we've warned you enough, so from now on we're just going to go ahead and let your code break'.
2. Their networking hardware wasn't extensively tested for an IPv6 single-stack deployment. Turns out that when presented with a BGP advertisement that contained only IPv6 routes and no IPv4 routes, their switches would immediately crash. How did they discover this? By sending out a BGP advertisement that contained only IPv6 routes and no IPv4 routes, crashing every rack switch in the data center. There's no reason why this should happen; it's not a violation of the BGP spec or anything, it's just a bug for a case that no one tested on the vendor's end because none of their customers tried to do that.
So it's not that IPv6 sucks; it's actually pretty great in a lot of ways. The problem is that everything else sucks; people don't bother to support things, they don't consider it in their code, they don't test for it, they don't bother to roll out support because no one else has done so either so why bother, and so on.
In the end, IPv6 is 'avoided' because of the problems that Facebook ran into, or that OP ran into, and is 'resisted' because it's extra work that they could put into doing other things with their limited time and engineering work.
To be clear, dual-stack deployments work great; my ISP recently did a trial of a dual-stack deployment which I was lucky enough to participate in, and it was almost completely transparent. My Unifi gateway picked up the address and handed addresses out to clients internally, clients used IPv6 where appropriate and fell back to IPv4 when necessary, and everything worked completely transparently.
TL;DR IPv6 isn't the problem, the industry is the problem.
OTOH - for people making real-world decisions, the difference between "$Networking_Technology sucks" and "~all available implementations of $Networking_Technology suck" is pretty meaningless.
If it is built to last a 1000 years or more, ~25% of internet traffic by the end of the first 30 years isn't a terrible rollout curve. That's 0.3% of its expected lifetime. (Assuming the 1000 years clock started 30 years ago. It's even believable the 1000 years clock starts closer to 90% rollout of IPv6 than to IPv6 announcements 30 years ago. IPv4 address scarcity wasn't truly felt until decades into IPv4 usage, though it was an academic concern.)
Many Internet projects have always run on different timescales compared to the vastly faster timescales people associate with software and even hardware generations. (In part because these rollouts happen across software and hardware generations.) The IP protocol is so deeply fundamental to that, it is somewhat "civilization defining". It would probably be a lot scarier if an upgrade to something fundamental like IP was an "overnight success". Civilizations are built on the timescales of decades and lifetimes. It should not be a surprise that IPv6 rollout has happened on such timescales. We mostly can only hope that the IPv6 architects were as smart as they hoped they were in preparing for the deep, unknown future of the internet, because they knew they were working on a civilation-timescale tool. (Which is exactly why IPv6 is not just "IPv4 with bigger addresses".)
I don't think that measuring the rollout curve relative to the expected lifetime of the thing is reasonable (or at least, useful), though. In terms of something like this, measuring it relative to when IPv4 is simply no longer feasible is better. And that time is very, very near.
Like, I said this elsewhere, Cloudflare public DNS is 1.1.1.1. If I switch to ipv6, I get to use 2606:4700:4700::1111. You telling me that's an upgrade?
Also, any change to the protocol was going to be a massive shift regarding network hardware. It wasn't ever possible to slap a few more bytes onto the address.
If you're going to make a monumentap shift, why not do it right?
yes, that was the argument from the very beginning, and it's not without merit. I disagree with it, because it's making a monumental shift into one that is even more monumental and increases resistance to making the change at all.
But who knows? Both sides of this argument are just speculating.
There have been other huge migrations pulled off in networking. HTTP->HTTPS is the first that comes to mind. Extra layer of security, no other changes. Browsers slowly made users more and more wary of unsecured sites, and it became easier for site admins to obtain SSL certs. Once plain HTTP was finally made uncommon, versions of SSL/TLS still got upgraded slowly. They also avoided making it too flexible and turning into a fragmented mess like email or XMPP, i.e. browsers strongly avoid self-signed certs and started banning old versions.
The concept of vanity IPv4 addresses was invented in 2009, when Google acquired 8.8.8.0/24 from Level3. This is an emergent feature of a small, densely packed address space. IPv6 had existed for a decade (EDIT: not two decades) by that point, so you can't really blame the designers.
Sprint controls 2600::, probably by accident, but they're not doing anything interesting with it.
Maybe the bigger issue was trying to get rid of NAT. People don't want every local network device to have a public IP and have to trust that the router's v6 firewall will do its job.
I understand that he's building a usable service and just trying to git 'er done, but it's a lot of hacks, so I'm glad they're documented in this here blogpost.
I hope that he can continually probe the edges to find out when real IPv6 support becomes available, and can gradually remove the hacks for a purer experience.
I.e. it allows you to push IPv4 to your internet edge only in a way that doesn't downgrade anything about actual IPv6 capable connections. For a single server that probably does seem pretty silly but once you have multiple it can make more sense.
What I want it for is so that I can have services exposed through my domain name, but operated on different internal servers.
I feel like excluding IPv4 folks is a large reason why IPv6 continues to fail. I feel like this is a pretty good compromise between pushing IPv6 and not being an IPv6 hermit in the IPv6 desert.
This could be done on the ISP/enterprise level, but it is more counterproductive to tell IPv6 adopters and promoters that we need to bend over backwards and hack in NAT and purchase/rent/lease public IPv4 addresses, when this is not our problem anymore.
I feel like the more juicy services that are IPv6-accessible-only, the more it will drive consumer demand, and will light a fire under people who are responsible to update the support and ensure that IPv6 works, even when IPv4 doesn't.
My hope is folks know of workarounds and I’ll do them and update the post.
This is the major flaw. Sites can't go ipv6-only. In reality we will have parallel ipv4/6 networks in place until the wheels fall off
