> Another thing that changed on the server side was that, thanks to AWS and the like, it became trivial to set up a massive private network. Nowadays you can have a cluster of thousands of virtual machines that communicate with one another entirely within a VPC. Only machines that need to communicate with external entities get a public IPv4 address. This kind of setup not only frees up a /20, but also has the benefit of being more secure.
This is something that people who are too deep in the weeds of legacy networking don't realize. The future is to not use IP at all within enterprise and not use the Internet at all for B2B communication. In fact the future is to not use any networking abstraction at the application layer.
To start with every device can be in VPCs with the same private /16 because they can easily communicate securely within the cloud environment via services like VPC lattice or using S3/API gateway both within and across companies. Let the cloud provider handle the undifferentiated heavy lifting of figuring out how to get data from one device to another. In time third parties will establish cross provider bridges.
Then you can start to ask yourself why your applications need the "networking" abstraction at all. If you want to send some bits to an application either within or across companies it should be just a matter of putting the bits in some ___location the receiving application has access to and the cloud providers can figure out how to actually make the bits accessible to the other application. Think writing to an S3 bucket using a VPC endpoint but with less HTTP/TCP/IP cruft in the middle.
As a benefit the identities on both sides will be established by the cloud providers so you don't need to worry your devices are reachable by malicious actors. Then you can start to get rid of all this cyber security nonsense that has grown up around the ridiculously insecure protocols that were developed in the 70s for connecting trusted machines and somehow are still in use today.
Internet service providers and cloud providers may or may not use IPv6 but enterprises, schools, and end users certainly won't need to.
IPv6 had this cool idea that each subscriber would get a /64, and devices within the subscriber's network would be assigned /128s with the last 64 bits matching their MAC addresses.
Except it turns out that most organizations see no need to give internal devices globally routable IP addresses, much less expose their MAC addresses. If anything, it's a vulnerability, not a feature.
On the other hand, going too far along with your idea would look like a dystopian future where everyone is corralled into one corporate walled garden or another. So it's understandable that there's a strong gut reaction against it. Fortunately, there are enough IPv4 addresses to support both corporate walled gardens and a reasonable number of independent operators.
This is something that people who are too deep in the weeds of legacy networking don't realize. The future is to not use IP at all within enterprise and not use the Internet at all for B2B communication. In fact the future is to not use any networking abstraction at the application layer.
To start with every device can be in VPCs with the same private /16 because they can easily communicate securely within the cloud environment via services like VPC lattice or using S3/API gateway both within and across companies. Let the cloud provider handle the undifferentiated heavy lifting of figuring out how to get data from one device to another. In time third parties will establish cross provider bridges.
Then you can start to ask yourself why your applications need the "networking" abstraction at all. If you want to send some bits to an application either within or across companies it should be just a matter of putting the bits in some ___location the receiving application has access to and the cloud providers can figure out how to actually make the bits accessible to the other application. Think writing to an S3 bucket using a VPC endpoint but with less HTTP/TCP/IP cruft in the middle.
As a benefit the identities on both sides will be established by the cloud providers so you don't need to worry your devices are reachable by malicious actors. Then you can start to get rid of all this cyber security nonsense that has grown up around the ridiculously insecure protocols that were developed in the 70s for connecting trusted machines and somehow are still in use today.
Internet service providers and cloud providers may or may not use IPv6 but enterprises, schools, and end users certainly won't need to.