We needed IPv6 support five years ago. IPv6 is so vital because without it, we'll see the cost of public IPs skyrocket. I'm surprised it hasn't considering two of the places I worked for in the past few years had trouble purchasing IPs for some of their larger data centre offerings.
It's sorta like the network neutrality argument, except you're talking about limits on who can offer services to everyone vs those with newer IPv6 devices and ISPs. You can end up with two different Internets.
What product are you building where you can avoid needing public IPv4 addresses considering that the vast majority of the people on the internet still use IPv4? It seems like you'll still need both for many years.
Yes, I agree with you. Which again makes me wonder why djsumdog considers full IPv6 support so critical. Except for very unusual businesses it doesn't seem to make sense.
Our entire application back end is written in IPv6 only. We don't have an IPv4 version of our product. Until IPv6 was offered, no way for us to host our application on AWS.
Good question - It's not the APIs that are the issue, it's the actual IPv6 addresses in the packets on the wire that we need. All of our remote devices (typically on the order of 5 million+ for larger customers) have IPv6 addresses. We can use tunnel routers to get the traffic over IPv4 networks to the destination, but the applications themselves are addressing the devices with IPv6 addresses - which means, at least on the network segments that our many applications servers are running on, we need to have IPv6 routing working.
Everything we've done assumes an IPv6 network - trying to squish large device networks into IPv4 is just a losing battle for a huge number of reasons (address mobility, address conflict, large number of downstream devices (20,000+) per network segment, etc...)
Couple different classes of customers - utilities are the existing (Electric/Gas/Water meters) and IoT (Sensors, Street Lights, Parking) are the up and coming.
Both of them lend themselves well to mesh networking application, and mesh networks, in which any one of the 5mm+ deployed devices might appear in any one of the 10,000+ network segments, and in which we just want to concatenate the MAC address and Network segment to get a network address (basically SLAAC) - really makes IPv6 a pretty good fit.
A few months ago Apple made it a requirement for all new iOS apps and app updates to support IPv6 only networking.
If the app backend is not also available from a network where IPv4 is completely blocked, the app is rejected.
At the same time, AWS does not let new accounts to create EC2 instances outside of VPC, and only provided IPv6 support in the non-VPC classic stack (only available to old AWS accounts that signed up years ago).
So for the last few months, AWS has been unusable as a backend for iOS apps unless you have an old classic AWS account.
The requirement is only to work in networks with NAT64. That means your app can not hardcode IPv4 addresses and not rely on IPv4 only APIs, it has to work if any of its backend services are only visible through an IPv6 address from a NAT64 gateway and it receives that address from a DNS64 service. The backend service itself does not have to have IPv6 connectivity.
A funny quip, but since it seems like you're missing the point: what's the business impact of the choice, or the existence/absence of IPv6 support in a hosting provider?
If I'm running a small startup that's available as a website, how does IPv6 support matter to me? (Assuming that I can otherwise get IPv4 addresses for hosting my site, which I can.)
Because there are many other factors in choosing a hosting provider (price, performance, features, security, scalability, etc). It seems a bit weird that all of these would be less important to someone than IPv6. Though I guess I can imagine that for some businesses it could be hugely important. Was just wondering what OPs business was that it became an overriding priority.
Rolling out an IPv4 only stack right now is debt. IPv6 has finally hit the point where there's no longer an if portion to the question, but rather a when. Every server rolled out in an IPv4 only setup, every service built, etc, is one more potentially service-interrupting area that will have to be changed when port your stack to IPv6. If you're young and small, starting as IPv6 native means that the next few years you'll have an advantage over your competitors because they'll be thinking migrations while you're thinking about growing your business.
That's reasonable, but I think you significantly underestimate how long it will take before these sorts of conversions will become necessary. IPv6 is 20 years old. These things take decades not years.
In addition, I think you overestimate the difficulty of conversion. Most backend servers run on 10.x.x.x networks and that doesn't need to change. You just need a proxy in front of them that can speak IPv6. Installing a new proxy does not sound like a hard job. It sounds trivial.
It's sorta like the network neutrality argument, except you're talking about limits on who can offer services to everyone vs those with newer IPv6 devices and ISPs. You can end up with two different Internets.