> You can configure your Application Load Balancer so that clients can communicate with the load balancer using IPv4 addresses only, or using both IPv4 and IPv6 addresses (dualstack).
I'd love to go IPv6 only. Amazon won't let me, and charges for the privilege.
They make more money from selling servers than they do from selling v4 addresses. There's a limit to how many v4 addresses they can get, so they'll make more money if they can sell servers without v4 addresses -- otherwise the limit on v4 addresses will turn into a limit on the number of servers they can sell.
I agree and would first urge people to test IPv6 client access using some lazy-loaded image that is IPv6 only on their website. It should look like a normal resource so that false-negatives are not introduced by NoScript or uBlock.
People can of course manually test here [1] from their homes, schools, work place. I would wager most cellular data networks would be fine. The impact would probably depend on how a website is utilized. Stats on mobile vs. non-mobile would probably be telling. The people on their cell should test LTE vs Wifi and clear cache between tests.
That seems unlikely given that the vast majority of users have no clue what the underlying service provider is for the web services they're using, and those who do know are savvy enough to understand the difference between an AWS issue and a configuration issue.
This could also slow down IPv6 adoption. This is going to free up a ton of IPv4 addresses, reducing the need for AWS to purchase new ranges. I know of a few companies that started auditing their public IPv4 usage on AWS after the original announcement.
Some AWS customers have released 80+% of their public IPv4 addresses. The alternative isn't IPv6, it's private addresses. Many AWS customers have been slapping public IPs on EC2 instance just because they could or because they didn't know any better.
"This is going to free up a ton of IPv4 addresses, reducing the need for AWS to purchase new ranges."
Yup, this has been obvious for a while if you read the better economic analyses. Charging for IPv4 doesn't on its own remove it. It creates some sort of economic balance between the value and scarcity of the IPv4 address space.
When you're trying to fit the entire world of 7 billion people into 4 billion addresses, the space looks pretty scarce. But assuming a roughly power law distribution of services and their importance of being on IPv4, as you cut off the people with lower-end needs, like, "my cell phone needs to communicate on the internet so let's give it an IPv4 address", you extremely rapidly cut through orders of magnitude of the old uses.
That long tail of "Facebook is not willing to cut off even .01% of its user base so it has IPv4 addresses to serve on" may take a long time to get through, but we're well through getting huge swathes of the other users off of it.
What kills IPv4 is in the far future when the expense of maintaining it specially exceeds the benefits. Since maintaining it is rather cheap, this is going to take a while. But as IPv4 diminishes in importance, ironically, so does the value of entirely eliminating it. When it is 1% of the traffic, who will really be desperate to drop that to zero?
I don't find it at all difficult to imagine that someone like Google or Apple would sunset ipv4 when it reaches single digit percentage. They know no ISP would risk losing connectivity to them.
For example Apple has already been requiring that appstore apps work in ipv6 only networks since 2016. They can just keep tightening such rules until ipv4 dies.
It's naive to think that maintaining ipv4 (/dualstack) networks is (and will remain) cheap at large global scale like Google.
Thing is if it is only 0.01% of users Facebook won't give up on they can just do a few ipv4 server/address. Now Facebook has severs around the world, but if it is only a few users they just need two servers - and that is only for redundancy. Now they have thousands (maybe even millions? I don't know) of servers and they may as well give all the external facing ones IPv4 addresses as most need that anyway and so the hassle of maintaining IPv6 only servers isn't worth it.
And of course if you are in the 0.01% you will discover that while Facebook and google won't give up on you many other providers will as it just isn't worth the cost. By that time the cost won't be IPv4 addresses - they will be again free - it will be the cost of maintaining IPv4 on all the routers and servers. (the routers mean IPv4 will cost more, but it won't be for the address it will be for routing access)
Correct. I am convinced that the best way to speed up IPv6 adoption is to provide IPv6-only networking but with NAT64.
Historical evidence is on this: cell phone ISPs have started doing this a long time ago and look at how high the IPv6 adoption is on mobile.
Also, an IPv6-only network removes the happy eyeballs algorithm so any routing issues on the IPv6 internet won't be papered over by the speed of the IPv4 internet, so there's more incentive to fix that.
Of course everything I said above is conditioned on speeding up IPv6 adoption as a goal. Unfortunately for many, IPv6 adoption is not a goal at all, so nothing I said above applies to them.
Don't forget about MAP-T which does IPv4 NAT over IPv6. The client is IPv4, the ISP is IPv6, and server is IPv4. This is still CGNAT but IPv6 is provided. But means ISP uses IPv6 internally.
The problem for NAT64 in general use is that there is lots of IPv4-only software. NAT64 is great for business networks where control the software, but home users are going to try to use their Xbox 360 or Windows game from the 90s.
>The alternative isn't IPv6, it's private addresses.
I really wish more AWS services or workflows worked with private addresses. Sometimes a service can be completely internal but needs a public address to either talk to Dynamo or install packages; but those endpoints aren't available via private IP, even though they physically live in the same region
Customers having to switch to private addressing still seems like more pressure than customers having infinite free public addresses was providing, not less.
I.e. address exhaustion pressure isn't only about the complete inability to buy an IP it's about how much work you have to do to use IPv4 addresses.
It depends on how you measure IPv6 adoption. Is it about your ability as consumer to use only IPv6, or your ability to offer a website reachable only via IPv6.
AWS charging for IPv4 will help with the former, because companies now have more of a reason to care about IPv6. But it might delay the latter, because fewer IPs wasted on internal servers means less price pressure on useful IPv4 use by ISPs, giving those that still hold out less financial incentive to change anything.
AWS owns about 7% of the entire public IPv4 allocation space. There's no way this is going to slow down IPv6 adoption. Nobody likes NAT, especially when it comes to servers.
IPv6 has been such a wild ride. About 7 years ago there was a big IPv4 depletion scare when ARIN made it harder to obtain IPv4. I did a bunch of dual stack deployments for customers around this time. In subsequent years quite a few of them ended up paying us to come back in and un-deploy IPv6 as their network engineers or often 'the IT guy' neglected to maintain firewall rules and access-lists leading to major security issues. I can't really think of any other vital technology like this that has rotted on the vine and had so many false starts.
Anecdote, my ISP gives us IPv6 but not my employer. We use the IT equipment till the last breadth. I have seen, permanent table-fan running towards Floor's network hub. I guess that one is NOT IPv6 ready. :D
I doubt it. Realistically the AWS charge mostly causes companies to stop giving IPv4 addresses to servers that never directly talk to customers. As a knock-on effect this will cause tooling to become more IPv6 aware, and put pressure on SaaS in infrastructure monitoring and dev tooling to be reachable via IPv6 (for example this might cause github to finally fix their IPv6 game because of higher customer demand).
Maybe companies use the same opportunity to make sure their services also work via IPv6. But they won't stop offering their services on IPv4, and AWS changes don't put meaningful pressure on ISPs to roll out IPv6. If anything it will reduce the pressure on the price of IPv4 addresses, making it more viable for ISPs to hold out.
I doubt it, especially that there is an option of using private/CGNAT ranges instead of adopting a whole new protocol. Everyone who cares about IPv6 have already done their part, and people who don't care about it will likely use the lower-friction option, and between private IPv4 networks and IPv6 I bet that a lot of people will see private IPv4 as a lower-friction option.
The tracker is for client connections to Google. To impact that graph AWS customers would have to, en masse, decide the $1/m charge is worth losing half their current users over and then the users and ISPs would have to scramble for IPv6.
The more likely story is places using AWS pay 1$/m for a public address and use private/IPv6 internally. I.e. an incremental step, not a revolution in the chart.
IPv6 adoption is not uniformly distributed. Some usersbases might have higher penetration. But yeah, I doubt there are many where it's high enough to be worth it.
I am not sure if these incentives help IPv6 adoption. Nobody can turn off IPv4 today; there is always a long tail of people with broken IPv6 stacks. Since IPv4 continues to work, I'm not even sure it's worth setting up IPv6 so that someday you can switch IPv4 off; do work that gets you customers today, switch off of IPv4 when it becomes a crisis. I think the best incentive would be a high price on IPv4-only, but if you do the work to support dual-stack, then that fee is waived. That way, there is savings for doing the technical work today, and you pave the way for a brighter future.
Personally, I think I'd pay the fee to not be dual stack these days. Everything in your infrastructure has to now check two things. Your website uptime checker has to probe via both IPv4 and IPv6. You have to maintain two sets of firewall rules. You have to remember to "ping -6 example.com" in addition to "ping example.com" when checking connectivity. I don't think it's worth the effort, and I say that as someone who first made their website available over IPv6 in like 2008. (I moved providers in 2020 and the new one didn't have IPv6. It made me sad. But now it's just one less thing to worry about.)
There are internal servers talking to other servers which don't need ipv4. There's zerotier that gives you a private IPv6 network regardless of your network capabilities. The only part that actually still requires ipv4 is the general public user.
But I refuse to let them switch me, because their IPv6 offer does not include a v4 address, only CGNAT. Of course if everyone was on v6 that wouldn't matter, but until then I need the ability to forward ports to my server!
This isn't even technically in breach of the ToS; I have a business line, mostly for the customer support.
And thus I add to the problem, because now anyone who wants to connect to said server also needs a v4 option...
Crusty enterprise networks are far bigger problem than retail ISPs. This is clearly visible by the fact that you have clear weekend peaks in e.g. Googles IPv6 adoption stats.
This is measurably false. Google’s IPv6 adoption graph has noticeable spikes on the weekends when people use their home internet, and decreases during the work week when people go to work: https://www.google.com/intl/en/ipv6/statistics.html
Adoption is limited by enterprises who are change-averse and already entrenched in ipv4. Residential ISP’s have made much more progress.
My current (Brightspeed) and previous (Spectrum) ISPs have nominally "supported" IPv6. Except ... not nationwide, there are regional differences in how it's done and how well it works. And nobody can tell me if my specific location is supported or how to configure my equipment to use it.
On one hand, that gives me hope that we're getting closer to near-universal ISP support. On the other hand, it's been like this for so long I question if it'll ever improve.
Some sort of NAT64 is probably a better idea, because that applies below the TLS layer.
When people complain about IPv6 and IPv4 being incompatible, the fact that you can establish a cross-protocol TCP+TLS session with just a NAT is a remarkable counterexample. It could've been a lot worse.
Readit News
https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...
> You can configure your Application Load Balancer so that clients can communicate with the load balancer using IPv4 addresses only, or using both IPv4 and IPv6 addresses (dualstack).
I'd love to go IPv6 only. Amazon won't let me, and charges for the privilege.
Look at the list of "no"s on https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-su....
Want IPv6...... please hold forever.
People can of course manually test here [1] from their homes, schools, work place. I would wager most cellular data networks would be fine. The impact would probably depend on how a website is utilized. Stats on mobile vs. non-mobile would probably be telling. The people on their cell should test LTE vs Wifi and clear cache between tests.
[1] - https://test-ipv6.com/
Deleted Comment
"Elastic Load Balancing pricing" - https://aws.amazon.com/elasticloadbalancing/pricing/
"AWS Free Tier now includes 750 hours of free Public IPv4 addresses, as charges for Public IPv4 begin"- https://aws.amazon.com/about-aws/whats-new/2024/02/aws-free-...
Or something crypto. Pay to your IPv6 address, or nodes must be IPv6.
Or social network.
Start with an edge case that gets insiders to change behaviour.
Some AWS customers have released 80+% of their public IPv4 addresses. The alternative isn't IPv6, it's private addresses. Many AWS customers have been slapping public IPs on EC2 instance just because they could or because they didn't know any better.
Yup, this has been obvious for a while if you read the better economic analyses. Charging for IPv4 doesn't on its own remove it. It creates some sort of economic balance between the value and scarcity of the IPv4 address space.
When you're trying to fit the entire world of 7 billion people into 4 billion addresses, the space looks pretty scarce. But assuming a roughly power law distribution of services and their importance of being on IPv4, as you cut off the people with lower-end needs, like, "my cell phone needs to communicate on the internet so let's give it an IPv4 address", you extremely rapidly cut through orders of magnitude of the old uses.
That long tail of "Facebook is not willing to cut off even .01% of its user base so it has IPv4 addresses to serve on" may take a long time to get through, but we're well through getting huge swathes of the other users off of it.
What kills IPv4 is in the far future when the expense of maintaining it specially exceeds the benefits. Since maintaining it is rather cheap, this is going to take a while. But as IPv4 diminishes in importance, ironically, so does the value of entirely eliminating it. When it is 1% of the traffic, who will really be desperate to drop that to zero?
For example Apple has already been requiring that appstore apps work in ipv6 only networks since 2016. They can just keep tightening such rules until ipv4 dies.
It's naive to think that maintaining ipv4 (/dualstack) networks is (and will remain) cheap at large global scale like Google.
The service providers who have to maintain IPv4 and IPv6 configurations in their networks.
Should be more like 8bn now
And of course if you are in the 0.01% you will discover that while Facebook and google won't give up on you many other providers will as it just isn't worth the cost. By that time the cost won't be IPv4 addresses - they will be again free - it will be the cost of maintaining IPv4 on all the routers and servers. (the routers mean IPv4 will cost more, but it won't be for the address it will be for routing access)
Historical evidence is on this: cell phone ISPs have started doing this a long time ago and look at how high the IPv6 adoption is on mobile.
Also, an IPv6-only network removes the happy eyeballs algorithm so any routing issues on the IPv6 internet won't be papered over by the speed of the IPv4 internet, so there's more incentive to fix that.
(If you are interested in doing this at home, the most up-to-date documentation is a presentation from RIPE https://ripe87.ripe.net/wp-content/uploads/presentations/8-I... that covers NAT64/DNS64/DHCP108/PREF64).
Of course everything I said above is conditioned on speeding up IPv6 adoption as a goal. Unfortunately for many, IPv6 adoption is not a goal at all, so nothing I said above applies to them.
The problem for NAT64 in general use is that there is lots of IPv4-only software. NAT64 is great for business networks where control the software, but home users are going to try to use their Xbox 360 or Windows game from the 90s.
I really wish more AWS services or workflows worked with private addresses. Sometimes a service can be completely internal but needs a public address to either talk to Dynamo or install packages; but those endpoints aren't available via private IP, even though they physically live in the same region
If you’re in a 6-only VPC/subnet, an egress only gateway will allow you to grab packages from IPv6 enabled public data sources.
I.e. address exhaustion pressure isn't only about the complete inability to buy an IP it's about how much work you have to do to use IPv4 addresses.
AWS charging for IPv4 will help with the former, because companies now have more of a reason to care about IPv6. But it might delay the latter, because fewer IPs wasted on internal servers means less price pressure on useful IPv4 use by ISPs, giving those that still hold out less financial incentive to change anything.
https://www.google.com/intl/en/ipv6/statistics.html
Anecdote, my ISP gives us IPv6 but not my employer. We use the IT equipment till the last breadth. I have seen, permanent table-fan running towards Floor's network hub. I guess that one is NOT IPv6 ready. :D
Maybe companies use the same opportunity to make sure their services also work via IPv6. But they won't stop offering their services on IPv4, and AWS changes don't put meaningful pressure on ISPs to roll out IPv6. If anything it will reduce the pressure on the price of IPv4 addresses, making it more viable for ISPs to hold out.
I doubt it, especially that there is an option of using private/CGNAT ranges instead of adopting a whole new protocol. Everyone who cares about IPv6 have already done their part, and people who don't care about it will likely use the lower-friction option, and between private IPv4 networks and IPv6 I bet that a lot of people will see private IPv4 as a lower-friction option.
The more likely story is places using AWS pay 1$/m for a public address and use private/IPv6 internally. I.e. an incremental step, not a revolution in the chart.
IPv6 adoption is not uniformly distributed. Some usersbases might have higher penetration. But yeah, I doubt there are many where it's high enough to be worth it.
Personally, I think I'd pay the fee to not be dual stack these days. Everything in your infrastructure has to now check two things. Your website uptime checker has to probe via both IPv4 and IPv6. You have to maintain two sets of firewall rules. You have to remember to "ping -6 example.com" in addition to "ping example.com" when checking connectivity. I don't think it's worth the effort, and I say that as someone who first made their website available over IPv6 in like 2008. (I moved providers in 2020 and the new one didn't have IPv6. It made me sad. But now it's just one less thing to worry about.)
To the public internet, no. To internal services, possibly, and if you use a CDN you can have everything on the origin side using IPv6.
... for all services.
There are internal servers talking to other servers which don't need ipv4. There's zerotier that gives you a private IPv6 network regardless of your network capabilities. The only part that actually still requires ipv4 is the general public user.
So, no need to bother with IPv6 and its myriad complexities just for that.
But I refuse to let them switch me, because their IPv6 offer does not include a v4 address, only CGNAT. Of course if everyone was on v6 that wouldn't matter, but until then I need the ability to forward ports to my server!
This isn't even technically in breach of the ToS; I have a business line, mostly for the customer support.
And thus I add to the problem, because now anyone who wants to connect to said server also needs a v4 option...
Adoption is limited by enterprises who are change-averse and already entrenched in ipv4. Residential ISP’s have made much more progress.
On one hand, that gives me hope that we're getting closer to near-universal ISP support. On the other hand, it's been like this for so long I question if it'll ever improve.
* https://news.ycombinator.com/item?id=39205515
When people complain about IPv6 and IPv4 being incompatible, the fact that you can establish a cross-protocol TCP+TLS session with just a NAT is a remarkable counterexample. It could've been a lot worse.