Live data from Hacker News

AWS to begin charging for public IPv4 addresses

aws.amazon.com

301–310 of 377 posts

Re: AWS to begin charging for public IPv4 addresses

#301

So I have a tiny personal website hosted on ec2. Right now the DNS points to the server's public IPv4 address. But I don't really want to pay $40+/year for an IPv4 for my personal project. Does anyone have experience switching a small personal site to IPv6 only in 2023? I'm guessing the vast majority of my (North American/European-based) friends and visitors can probably connect just fine to an IPv6 address. I wish I…

> Does anyone have experience switching a small personal site to IPv6 only in 2023?

Trivial. Just put Cloudflare in front of it.

Re: AWS to begin charging for public IPv4 addresses

#302

Earlier quoted context omitted.

According to Google ( https://www.google.com/intl/en/ipv6/statistics.html ), 60% of word-wide users wouldn't be able to visit your website. In the US, it would be about ~50% of users, while in Europe it's ranging from 30% (France) to 98% (Spain) who wouldn't be able to visit the website. But yeah, I'd do what you say in the bottom of your comment. Add AAAA records and then see how many people uses ipv6 compared to ip…

I think there’s a difference between “don’t” and “can’t”. It’s not clear to me on that page how it describes “can’t”, other than ambiguous (to me) graph labels. Is there more info elsewhere that describes the “can’t”?

Chrome connects to google through ip6, if it succeeds, then ip6 is available, thus they gather statistics.

Re: AWS to begin charging for public IPv4 addresses

#303
post #79

The only barrier for me to go IPv6-only is those VPS that are provided with a single /128 IPv6, and I do not know of a service that would offer IPv6 tunneling other than HE, that requires an IPv4 endpoint. The day I get a full /48 or /64 with my VPSes, I'm ready to drop IPv4.

Vultr/Linode offer a full /64. Linode even offers /56 with justification.

Re: AWS to begin charging for public IPv4 addresses

#304

Earlier quoted context omitted.

According to Google ( https://www.google.com/intl/en/ipv6/statistics.html ), 60% of word-wide users wouldn't be able to visit your website. In the US, it would be about ~50% of users, while in Europe it's ranging from 30% (France) to 98% (Spain) who wouldn't be able to visit the website. But yeah, I'd do what you say in the bottom of your comment. Add AAAA records and then see how many people uses ipv6 compared to ip…

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.

It's a chicken and egg problem: as long as sites are available through ip4, ISPs have no incentive to provide ip6, and since ISPs often don't provide ip6, sites can't go ip6-only. One possible solution would be to provide both and throttle ip4 traffic, then better speed can provide incentive to upgrade to ip6.

Re: AWS to begin charging for public IPv4 addresses

#305

Earlier quoted context omitted.

$40/mo is outrageous? We spend thousands a month on AWS and drive most traffic thru a single NAT gateway. It's rock solid and it "just works" without any fuss. Totally worth it.

$40/month just to run it, but then $0.045 per GB data rates. The data rates are what is outrageous. NAT Gateways comprise a non-trivial portion of many customer's bills for this reason.

Exactly, it is $32 just to have it turned on 24/7 and then you pay additionally. Looked into it as it is the only(?) way to get dedicated IP for Lambda which is a common use case, which also explains why it is so costly. They lure you in free tier and then charge for all the necessities.

Re: AWS to begin charging for public IPv4 addresses

#307
post #226

Earlier quoted context omitted.

TCP does not use IP fragmentation, and the IP packets are marked "Don't fragment". TCP performs its own fragmentation and every packet gets a TCP header in its leading section. A NAT, Firewall, or end-host can L4 route the TCP packet as-is and does not need to correlate with other packets. Edited to extend: this is why TCP has a "Maximum Segment Size", and why Path MTU Discovery information has to be passed into the…

It could not have copied the UDP header. Otherwise you wouldn't be able to put any new protocol on IP without teaching it to every router.

Well about those new IP protocols...

Re: AWS to begin charging for public IPv4 addresses

#308
post #268

Earlier quoted context omitted.

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…

Even well-behaved unfragmented UDP should be more expensive to NAT because it doesn't have an end-of-stream "FIN" marker, meaning stateful middleboxes need to retain state for longer because they can only time out.

Timeouts on UDP are usually much shorter than TCP, so it's not as bad as it sounds.

Re: AWS to begin charging for public IPv4 addresses

#309

So I have a tiny personal website hosted on ec2. Right now the DNS points to the server's public IPv4 address. But I don't really want to pay $40+/year for an IPv4 for my personal project. Does anyone have experience switching a small personal site to IPv6 only in 2023? I'm guessing the vast majority of my (North American/European-based) friends and visitors can probably connect just fine to an IPv6 address. I wish I…

> tiny personal website

I'd recommend just migrating to cloudflare pages or github pages; they're both free

Re: AWS to begin charging for public IPv4 addresses

#310

Earlier quoted context omitted.

Not to mention the absurd fact that accessing (IPv4) AWS APIs from a private subnet requires paying for either a NAT gateway or an interface endpoint (we got bitten by sending a ton of Kinesis traffic through a NAT gateway once)

This is one thing Google Cloud does well - traffic to Google services bypasses NAT gateway, even over IPv4. I was curious how they do this, so I set up a service on Google Cloud Run that just echo'd the user's public IP address. When curl'd over IPv4, it said I was coming from a unique local (i.e. private) IPv6 address. The private IPv4 address of my server was embedded in the address, along with some other random-lo…

I know Google’s load balancers use BGP. So a load balancer will have a single IP address, but you don’t talk directly to that IP. Google’s servers take over as traffic is being routed.
Post reply on HN