Live data from Hacker News

AWS Customers Cannot Escape IPv4

tty.neveragain.de

271–280 of 316 posts

Re: AWS Customers Cannot Escape IPv4

#271
post #8

IPv6 is such a massive headache it’s kind of mind boggling. I used to be super enthused - but it is absolutely less useful and more annoying than it’s worth.

This is one example where it's clear IPv6 isn't the problem, actually. A lot of problems with AWS would disappear if they would just support IPv6 like your average budget ISP does. IPv6 just works. Amazon, Github, and Azure don't. That's not really a problem in most cases (very few people go IPv6 only because it's just not necessary with CGNAT, and even then network translation tricks can put up IPv6 IPv4 bridges eas…

Amazon doesn't support DNSSEC on their domains. If you mean that it's possible to DNSSEC-sign a Route53 domain, yes, but AMAZON.COM isn't signed. Very few tech companies have signed their domains; it's a net negative.

Re: AWS Customers Cannot Escape IPv4

#272

Earlier quoted context omitted.

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.

What you need is an Ingress. You can just have one ELB front all of your services if you wish.

https://kubernetes.io/docs/concepts/services-networking/ingr...

Re: AWS Customers Cannot Escape IPv4

#273

Earlier quoted context omitted.

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…

My favorite region isolation oversight was when someone realized that the perl cron job that iterated over every border router globally and applied ACL updates 2-3x per day didn't pay attention to isolation at all, and could easily have just started blackholing the entire network one device at a time if someone configured a bad rule. The mitigation was to sort routers by hostname which began with the regional airport…

Oh wonderful. 15 minutes to get the page, put down my beer, get on my computer, sign in to everything, get 2-factored 3 times AND figure out exactly what’s happening and fix it.

Re: AWS Customers Cannot Escape IPv4

#274
post #241

Earlier quoted context omitted.

This is wrong. Every IPv6 interface has a link-local address (which is not routable outside the LAN) as well as a global address. Global addresses are just addresses that come from a block allocated by the IANA. It has no bearing on whether the interface is reachable from the public internet. Just like with IPv4 networks, a stateful firewall will prevent unsolicited inbound connections.

Why is it wrong? You don't seem to be engaging the parent's point at all, which is that IPv6 addresses are a more specific identifier than current IPv4 addresses. The existence of link-local addressing has no bearing on that argument, because those addresses are non-routable by definition. Nor does stateful firewalling prevent your unique device address from being broadcast over the Internet, you'd need 6-to-6 NAT to…

[flagged]

Re: AWS Customers Cannot Escape IPv4

#275

Earlier quoted context omitted.

I've been listening to a very good IPv6 related podcast with knowledgeable hosts (IPv6 Buzz) and all it's done is convince me that IPv6 is a poorly thought out mistake. Every other episode seems to be about a different new RFC that's replacing another RFC because the original ended up having a bunch of holes and edge cases. That's somewhat understandable for a new protocol but the protocol have been around for almost…

This somehow reminds me of some anti EV (Electric Vehicle) people. They accept ICEVs (Internal Combustion Engine Vehicle) as given and normal (ICEVs just exist, the fuel falls from the sky) but dig really deep into an anti EV mindset. They follow anti EV blogs and podcasts. They will tell you how bad EVs are for the environment, how mutch water and cobalt and what not is used for the production without acknowledging…

There's a nugget of truth in anti-EV comments, namely 1) EVs are in many ways a mediocre solution (EVs will increase batteries etc needed), and 2) pursuing EVs carries an opportunity cost (public transport will reduce emissions far more than EVs and be substantially cheaper than cars as well, and a $1000 EV subsidy could instead be a free ebike).

That said, EVs are mostly better than ICEVs - "mostly" because performance-heavy applications like long-haul trucking and tractors still benefit heavily from fossil fuels, and in most other applications EVs are still more expensive than ICEVs.

Re: AWS Customers Cannot Escape IPv4

#276

Earlier quoted context omitted.

Right and what is better way to learn than deploying random features to prod!

Did I say they had to deploy it to production? If they deployed it in dev and test environments even a few years ago, they might have some experience deploying it in prod today.

It's only been ratified since 1998 and available as far back as Windows NT4

Pretty sure that's enough time to test it in development...

Re: AWS Customers Cannot Escape IPv4

#277

Earlier quoted context omitted.

It's not just AWS. Microsoft, security auditors, penetration testers, cyber insurance companies, etc. also largely insist on not having publicly addressable endpoints. I don't understand why, but until some large tech company starts pushing for end to end addressability as best practice, I have no choice but to follow the conventional wisdom to avoid throwing up red flags.

> I don't understand why I will resist the urge to be snarky at your expense and politely point out that exposing your LAN to public routing tables is madness, from all perspectives. It brings no benefits and carries huge risks.

>exposing your LAN to public routing tables is madness

And I don't understand why people think that.

You are exposing a /64 network. That's 2^64 addresses, no one can scan your LAN if that's what you fear, nor can anyone reach your hosts if you build a stateful firewall that denies incoming connections - you know, just like NAT. But minus the packet modifications.

Re: AWS Customers Cannot Escape IPv4

#278

Earlier quoted context omitted.

It's not just AWS. Microsoft, security auditors, penetration testers, cyber insurance companies, etc. also largely insist on not having publicly addressable endpoints. I don't understand why, but until some large tech company starts pushing for end to end addressability as best practice, I have no choice but to follow the conventional wisdom to avoid throwing up red flags.

> I don't understand why I will resist the urge to be snarky at your expense and politely point out that exposing your LAN to public routing tables is madness, from all perspectives. It brings no benefits and carries huge risks.

Using global addresses is not, of course, "exposing your LAN to public routing tables", or any charitable interpretation thereof. Reachability != addressing.

Re: AWS Customers Cannot Escape IPv4

#279

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…

If you have a dual stack network in AWS, wouldn’t it prefer IPv6 from DNS but IPv4 would still work? This is how I have most of my things that need general internet egress configured

Re: AWS Customers Cannot Escape IPv4

#280

Earlier quoted context omitted.

If you're not using token ring, it's not a real network.

I read that as "Tolkien ring" - which would also be appropriate, since "...and in the darkness bind them" is a good summary of cloud vendor lock-in.

"Nine /8's were gifted to the race of cloud providers, who above all else, desire power"
Post reply on HN