I'm kinda sick of all the AWS posts on here, but I'm trying to be fair since some of them are really interesting.
This is one of those that's more of a "about damn time," features that'd I'd care about if I already didn't go with Digital Ocean/Linode instead just because of IPv6 support.
The reason there are all these posts in the last few days is because AWS's conference re:Invent is going right now in Las Vegas, and a lot of these announcements are therefore being made right now.
This is the post I've been waiting for 2+ years - we have a ton of projects that we would like to deploy on AWS, but EC2 and friends have never supported IPv6, which has blocked us from moving forward, and our customers are reluctant to deploy on anything other than the big 4 (IBM/Google/Azure/AWS).
I think "about damn time", but I definitely want these posts - I use AWS despite its flaws, and it's important to me to know what's going on.
As long as AWS is both widely used by existing users, and is a likely option for new users evaluating alternatives, these AWS posts are always relevant on HN.
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.
Great! Lots of people on Hacker News use AWS because places like Linode and DO don't actually have all the services and scale their work requires. Believe me, we agree that this announcement is several years overdue. I think most engineers who work in AWS would also agree. But when you get to their scale, it's hard to make big changes like this in a safe way. The fact that it rolled out in a brand-new region (us-east-2 only for now) is good evidence that they are being very very careful with this rollout.
And as mentioned, the reason there are so many AWS posts this week is because they save up all their announcements for the conference going on right now. I sorta wish they'd spread the stuff out more, myself, but these are mostly HN-front-page quality announcements. It's just a year's worth of work dumped all in two days.
>But when you get to their scale, it's hard to make big changes like this in a safe way
Which only makes it more baffling that AWS still doesn't support IPv6 everywhere.
IPv6 is 8 years older than AWS. AWS is a decade old. Given that the inevitability of IPv6 is long known and that it's well known that as a rule changes get more difficult the bigger you get, I would have expected Amazon to start IPv6 deployment much earlier, back when AWS was much smaller.
