Live data from Hacker News

AWS Customers Cannot Escape IPv4

tty.neveragain.de

201–210 of 316 posts

Re: AWS Customers Cannot Escape IPv4

#201
> RDS (nine in ten customers have public IP on RDS by accident)

AWS does make it easy to fuck up with its default settings. Subnets that auto-assign EIPs for every instance attached to them should not exist, period. And neither should RDS instances or anything else be reachable from the public Internet by default.

Re: AWS Customers Cannot Escape IPv4

#203
post #132

Earlier quoted context omitted.

> IPv6 just works Only via the herculean efforts of a bunch of people having to literally reinvent the world to deal with it. Everything needs IPv6 support specifically. It's such a mess, if IPv6 has just been identical to IPv4 but with larger addresses we would be on it by now. But no they had to make it their religious crusade to eliminate NAT (and now we have NAT66 so clearly a winner) put IPSec in there which is…

Yes I'm not qualified to really argue the point but naively it never made sense to me that IPv4 was not backwards compatible with IPv6 addressing. You'd think the people on the committees would have foreseen the trouble that would avoid. Telephone companies didn't make you dial the area code for local numbers. Microsoft bent over backwards to make sure that old DOS software still worked on Windows. Linux has a mandat…

IP is a bidirectional protocol, so the correct analogy would be if Microsoft had to make DOS software run on Windows, and Windows software run on DOS.

Remember the error "This program cannot be run in DOS mode"?

IPv4 and IPv6 are unidirectionally compatible using NAT64. The fact that you can make an IPv6 to IPv4 TLS connection using a packet-level translator without breaking the endpoints is quite remarkable, and it wouldn't have been possible if the protocols were too dissimilar.

Re: AWS Customers Cannot Escape IPv4

#204
post #27

Earlier quoted context omitted.

IPv6 adoption is only going to further the consolidation of customers onto the big monopoly providers. They will be the only ones who can afford to add the dedicated network engineering staff to make it work reliably. Most people don't realize there are two IPv6 internets right now, the Cogent side and the Hurricane Electric side. Both are equally sized and refuse to connect to each other, so you need to know that an…

> two IPv6 internets right now, the Cogent side and the Hurricane Electric side Cogent engages in peering spats on IPv4 too; this dynamic is not new with or unique to IPv6, or limited to Cogent/HE. The lesson here is to not go singlehomed under Cogent, not to reject IPv6.

The takeaway here was that you need to be aware of it to make IPv6 work. Again, your average operator of a small regional WISP may try to deploy v6 because they lack v4 space and face customer complaints because they single home behind HE and can't reach the other half of the internet.

Currently v6 is like connecting to the late 90s internet. It dosen't work as well as people think.

Re: AWS Customers Cannot Escape IPv4

#205
post #119

> The first pattern is having multiple Load Balancers (per VPC); this is often the result of using several readily available Cloudformation templates / Terraform modules, or somehow using Kubernetes ingress controllers that create a Load Balancer for every service. This is fixed by not doing that! A single Load Balancer can handle many URLs and services. This is the definition of cloud bloat. The fact there are tons…

I do believe the AWS Load Balancer Controller on Kubernetes allows for sharing a single "physical" load balancer. You have to set a load-balancer-name annotation https://kubernetes-sigs.github.io/aws-load-balancer-controll... to tie everything together to one load balancer. There is a downside where you have to have a few other annotations be the same value across your ingresses, but once you work around that, you're…

I couldn't find it easily specified in docs. This is a common use-case and part of why I avoid EKS for HTTP workloads is that I have tiny services I want to just make available and I don't want to have another full ELB sitting there. It isn't a cost thing primarily. It's that now I have another significant resource. I want all of these things on a misc LB.

Re: AWS Customers Cannot Escape IPv4

#206

Earlier quoted context omitted.

A lot of IT folks are still fearful of IPv6. I've been on calls where people disable IPv6 as a matter of "best practice." It's sad. People will gladly learn the latest flavor of the month web framework but won't take time to gain experience with a fundamental protocol.

Why? What's the (supposed) fear?

Because there's a lot of shit that still doesn't work well with IPv4. Logging is one good example - a lot of software that uses its database for event logs has the database column for remote_ip defined as VARCHAR(15), you can guess the rest of what happens when deploying that with IPv6 enabled.

Re: AWS Customers Cannot Escape IPv4

#207
In my experience the biggest issue for being IPv6 only in AWS is that github still can't IPv6! Tons of software expects to be able to reach out to github for something.

One can use some public NAT64 services, but that's not very reliable for anything serious. https://nat64.xyz/ . AWS chargers arm and leg for NAT gateways traffic, and I don't think it's possible to configure them so that they only intercept traffic to ipv4-only hosts (please let me know if i'm wrong).

Other than this being IPv6-only in AWS works flawlessly and is cheaper (free egress gateways for private networks). As long as you don't care about IPv4 of course - that's given.

Re: AWS Customers Cannot Escape IPv4

#209

Earlier quoted context omitted.

Can you remember what year it was? I’ve got a slight suspicion you were given some bullshit or at least a creative treatment of facts e.g. everything had IPv6 support but FUD-filled network engineers didn’t want to turn it on. Most network devices I’ve encountered were dual-stack way before anyone I knew seemed to care about actually using IPv6 — I always assumed it was added for US government/military requirements.

From memory, the regionalization project ran from approx 2014 to 2015 or 2016. There were also other reasons given, like the amount of internal software that used e.g. IPv4 addresses. Also, AWS likes to have 'lots of small things' instead of one big thing (regions, AZs, cells, two pizza teams, no (official) monorepo) so regionalization was part of that. Another big reason for regionalization, other than IPv4 exhausti…

You're talking about snowfort, and while ip exhaustion was one reason, it's also an isolation/fault tolerance/security thing.

Re: AWS Customers Cannot Escape IPv4

#210

> almost no AWS API can be used from a VPC without public IPv4 addresses Virtually every single application at the company I work at deploys into VPCs without public IPv4 addresses - this seems like a ridiculous claim.

Do they use NAT gateways? These require public IPs.
Post reply on HN