Live data from Hacker News

AWS to begin charging for public IPv4 addresses

aws.amazon.com

141–150 of 377 posts

Re: AWS to begin charging for public IPv4 addresses

#141
post #131

Earlier quoted context omitted.

Businesses and organizations are holding IPv6 back, not consumers. No one I talk to is prioritizing IPv6 migrations or spending money to upgrade gear that will support it. Maybe some net new stuff might get it, but for most businesses IPv4 is and will be the default, simply because they can't be bothered to do something different.

Hmm, I use IPv4 mostly because nobody in their right mind can remember a IPv6 address…

Who's out there remembering IPv4 addresses?

Re: AWS to begin charging for public IPv4 addresses

#142

Earlier quoted context omitted.

Sigh, so basically it's impossible to switch without shredding an already tiny audience. I'm sure it won't be a nice UX either to have a "can't connect to this IP" error in someone's browser. IPv6 has been around for so long now, I'm disappointed it doesn't have a little bit higher adoption.

And if all else fails, you can put something like Cloudflare in front of it to handle IPv4 traffic.

Which than you're back to paying $40+/year to ensure you don't get wiped from their "free" tier when they feel like it.

Nothing is free forever.

Re: AWS to begin charging for public IPv4 addresses

#143

Earlier quoted context omitted.

For example, rather than simply routing IP packets and then forgetting them, you need to statefully inspect every TCP segment and every supposedly connectionless UDP conversation, you need to maintain state for every live conversation, and you need to mitigate DOS with all those resources. At that point, you might as well be running a Layer 7 Firewall or an Intrusion Protection System.

UDP is connectionless precisely so you can build novel stateful protocols on it. There’s no promise in UDP that you’ll be able to statelessly monitor it.

UDP is actually more expensive to NAT than TCP is. The reason is UDP fragmentation, which is my vote for the worst, and least forgivable, design error of TCP/IP.

Instead of putting the fragmentation in L4 (like QUIC now does) and including a UDP header on every fragmented packet in a datagram, UDP only includes the header on the first packet. With fragmentation happening; firewalls, NATs, and end-hosts have to buffer and coalesce IP packets based on IP IDs, before the destination can be identified. It's a real nuisance. A lot of CGNAT "stateless" implementations can't handle this and you get very hard to debug issues when there are fragmentation and MTU mismatches.

Re: AWS to begin charging for public IPv4 addresses

#144
post #16

> A new blog post shows you how to use Elastic Load Balancers and NAT Gateways for ingress and egress traffic, while avoiding the use of a public IPv4 address for each instance that you launch. It would be nice if this came with reasonably priced NAT gateways. The current pricing is outrageous.

100% agree, they need to offer steep reserved instance pricing for NAT gateways. To deploy 3 NAT gateways (HA one in each availability zone) is $99/mo just for the instances.

Re: AWS to begin charging for public IPv4 addresses

#145

Earlier quoted context omitted.

Businesses and organizations are holding IPv6 back, not consumers. No one I talk to is prioritizing IPv6 migrations or spending money to upgrade gear that will support it. Maybe some net new stuff might get it, but for most businesses IPv4 is and will be the default, simply because they can't be bothered to do something different.

Serious question, is there any enterprise gear made today which does not support IPv6? I have assumed that the natural hardware upgrade cycles made it so 99% of all active equipment could support the technology, even if it was not configured to do so.

Man in the middle certificate re-signing deep packet inspection firewalls are notorious for not supporting IPv6. Most everything else has switched, but many network admins fear IPv6 and don't want to have to learn something new.

Re: AWS to begin charging for public IPv4 addresses

#146
post #84

Earlier quoted context omitted.

For iOS maybe. Most of those applications are also using Apple's networking libraries and are effectively required to be on Apple's infinite software update treadmill to continue to be listed, keeping them young and hip in perpetuity. This is the upside to that treadmill, things are up to date or just stop working. But I don't think that's representative. "Or just stop working" isn't a valid alternative to the rest o…

A hospital's MRI machine doesn't need an internet connection. IPv4 only intranets are fine and we are never going to get rid of them. But anything that connects to the internet needs to be updated regularly, if only for security and vulnerability reasons. If you have a 10-year-old functional and supported desktop, it most likely supports being IPv6 only just fine. The typical 10-year-old desktop came from the factory…

Windows networking became v6-first in Vista, over a decade ago.

Re: AWS to begin charging for public IPv4 addresses

#147
post #137
post #124

Earlier quoted context omitted.

AWS NAT gateway is $0.045 per hour plus $0.045 per GB. The hourly fee seems mostly okay - for largish users, one or two per region is fine. $0.045 per GB is nuts . That’s $20.25/hour or $14580/mo for 1 Gbps. One can buy a cheap gadget using very little power that can NAT 1 Gbps at line rate for maybe $200 (being generous). One can buy a perfectly nice low power server that can NAT 10Gbps line rate for $1k with some c…

Bit confused. Couldn't you just run a Linux VM to do your NAT and only pay normal egress?

> just run a Linux VM

+ Run extra for failover, HA etc + manage security + Monitor performance + ...

Re: AWS to begin charging for public IPv4 addresses

#148
post #16

> A new blog post shows you how to use Elastic Load Balancers and NAT Gateways for ingress and egress traffic, while avoiding the use of a public IPv4 address for each instance that you launch. It would be nice if this came with reasonably priced NAT gateways. The current pricing is outrageous.

NAT is pretty computationally intensive, this is why e.g. ISPs & mobile carriers are pushing IPv6 over CGNAT.

> ISPs & mobile carriers are pushing IPv6 over CGNAT

LOL. Not Metronet. They are doubling down on CGNAT. They've acquired ISPs with IPv6 and killed it in favor of CGNAT.

Re: AWS to begin charging for public IPv4 addresses

#149
post #112

Earlier quoted context omitted.

I couldn't believe it either, but using Chome on ChromeOS 114, updated yesterday, all the public sites report that I am connecting from 2002::/16

Interesting. It's only possible to terminate 2002::/16 using a public IPv4 address, so if you're behind a NAT router, then the router itself must be running 6to4.

Aha! Thanks for the hint: I recently had to reconfigure my router from factory settings. The IPv6 configuration, sure enough, was kicked into 6to4 mode. I set it to "Auto Config" and now I've got end-to-end IPv6 connectivity with, look Ma, no NAT!

Thank you, p1mrx!

Re: AWS to begin charging for public IPv4 addresses

#150
post #131

Earlier quoted context omitted.

Hmm, I use IPv4 mostly because nobody in their right mind can remember a IPv6 address…

Who's out there remembering IPv4 addresses?

If only there were some sort of a system for translating human readable names to network addresses...
Post reply on HN