[marginalx]

Is most of that due to mobile?

The real migration challenges are in the server side/consumer home internet space which I'm not sure if there are clear stats around the adoption there.

I think IPV6 is a great example of over engineering, trying to do too much in one iteration. In an ideal scenario this could work, but in the context of large scale change with no single responsible party, it usually doesn't work well.

[zokier]

CloudFlare Radar has stats for desktop (34%) vs mobile (46%) adoption: https://radar.cloudflare.com/explorer?dataSet=http&groupBy=i...

[kalleboo]

On the server side, everyone is moving behind CDNs that support IPv6 by default.

On the consumer home internet side, consumer ISPs are slowly one by one lighting up IPv6, and it just works since consumer routers are mostly auto-configure (often literally controlled by the ISP). Mobile is largely IPv6 already.

The biggest challenge is in corporate/academic/medium-size business networks where they have lots of obscure subnets and firewall rules and old software and hardware running a critical task under a dusty table somewhere.

[azernik]

The problem has nothing to do with over engineering, or really anything to do with the actual contents of the IPv6 standard. It is just devilishly hard to make any backwards-incompatible change to layer 3, and address expansion is always going to be backwards incompatible.

[mrjoe3332]

There were some choices of v6 that made it extra hard, like declaring all v4 addresses no longer valid in v6, or making slaac default

[azernik]

IPv4 addresses are in fact a subspace of IPv6 (that's NAT64). They were not by fiat declared invalid. The actual thing I think you're complaining about - the necessity for NAT64 at all - is unavoidable, because you need a NAT/protocol-translation layer for packets to actually move between the new address space and the old one.

SLAAC-by-default is not, in my experience implementing IT automation, an actual barrier for adopters. You have a router sending out RS instead of a DHCP server, to an admin this is not a meaningful change.

[mrjoe3332]

NAT64 is a temp bolt on and also not the same thing. If I own 1.1.1.1 in v4, that doesn't mean I own some equivalent of 1.1.1.1 in v6. They had router nat64 and relay nat64, both with dealbreaker problems.

You don't exactly need a translation layer. If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual. Then after v4 is abandoned enough, I can sell 1.1.1.1.2:: to someone or use it instead of NAT.

SLAAC is a good design as a non-default that people who know what they're doing could enable, but a lot of people don't even want public v6 addrs for hosts, they just want NAT/DHCP.

[azernik]

> You don't exactly need a translation layer. If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual.

Think about this on a concrete, packet by packet level - I, from a v6 network, with a 128-bit address that cannot be represented by IPv4, decide to open a connection to 1.1.1.1. 1.1.1.1 doesn't have v6 set up, and so can't read my v6 packet and craft a response packet, because its address is invalid in v4. We need a gateway in the middle that will translate the packets from one format to another and perform the NAT function from one address space to another. This is an irreducible complexity.

> a lot of people don't even want public v6 addrs for hosts, they just want NAT/DHCP.

People don't care about whether their address is public or not, they want connectivity. SLAAC gives that to them; it is you that are insisting on adding complexity for the sake of having a non-routable address. As a user, I enable IPv6 on my router and go on my merry way; as an ISP, I assign my customer's router a /60 or /56 via DHCPv6 instead of a /24 and go on my merry way. Running an IPv6 address allocation system is a an easy, solved problem and has been for decades.

The hard problem is dual-stacking, and there is no way around that.

[Dagger2]

I mean, you own 2002:101:101::/48. You also own ::1.1.1.1, ::ffff:1.1.1.1 and 64:ff9b::1.1.1.1.

> If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual

That's not really how routes work. Or DNS.

I think you're mainly arguing we should import v4's allocations into v6, but about the only benefit is that people don't have to bother requesting new allocations. It doesn't help with any other aspect of the transition, and there are good reasons to avoid doing it -- the v4 address space is highly fragmented and also very unfairly allocated.

Plus we have plenty of people saying we should take back v4 allocations from companies that own them. That's not possible, but _not_ giving owners of v4 /8s an entire 1/256th of the v6 address space certainly is.

[jollyllama]

I was wondering how much is "last mile" between end-user devices and the next hop vs. within cloud networks, but the bit about mobile is a good point.

[mrjoe3332]

It'd be annoying even in the scenario where it got quickly adopted. Complicated spec, user-unfriendly addresses, unclear defaults.

[marginalx]

Precisely the reasons for lack of adoption I would say.