"It's not being used", except for nearly half of Google's traffic: https://www.google.com/intl/en/ipv6/statistics.html

Disconnect your phone from Wi-Fi and visit https://ifconfig.co/ . If you're a Verizon customer, it's probably going to show you an IPv6 address. It's huge, right now, today.

"Depended on" is what I should have said. An ISP or website can be v4-only or support both, but it's not going to be v6-only.

Fair. I bet that'll change soon though. My prediction is that it'll be a mobile-first game, like the next Pokemon Go sort of thing, that'll be IPv6-only.

I agree it would probably be something mobile-first that does it, since those carriers all(?) support v6.

Plenty of mobile users use wifi at home/work. Telling them to disable their ipv4-only wifi just to play your game is going to be a non-starter, especially when the cost of ipv4 address adds negligible cost to infrastructure. Is your CTO really going to massively increase user friction ("turn of your wifi to play!") just so try to save a few cents (comparatively speaking) on infra?

It could be in a country where people don't have home wifi.

Like africa which does not have a shortage of V4 address and there is effectively no v6 rollout?

this isn't true. I know because at some point XFinity started dropping ipv6 connections for me and I noticed because a number of sites (forget which) were broken

What do you mean by dropping ipv6 connections, like dropping ipv6 packets? That's only an issue if you're using v6. I disabled ipv6 on my router years ago and have never had a problem just using v4.

I ran an ipv6-only website because that's the only way I can have a publicly routeable address at home. Just as an anecdote.

There is not a single widely used service on the Internet that depends on IPv6 exclusively.

I had to check if HackerNews even supports ipv6, apparently it only recently started: https://news.ycombinator.com/item?id=39099065

> "It's not being used", except for nearly half of Google's traffic:

One of the world's largest ISPs, Vodafone, is yet to support IPv6.

What Google supports is irrelevant if your ISP can't handle the traffic.

True, but irrelevant to my point. Whether a particular ISP supports doesn’t matter: it is being widely used by the rest of the world, to the point that it’s half of Google’s traffic.

> True, but irrelevant to my point.

Vodafone's network is reported to handle around 20% of the world's traffic. It's not a random ISP. It's network does not support IPv6. It is how a big chunk of all internet users experience the internet. Claiming it doesn't matter in a discussion over IPv6 adoption rate is ludicrous.

And it would have failed for exactly the same reasons, because just changing the address field size is enough to have everyone who uses BSD Sockets to rewrite all parts of code that create sockets.

Especially since getaddrinfo was ported over from more streams/OSI oriented stacks pretty late, precisely because BSD Sockets required separate path for every protocol.

On hw side, by mid-1990s even changing one routing-important field would mean possibly a new generation of ASICs needed with more capabilities.

Essentially, once you agree to break one field, the costs are so big why not try fixing other parts? Especially given that IETF has rejected an already implemented solution of just going with OSI for layer 3.

All that code using BSD sockets is rewritten by now to support v6, right? If so, that can't be the reason.

And btw, what I suggested would actually work without userspace code changes until you want to start subdividing the /32s. Cause v4 addresses would've still been valid in v6.

Where would you store the other 96 bits. In the body?

Ipv6 packet format was needed either way, but only with the 32-bit address space at first (the other 92 bits set to 0). You simply tell your system to start using v6 instead, and everything else stays the same. No dual-stack.

Next step would be upgrading all those parts like DNS, DHCP, etc to accept the 128-bit addrs, which again can be done in isolation. Then finally, ISPs or home routers can start handing out longer addresses like 1.1.1.1.2.

There are two ways for me to interpret "simply tell your system to start using v6".

If it means upgrading every program, then your plan works but it's the same as how things work today. You're telling people to do a thing, and they aren't bothering. The "simple" step isn't simple at all.

If it doesn't mean upgrading every program, then your rollout fails on the last step. You start handing out longer addresses and legacy programs can't access them.

It's the second one. But legacy programs did get upgraded, so I don't see why they wouldn't under this other plan. If anything, it's easier because you're only making the address field bigger and it's not a separate case. Some routers struggled with 128-bit addrs due to memory, and could've gotten away with like 48 or 64 bits if they're using DHCP.

Lots of legacy programs, and current programs, and other things that could have been upgraded did not get upgraded. Getting to the situation where you can just flick a switch is not a realistic dream. There's not enough motivation for the average business to add support for a version that isn't in use yet.

> Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages.

Exactly. I would love to have seen the world in which that happened, and where all the other parts of IPv6 were independently proposed (and likely many of them rejected as unwanted).

The main problem wasn't all the smaller features but one big one in particular that can't be split into smaller pieces, the new addressing scheme. They wanted to replace all the existing addresses, which meant replacing all the routes. Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack.

> Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack.

Sure, "make the addresses bigger" would have required providing DHCPv6, DNS AAAA records, and various other protocol updates for protocols that embedded IP addresses. And making changes to the protocol header at the same time (e.g. removing the redundant checksum) were also a good idea.

It didn't require pushing SLAAC instead of DHCP.

It didn't require recommending (though fortunately not requiring) IPsec for all IPv6 stacks.

It didn't require changing the address syntax to use colons, causing pain for all protocols that used `IP:port` or similar.

It didn't require mandating link-local addresses for every interface.

It didn't require adding a mandatory address-collision-detection mechanism.

And I'm sure I'm forgetting a few.

Yeah. I didn't like any of those proposed changes, especially the colons. You also didn't mention how NAT6 isn't a thing by default.

It didn't require removing ARP and inventing Neighbor Discovery that embeds the hardware addresses into the IP address.

It didn't require the Ruby Goldberg "on link" network mechanism.

It didn't require multicast instead of broadcasts for local network discovery.

It didn't require using DNS config (of all things) to specify V4/V6 priority.

It didn't require adding a "flow label" that is nobody to this day knows how to use properly.

The list of fails is ridiculous.