IPv6 adoption is just the traffic shift from desktop to mobile. IPv6 kinda makes sense in mobile because it solves a problem of needing multiple addresses per person (phone, tablet, gaming device, etc) and the whole stack is maintained by two entities (the phone OS manufacturer and the carrier). It probably would have worked even better if it was far less complex and only solved the problem that was needed.
> IPv6 adoption is just the traffic shift from desktop to mobile.
There are entire ISPs (in the US) that are IPv6-only for CPE because IPv4 is unavailable and they have to use expensive CG-NAT boxes to deal with IPv4:
Residential broadband often has it too. The laggards are corporate networks and cloud where IT is ultra conservative and “if it’s not broke don’t fix it.”
The only thing that will make corporate environments change is if something they need starts requiring it, and not a second before.
Cloud is slowly getting it. Slowly. GitHub still doesn’t have it though, which makes pure v6 nodes annoying for a lot of use cases.
I work for a federal space where IPv6 native is a mandate. As someone who's working on k8s, we often have to build and patch everything ourselves to support that mandate. Want to pull a helm chart from a github repo? Gotta either dual stack the node or run a reverse proxy to make that happen.
I'd love to be at a point where everyone just dual stacked everything so that one day we can flip off the IPv4 switch.
I think major failure of Kubernetes was not being IPv6-only from the beginning. Its model of every pod having own address works much better with IPv6 where addresses are cheap. With IPv4, it needs complicated overlay networks. The cluster boundary would also make a good place for NAT64 proxy.
Kubernetes didn't get IPv6 support until later, and it sounds like it isn't reliable yet.
Corporate networks are not lagging for being ultra conservative; they lag, because the moment they start thinking about any change, their vendors start pushing all manners of products and licenses on them, that they insist are absolutely necessary for that change and it won't work without it. Sharks feel the blood in the water, and they want to make whatever is possible on it.
So in the end you are looking both at capex, increased opex and for what? You have ipv6? Congratulation, now you go to your C-level bosses and explain to them why it was worth it. Good luck.
Residential broadband has been getting v6 too. It saves money and provides added functionalityfor the same reasons as on mobile. And academic/research networks got there first long time ago. Corporate envirments seem the biggest holdout.
IPv6 only solves a problem if you don't understand the problem itself! Just because people have five devices doesn't mean they need 65,000 * 5 internet addresses ... there is an endpoint for every port and each device needs only a handful of ports if not only one! Each user can certainly get by with five ports on five shared ipv4 addresses.
As I said before IPv6 will never happen fully because it solves a non-problem very expensively - by assuming the whole world is 64-bit workstations!
That works fine for outbound connections but doesn't work for inbound connections. You can't have two devices listening for inbound connections on the same IP address.
I'm worried about the long tail. IPv6 won't actually be useful until more or less everything supports v6; as long as there are enough clients which don't support v6 servers need v4, and as long as there are enough servers which don't support v6 clients need v4. And until we can start disabling v4, v6 gives no advantage and only causes significant added complexity.
I'm worried that the time when we can start removing v4 and therefore see the actual advantage of v6 won't be here for at least a hundred years, optimistically.
> And until we can start disabling v4, v6 gives no advantage and only causes significant added complexity.
v6 advantages:
* If you're an ISP, you need more complex hardware for CGNAT-v4 if your traffic is huge. If you do support v6, netflix, youtube and majority of your traffic is already on v6, you can get by without upgrading your CGNAT Infra.
* I suspect v6 should have faster initial connection - time to first byte, because of no NAT. I assume NAT is implied in v4 because if you're an ISP say in India where you have 1.2B mobile devices, you cannot buy 1/4th of all IPv4 addresses.
* Because of more IP addresses you can run VMs with public v6 addresses. It's not common to have ISPs give multiple IPv4 to a single customer, but with v6 that's always the case.
* Until the transition is complete, I and everyone else is gonna have to use an ISP which provides a v4 address, whether they're end users or a server operators. Fair enough though that ISPs may have some incentive to making more people have v4+v6 (not that they seem to have realized...)
* I really don't think NAT could possibly make a noticeable difference in the time to first byte. My guess about what's "barely noticeable" would be a few hundred added milliseconds, my guess at what NAT would add would be a few milliseconds. Happy to be proven wrong though if there are any studies or experiments on the topic.
* I'm not sure what benefits there are to giving your VMs public v6 IPs when you still need to support incoming v4 connections.
For whatever reason (it's probably a mix of NAT, the extra routing needed for CGNAT, and other things) there is a measurable difference in time to first byte on v6. Apple measured it as 40%: https://www.zdnet.com/article/apple-tells-app-devs-to-use-ip...
(Also, doing things like loading a webpage requires many round trips, so even a small RTT difference multiplies to a bigger delay for total load time.)
You don't need to remove v4 to get benefits from v6. For example, you can handle inbound v4 on your load balancers to avoid needing to mess around with it on your entire VM fleet.
I did a small experiment with 2 websites: federalreserve.gov and one of the Google's server located in Delhi. I'm in India in a city around 250 kms from Delhi on ISP: Reliance Jio Fiber.
I see around 8ms benefit when using IPv6 for Google, and 20 ms when using federalreserve.gov
Hardly noticable
I think you’ll find the real transition to be a lot quicker than that. All it takes is one of the big companies drawing a line in the sand because they’re unable to buy enough IP addresses, so they finally take a stand. Just like when YouTube nailed the lid into the coffin of ie6.
I doubt a big company would draw the line in the sand. But I could see an upstart (think TikTok) not having up enough IP addresses and just giving a crappy, slow proxied experience over IPv4, but having it be native, zippy and good over IPv6. Suddenly you have teens begging their parents to switch ISPs.
That comes with a major assumption that switching ISPs is an option. Most people get to choose between their cable company, or a fleet of ill-trained pigeons
As an example, the options where I am right now (thankfully temporary) are:
- $55/mo. 3 Mbps DSL
- $80/mo. 300 Mbps cable (or even more expensive, faster cable)
- $120/mo. 100+ Mbps (if you're lucky) Starlink
- A few other heavily restricted, very expensive satellite options (e.g. HughesNet), to which the aforementioned fleet of ill-trained carrier pigeons might be preferable
Only one of those is practical and (mostly) reliable for anything remotely approaching something like remote work.
Back home it's such a luxury to be able to choose DSL, cable, or fiber. I can only dream that all markets will have an actual choice between Internet service providers someday.
Many of the "choices" are false choices. My home, in the downtown of a major city, shows as having two choices for wired broadband, but the phone company's wired broadband option is an old ISDN network grandfathered in to "broadband" that probably shouldn't have been, it is the very bare minimum of "broadband" in 1990s standards. (And the phone company charges the same monthly cost for it as actual high speed broadband options they provide, just to add additional cruelty.)
I have a choice between the cable company and sorta Starlink (Starlink isn't actually available in my area yet, and is a nonstarter anyway). There are no other options available to me.
I think you'll be surprised. As soon as most large and medium businesses support IPv6 we'll start to see people dropping v4, likely within the next 5-10 years. When only a tiny % of your potential customer base is dependent on v4 you start to weight the cost of staying dual stack or just going pure v6
I find partial IPv6 support quite useful. For example, at home I have a lot of services where it it convenient if I can access them but it is not essential. I give those services IPv6 addresses. I have IPv6 at home, at work, on mobile. So it is not a big deal if I can't access them from some part of the world. With increasing prices of IPv4 addresses, I expect that more internal services will move to IPv6.
For services at home, where I do need IPv4 support, access over IPv6 is simpler and more robust. We can expect more of that in the future. Increasing prices of IPv4 addresses, certainly if for routing purposes you need a /24, may result in worse traffic engineering for IPv4.
Certainly, it is at least a start that all the cloud providers are slowly raising the hourly costs for v4 addresses to better reflect scarcity and other externalities. Those costs rise high enough it will be a pressure on corporate bottom lines (and then in turn IaaS tools and many other SaaS providers).
And yet Azure has comically bad IPv6 support, so you can't even move (partially) away from IPv4 even if you wanted to. Besides, the cost of a v4 address is peanuts compared to the other cloud costs.
All of the big three (AWS, Azure, GCP) have comically bad IPv6 support and comically bad security advice on IPv6 and private networking in their documentation.
Kubernetes is comically bad at IPv6. Docker is comically bad at IPv6.
GitHub is comically bad at IPv6.
Like I said, pricing IPv4 at all, is at least a start, a baby step in the right direction. Even if it is a drop in the bucket compared to the rest of the cloud invoice, it is still at least a line item that corporate accountants are going to notice. It is now an obvious cost to cut. Maybe that will put pressure on fixing how comically bad the above offenders (and more) are actually supporting IPv6, because corporate accountants may start asking hard questions.
We could, but it would have broken compatibility with v4 just as thoroughly as v6 did and so would have had the exact same deployment difficulties v6 has.
In fact v6 mostly _is_ a minor tweak to v4; most parts of it are lifted directly from v4 but with a longer address.
The larger address space is only an advantage if we don't need a v4 address. The situation "I need a v4 address" is not worse than the situation "I need a v4 address and a v6 address".
Not exactly. There's some pretty snazzy interoperability tech out their. (I.e. 4-6-4 XLAT) that let's clients get v4 addresses when they need them, which means if there's a big chuck on devices on both ends that support v6 you don't need as many v4 address.
This kinda a problem for motivating people to move to v6 because as implementations of v6 grow there's going to be less and less pressure on the v4 address space.
That's not quite true. Even after corporate users have switched the government will still be on V4. The US military is drowning in IPv4 addresses and feels little pressure to switch.
Azure AD only got IPv6 support this year. Most corporate networks have not switched, whole most federal agencies have implemented IPv6(due to mandates), mobile carriers are heavily utilizing IPv6 and so are residential ISPs (Comcast and Time Warner have been deploying IPv6 since 2011)
Federal agencies turned on the Cloudflare flag that auto-translates incoming IPv6 packets to the IPv4 that they support for front facing websites. That checked the box and little progress has been made since then.
People like to complain a lot about the new features in v6, but they don't make it any worse as a v4 replacement.