Single-purpose accounts aren't allowed on HN (they're too predictable and predictability is the antithesis of curiosity) - so I've banned this account. If you don't want it to be banned, you're welcome to email hn@ycombinator.com and we can figure something out.
> I could see doing IPv6+IPv4 in a corporation and terminate everything on load balancers, allowing anything behind the LB to be any combination of IPv4/IPv6. But IPv6 only? I don't see any big companies doing that in my lifetime.
facebook started migrating to ipv6-only datacenters in 2014 or so. i think all of them are converted at this point. they only support legacy ip at their network edge, & use siit (iirc) to facilitate access.
The legacy IP at their edge is what I meant by terminating IPv4+IPv6 at the load balancers.
The tricky part is that almost all datacenters today need to talk out to other datacenters. Not all of them use IPv6 which means they will still need some way to speak IPv4 until all their 3rd party data processors are also doing IPv6 and for Facebook I happen to know that is a lot of 3rd parties. If they are truly IPv6-only in the datacenter then they would have to forward-proxy all outbound connections through something with an IPv4 address on the edge as well and that can not go away until all their partners and vendors are also purely IPv6.
You can do that with NAT64, which you can run as a service in your datacenter rather than needing to deal with v4 throughout it. (In fact it doesn't have to be run in your datacenter -- it could be outsourced to somebody else, which will probably make sense eventually as v4 use dwindles.)
> Part of the motivation for this was to use (mostly) unique MAC addresses (48 bits) as your identifier and that fits in 64 bits. Of course this became a massive PII leak and a tracker's dream so it never happened but we're still stuck with /64 blocks that we absoultely do not need.
please read about rfc4941 privacy extensions & how prevalent their use is before continuing to regurgitate decade-old, outdated privacy alarmism about MaC aDdReSsEs.
> I don't see any "dash" to support v6 in our future, when the option to just keep working around issues with v4 is so much easier and cheaper in the moment.
30-40% global adoption in ~10 years may or may not be a "dash", but it's also not nothing.
"easier and cheaper" is very much not the case at larger scale. legacy ip space is only growing more expensive, & cgnat platforms are not cheap. even if a carrier HAS TO deploy cgnat, deploying ipv6 first means you don't need to buy cgnat capacity for any v6-native traffic (which is a non trivial volume)
> Really, what does anyone have to gain by switching to v6?
the above, & also a future-proofed, infinitely scalable network. any org's that do alot of m&a don't have to play as many stupid rfc1918 integration games.
if you don't deal w/ scale, yea, hard to see the benefits. fair.
> 30-40% global adoption in ~10 years may or may not be a "dash", but it's also not nothing.
Still nowhere close to being remotely unusable after soon 30 years is very very close to nothing.
Regarding benefits: Amazon, Azure and all the other major VPS companies has a lot to gain from IP addresses being expensive, since it makes it almost impossible for new players to enter the market. ISPs may pay for CGNAT in terms of infrastructure and complexity, but they save in support and abuse mitigation cost by making it impossible for normal people to host their own stuff, they save in support cost by not dealing with customers' broken products which get confused by IPv6, and they gain financially from charging a ton for "pro"/"enterprise" non-CGNAT connections.
And for any kind of web service, supporting IPv6 is obviously just a net negative, since you have to deal with both v4 and v6 rather than just v4.
So I suppose I'm saying, sure, there are minor things to gain from v6, but it's not clear that they outweigh the (opportunity) cost of v6 for anyone, and for large sectors it's simply a cost with no upside.
I don't see a rush to support v6... ever. We'll keep growing steadily but slowly for a while, then adoption will taper off.
But hey, I may be wrong! I'd certainly be happy if you were right. The minuscule amount of progress across almost 30 years doesn't instill confidence though.
What I think (or at least hope) that this post is missing, is the ever-growing opportunity cost of having a population of people that are flat out unable to access your service. Google's IPv6 page currently has almost all of Africa at near-0% v6 adoption, but this map https://data.worldbank.org/indicator/IT.NET.USER.ZS?view=map shows a lot of African countries that still have low internet access. With such a long way to go towards full access, and in a lot of countries, exponentially rising populations, could a lot of African ISPs give up on the cost and/or CGNAT complexity of trying to magic up so many new IPv4 connections, and go all in on v6? That's only my layman speculation though.
Neat, very different results. But still looking at it from the wrong direction?
That is, ipv6 for clients. But I'm more interested in servers, because that is what would affect me if I don't have IPv4. Such as the experiences described by OP in this thread.
ipv6-only web sites are borderline nonexistant, because no one who needs to maintain a profit dares to cut off a revenue stream from legacy ip only users (yet).
Ugh, Centurylink. Their networks, both DSL and Fiber, support IPv6 but you need to go into the router config and explicitly enable it which is why they show up as 0.5% IPv6 supported in that first link despite every other top-10 US ISP having at least 50%. I've enabled v6 on my home connections with them on both DSL and fiber and I've had absolutely no problems with it. I wish they would enable it by default with their consumer network equipment.
but there are waitlists to fulfill, so...you're probably still right.
(tl;dr: "repatriate the poorly allocated legacy ip space" is a losing proposition)