Even if we could directly address every device on the internet, you'd still mostly want to run through a middle server anyway so you can send files and messages while the receiver device is sleeping, or to sync between multiple devices.
Pretty much the only loss was people self hosting servers, but as long as you aren't behind CGNAT you can just set up DDNS and be fine. Every ISP I've been with lets you opt out of CGNAT as well as pay for a static IP.
Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted change.
They're almost always deployed though because people end up liking the ideas. They don't want to configure VRRP for gateway redundancy, they don't want a DHCP server for clients to be able to connect, they want to be able to use link-local addresses for certain application use cases, they want the random addresses for increased privacy, they want to dual stack for compatibility, etc. For the people that don't care they see people deploying all of this and think "oh damn, that's nuts", not realizing you can still just deploy it almost exactly the same as IPv4 with longer addresses if that's all you want.
Or they're deployed because it's difficult to use IPv6 without them, even if you want to. For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.
Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
> For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.
On IPv4 I assume you're doing something which boils down to (from whatever network configuration tool you use):
ip addr add 192.168.1.100/24 dev eth0
ip route add default via 192.168.1.1 dev eth0
ip -6 addr add 2001:db8:abcd:0012::1/64 dev eth0
ip -6 route add default via 2001:db8:abcd:0012::1 dev eth0
ip neigh add 192.168.1.50 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent
ip -6 neigh add 2001:db8:abcd:0012::2 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent
> Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
I have a strong aversion to AWS... but if there is anything more difficult about this for IPv6 than IPv4 then that's entirely on what AWS likes to do rather than what IPv6 requires. E.g. if they only give you a dynamic link local gateway it's because they just don't want you to use a public address as the static gateway, not because IPv6 said it had to be so by not supporting unicast gateways or something.
There's also nothing about IPv6 ND that would make it take longer to discover the gateway from a statically configured unicast address than IPv4 ARP would take, but AWS may be doing a lot of optional stuff beyond just being a dumb gateway in their IPv6 implementation - again, not because IPv6 itself said it should be so but because they want to do whatever they are doing.
(I'm doing this using direct netlink calls from my init; this is all about booting as fast as possible. The IPv6 address information is coming from instance metadata.)
And no interoperability between the two without stateful network address translation.
Exhaustion was raised for 32-bit IPv4 in the very early 90s, when we had a few million active Internet users. Allocations were very sparsely used and growth in Internet usage was exponential. It didn't take much of an imagination to foresee a problem.
A 36-bit Internet would be little better. By the middle of the 90s we had ~45 million active Internet users, ending our 16x space advantage, even assuming we didn't just squander that with 8x as wasteful Class A allocations and bigger spaces reserved for uses that will never arise.
Today, we have ~70 billion connected devices: 5-6 billion home subscribers each with multiple devices in the home, 7.5 billion smartphones, 20 billion IoT devices, and all growing rapidly.
We'd need NAT. But NAT was a response to exhaustion concerns, as a stop-gap measure to provide time to design and transition to a proper solution. If we didn't have exhaustion concerns, there'd be no NAT. If we did have exhaustion concerns, brought on perhaps by the lack of NAT, we'd still have invented IPv6, because we'd still have been able to forecast that the Internet would rapidly outgrow 36 bits of address space.
edit: disclaimer, I work in this space, but my comments reflect my own opinion and are not necessarily those of my employer.
It's improbable that I'm off by an order of magnitude: 7 billion is far too low (we have 7.5 billion smartphones in the world!) and 700 billion is far too high; how low an estimate could we make without being unreasonably optimistic? 40b seems quite low to me - 7.5b smartphones, 5.6b connected users, 20b IoT devices, and commercial use of IPs - but if we took that value we'd be sitting at saturation for 36 bits of address space (60% utilisation is pretty darn good!) and the next decade would kind of suck.
- force ISPs to follow RIPE guidance on addressing (static prefix, at least /56 for every site, DHCPv6-PD)
- force the manufacturers of low-end routers (e.g. provided by ISPs) to have good IPv6 support (good firewalling, DHCPv6-PD, mDNS, PCP/UPNP, advertise static ULA prefix to have working local network even if internet connection is cut)
- force Android team to support DHCPv6
- force browsers to support full IPv6 addresses in URLs / URIs (link local addresses, scope id)
- force avahi / mDNS to support IPv6 scope id - make operating system manufacturers to have a better unified socket API which can resolve any type of address (IPv4, IPv6, DNS, mDNS, etc. maybe even URLs directly) and deprecate all other API
- make software developers to use this new API and don't try to parse IP addresses or URLs themselves
- have a good solution for multi-homing / WAN failover (without BGP and PI address space)
- have a good solution for mobile / roaming devices (phones, notebooks)
and maybe we could make IPv6 stable and universally working
(Waste a /40 for every company, get low on available prefixes and start over designing IPv8 to have 256 bit addresses with 184 bit host part...)
I do not want to be a "reasonably-skilled admin". Not my job nor desire. I want DHCP to work and NAT to exist which acts as a de-facto firewall and hides my internal network config from the outside world. All with zero or fewer clicks in my home router's config. With IPv4 this works. With IPv6 it does not. Simple choice for me then: find the IPv6 checkbox and turn it off, as usual.
My option is you should not handle router config at all and leave it to the ISP.
As a technologist, growing up involves learning not to blame the consumer. They are not holding it wrong, you just designed it in a dumb way.
But on the other hand, if we had run out sooner, perhaps IPv4 wouldn't be as entrenched and people would've been more willing to switch. Maybe not, of course, but it's at least a possibility.