People like to complain a lot about the new features in v6, but they don't make it any worse as a v4 replacement.
People like to complain a lot about the new features in v6, but they don't make it any worse as a v4 replacement.
https://web.archive.org/web/20210122043401/https://blogs.aka...
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'd love to be at a point where everyone just dual stacked everything so that one day we can flip off the IPv4 switch.
Kubernetes didn't get IPv6 support until later, and it sounds like it isn't reliable yet.
Heh. Kubernetes as a whole was a failed project at Google that got open sourced.
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.
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:
* https://community.roku.com/t5/Features-settings-updates/It-s...
*https://news.ycombinator.com/item?id=35047624
Meanwhile India was 80% IPv6 as of a few months ago:
* https://news.ycombinator.com/item?id=32798003
The fact that the US and EU just happened to get a bunch of addresses first doesn't mean the rest of the world has the same options available.
More addresses are needed if everyone on the planet is to be able to connect.
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!
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.
- $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.
That was the work of a few people on the YouTube team, not the company itself taking a stand:
(Which we could have had with a minor tweak of IPv4 instead.)
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.
In fact v6 mostly _is_ a minor tweak to v4; most parts of it are lifted directly from v4 but with a longer address.
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.
* 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.
(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.
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.
End user facing apps also use it in gradual way when available, eg with WebRTC it lowers service ops costs and gives better latency.
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.
Corporate networks were the last to drop XP, the last to drop IE, and will be the last to adopt IPv6.