They need to come up with an ip solution that is useful enough that people actually want to upgrade to it.
When you compare it to other technologies like https, tls1.3, unicode, 5g cellular, wifi 6, wifi 5 or bluetooth versions, etc. It’s clear that ipv6 adoption is not what it should be if they launched a protocol with clearer benefits to the end user.
> It’s clear that ipv6 adoption is not what it should be if they launched a protocol with clearer benefits to the end user.
The "end user" has no idea about TLS 1.3 or many other things. It's the techies that work behind the scenes that make the changes 'on behalf' of everyone else.
And IPv6 traffic is, according to Google, the majority of traffic it sees in many countries (including the US at >52%):
The 'real' holdouts are enterprise companies and corporate networks as evidenced by the fact that IPv6 usage goes up on weekends (i.e., when most people aren't at work on said corporate networks). See also:
> Chances are if you use the Internet on your smartphone, you are connecting via IPv6. According to the Internet Society’s 2018 State of IPv6 Deployment,[1] 80% of smartphones in the US on the major cellular network operators use IPv6 and major mobile networks are driving IPv6 adoption with Verizon Wireless at 84%, Sprint at 70%, T-Mobile USA at 93%, and AT&T Wireless at 57%. Plus, some mobile networks are taking the step to run IPv6-only to simplify network operations and reduce costs.
Being able to connect your smartphone to the Internet seems like a clear benefit to the end user IMHO. Would hate to see what every mobile phone being behind CG-NAT would be like.
I think smartphones are a special case, because they generally cannot run public facing services that open up ports and are specifically designed to be hardened for ipv6 and designed to work in conjunction with the carrier's ipv6 firewall/network.
Compare that to a home network where, printers are shared, iot devices have open ports, computers and nas share drives. IPv6 may address the needs of cellular carriers and devices, but it doesn't adequately address the needs of small local networks connecting to the internet.
> I think smartphones are a special case, because they generally cannot run public facing services that open up ports […]
Except for peer-to-peer applications, like Skype used to be originally: clients (tried to) talked directly to each other. IMHO it'd be great if we could have app(lication)s that worked like that again: less centralization.
> Compare that to a home network where, printers are shared, iot devices have open ports, computers and nas share drives.
Off the top of my head: your CPE/home router has an internal CA; you tell a local app(lication) to 'connect to' the CA and get a certificate (ACME, SCEP, etc); your home IoTs/NAS/etc also connect to the CA and get certificates; so all your personal devices have a root of trust. You 'bookmark' the IPv6 address of your printer/NAS/whatever. When you are away from home you want to connect to (e.g.) NAS, so you tell your smartphone to connect to it, and it knows the IPv6 address, but how can the CPE or NAS know that this random IP that is trying to connect is trusted?
Well, it uses IPsec negotiation and sends the X.509 certificate, and the other end of the tunnel (NAS) sees that the cert is trusted, and so allows the tunnel to be connected. If a connection attempt is made with an untrusted certificate the negotiation fails.
Of course if you don't want your NAS to allow external connections you don't enable the feature (default: off), and so it never punches a hole (PCP, UPnP IGD). And given a IPv6 subnet is /64 (the equivalent of four billion IPv4 Internets), good luck trying to scan that address space (and it is generally recommended to give residential users a /56).
As it stands now, you have to have third party tunnels (Wiregaurd, Tailscale, etc) and 'extra' protocols on top of IP (often dynamic DNS as well) to do the above, whereas with IPv6 universal connectivity can become part of the 'base network' architecture.
All that I’m saying is that the marketplace is not convinced that IPv6 works better for a local network than IPv4 with NAT and DHCP.
It’s more secure and more private for users that aren’t security or network engineers.
My prosumer $1,000 networking setup isn’t sufficient to run certificates and IPv6 firewall the way you’ve described and I don’t feel qualified to setup what you are suggesting. I can get a $50 router and setup a reasonably secure IPv4 with NAT and DHCP in 15 minutes.
> My prosumer $1,000 networking setup isn’t sufficient to run certificates and IPv6 firewall the way you’ve described and I don’t feel qualified to setup what you are suggesting. I can get a $50 router and setup a reasonably secure IPv4 with NAT and DHCP in 15 minutes.
My several-year-old Asus AC68 does IPv6 (my previous ISP had it), (Open)VPNing:
Just because you're not qualified does not mean it wouldn't be handy to those who are, but not-high IPv6 adoption is hampering them. Further, some of this would currently have to be done manually (mostly the cert provisioning: IPsec/IKEv2 can otherwise be fairly automated), but if there was more uptake there's no reason it couldn't be more automatic.
Yeah, IPv6 is heavily tuned to the needs of the large-scale network operators, and is actively worse for the regular user and small networks.
From user/small admin standpoint, the goal is to re-use as much admin knowledge as possible - and what's on the wire does not really matter. So the ideal IPv4 upgrade _for users_ is IPv4 with larger addresses, but otherwise behaving identically. Ideally all the admin tooling stays the same, and the software needs changing some struct names, and tweaking IP regex. And sure, it'll all be different on the wire and all the OS'es need to be upgraded - but that is not a problem, consumer OS'es live only for a few years anyway.
From large network operator standpoint, the goal is improve efficiency of the huge networks. So lets eliminate NAT everywhere, completely redo host addressing, get rid of DHCP, and so on - redesign everything from scratch so it's "better". Sure, it's a huge learning curve but they have departments full of network engineers, they can do it. They are not some part-time sysadmins who just want their network to keep functioning.
I have MultiWAN on OPNsense. My PC IP is always 192.168.0.12. My router decides which upstream it should go. If I go full IPv6, router should derive double IPv6 from both WANs and if main upstream goes down, stop advertising IPv6 from main upstream. Or stop advertising gateway. I don't know what is the right IPv6 way of doing MultiWAN.
Not only PC may change IP, but also servers. Legacy IPv4 DNS can be extended to IPv6, but that mechanical action is not flexible enough. With IPv6 we need to be able to mass replace IPv6 /64 prefix leaving all suffixes intact. We probably need /64 prefix alias system. Software is not prepared for this. In IPv4 SNAT and DNAT were being these "aliases". If NAT is not an option anymore, then DNS must step in.
For many server software it just not possible to listen on multiple IPv6 address. Last time I tried MySQL, it just could not listen on multiple addresses. I could not make it listen on IPv4 and IPv6, specifying two addresses. MySQL server wanted just one address. This address could be [::], which means all interfaces and all protocols. And Linux implements some stupid hack to accept IPv4 connections to IPv6 socket. And Windows Vista also adopted this brainrot. But this is all wrong. Servers have to learn to listen to multiple IPs. This is normal. And for good IPv6 servers should learn to not only listen on multiple IPs, most wanted multiple IPv6, but also rebind listeners on the fly. If I got disconnected from ISP, reconnected by DHCPv6, and ISP assigned another IPv6 prefix, then DynDNS should update all my zones to new /64 prefix, and all servers in my network should rebind listeners.
Or else we may abandon all that TRUE IPv6 philosophy and do SNAT in DNAT in IPv6 just like in IPv4, but with wider address space. But then again, software (another software) is not quite ready for this. Software is expecting public IPv6 address to be just reachable. And private IPv6 address to be just unreachable.
That's illustrates my point well - the "TRUE IPv6" philosophy is major changes in every network-facing user software.. that's why it has been 20+ years and it's not done yet.
And the justification of "Software is expecting public IPv6 address to be just reachable" is super silly. You have to be crazy in this day-and-age to operate without firewall. Every office, every home network should have "default-deny" policy from the internet. So no, your software should not expect to be reachable even once IPv6 adoption is complete.
When you compare it to other technologies like https, tls1.3, unicode, 5g cellular, wifi 6, wifi 5 or bluetooth versions, etc. It’s clear that ipv6 adoption is not what it should be if they launched a protocol with clearer benefits to the end user.