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…
AWS Customers Cannot Escape IPv4
271–280 of 316 posts
Re: AWS Customers Cannot Escape IPv4
#272Earlier 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.
https://kubernetes.io/docs/concepts/services-networking/ingr...
Re: AWS Customers Cannot Escape IPv4
#273Earlier 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…
Re: AWS Customers Cannot Escape IPv4
#274Earlier 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…
Re: AWS Customers Cannot Escape IPv4
#275Earlier 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…
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
#276Earlier 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.
Pretty sure that's enough time to test it in development...
Re: AWS Customers Cannot Escape IPv4
#277Earlier 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.
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
#278Earlier 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.
Re: AWS Customers Cannot Escape IPv4
#279In 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…
Re: AWS Customers Cannot Escape IPv4
#280Earlier 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.