Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Customers Cannot Escape IPv4

tty.neveragain.de

Post reply on HN
Print view View original

121–130 of 316 posts

Re: AWS Customers Cannot Escape IPv4

#121

Post by vasachi »

fulafel wrote: post #93
vasachi wrote: post #32

Earlier quoted context omitted.

Well, I wouldn't put _any_ service on a public network, unless it is explicitly required. Firewall is all well and good, but security in depth is even better. Private networking is good. IPv6 doesn't help here at all.

This phrasing is really problematic. Using internet addressing (vs ambiguous addresses) does not make your network "public". Just like using unique MAC addresses doesn't. Confusing global addressing with public reachabiliy is exactly the rhetoric used by AWS, Azure etc to scare people into building mazes of ambiguously addressed 10.x networks.

What? Private networks are defined as networks, that use private address ranges[0]. They are most certainly not AWS "rhetoric".

And why are unique MAC addresses a problem?

[0] https://en.wikipedia.org/wiki/Private_network

Re: AWS Customers Cannot Escape IPv4

#122

Post by flerchin »

pmarreck wrote: post #118
mabbo wrote: post #104

Many years ago when I was a junior dev at Amazon, there was a massive project internally to split up every internal system into regional versions with limited gateways allowing calls between regions. The reason? We had run out of internal IPv4 addresses. The Principal PM in charge of the "regionalization" effort was asked in a Q&A "why didn't we just switch to IPv6?". Her answer was something along the lines of "The…

So basically, their IPv4 infrastructure investment is so entrenched that they're trapped. Sounds like a perfect opportunity for a market upstart to start out v6-only...

[flagged]

Re: AWS Customers Cannot Escape IPv4

#123

Post by flerchin »

dopylitty wrote: post #81

As an AWS customer I want to escape IP entirely. It's a waste of time managing these complex networking systems with their archaic protocols (IP, BGP, DNS, etc) Just let me strongly associate identities with my workloads and apply policy indicating which workloads should be able to send data with which other workloads. How data gets from one workload to another should not even be my concern, just make it happen.

IME "big picture folks" suddenly care about the details when their big picture fails to solve for the details.

Re: AWS Customers Cannot Escape IPv4

#124

Post by cduzz »

JackSlateur wrote: post #69
jiggawatts wrote: post #31

Earlier quoted context omitted.

I replied to someone else's similar misconception of what problem Private Link solves here: https://news.ycombinator.com/edit?id=37609614 Hint: it's a complex workaround for insufficient IPv4 addresses.

Private link is a clever way to implement real network segmentation That is, when you have a customer in some network and a provider in another network, you had to implement full connectivity between the customer and the provider With private link, you can remove all that connectivity, and instead expose the provider' service to the customer The service, nothing more, so just one endpoint This is really good from a s…

The IPv6 version of this would be ...

1. get list of customer netblocks

2. setup "internal" service(s) for customers

3. setup firewall rules to allow customer service allow list

4. setup DNS records

5. tell customers DNS and API targets

Re: AWS Customers Cannot Escape IPv4

#125

Post by NoZebra120vClip »

supriyo-biswas wrote: post #110
NoZebra120vClip wrote: post #103

Earlier quoted context omitted.

> the same applies for IPv6: use DNS (or your hosts file). And for reverse DNS, PTR records? What should we use there?

If you're setting up your private DNS resolvers, you can add PTR records to it. There's nothing special about PTR records in IPv6, they're just DNS records for "in6-addr.arpa" instead of "in-addr.arpa".

How many PTR records should you add for the customary 64-bit Interface ID that applies to one device configured with SLAAC?

https://datatracker.ietf.org/doc/html/rfc8501#page-4

Re: AWS Customers Cannot Escape IPv4

#126

Post by Twirrim »

mabbo wrote: post #104

Many years ago when I was a junior dev at Amazon, there was a massive project internally to split up every internal system into regional versions with limited gateways allowing calls between regions. The reason? We had run out of internal IPv4 addresses. The Principal PM in charge of the "regionalization" effort was asked in a Q&A "why didn't we just switch to IPv6?". Her answer was something along the lines of "The…

I remember the regionalisation, that was "fun" to be on the sidelines for (I was in a newer service that was regionalised from the get-go). I don't remember who the PM was for that one, but I remember that being when I truly came to respect the value that a TPM can add.

You're right about the cost and need to replace network equipment being one of the strong reasons why they didn't. Amazon used its own in-house designed and built network gear for a variety of reasons (IIRC there's a re:invent talk about it), which I'm sure is probably still the case. Every single one of those machines had fixed memory capacity and would need to be replaced to bump up the memory sufficiently large enough to handle IPv6 routing table needs etc. What they had wouldn't even be enough if they'd have chosen to go IPv6 Only (which you couldn't get through except via dual stack IPv4/IPv6 anyway).

Re: AWS Customers Cannot Escape IPv4

#127

Post by mr_mitm »

Varriount wrote: post #102
icedchai wrote: post #88

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?

It's definitely "best practice" to turn off features you don't need. Who knows, maybe in five years someone will find a bad bug in the implementation of the IPv6 stack, then you'll be glad you decreased your attack surface.

Not saying this is what you should do, just a common rationalization.

Re: AWS Customers Cannot Escape IPv4

#128

Post by AdamJacobMuller »

mtnGoat wrote: post #112
tinix wrote: post #108

Earlier quoted context omitted.

this doesn't forgo v6 phase-in though, can't kick that can down the road forever. surely they started the process... right? i cannot imagine AWS just sticking head in the ground and ignoring this...

Yes they are working on it. A number of services already support v6, more to come.

1 is a number.

0 is also a number.

Re: AWS Customers Cannot Escape IPv4

#129

Post by Twirrim »

tinix wrote: post #108
mabbo wrote: post #104

Many years ago when I was a junior dev at Amazon, there was a massive project internally to split up every internal system into regional versions with limited gateways allowing calls between regions. The reason? We had run out of internal IPv4 addresses. The Principal PM in charge of the "regionalization" effort was asked in a Q&A "why didn't we just switch to IPv6?". Her answer was something along the lines of "The…

this doesn't forgo v6 phase-in though, can't kick that can down the road forever. surely they started the process... right? i cannot imagine AWS just sticking head in the ground and ignoring this...

No one is ignoring it, and the US Government has done everyone another favour on this score. Years ago in the late Bush / early Obama administration, NIST required that all federal government agencies have IPv6 at the border. Federal government money is not to be sniffed at, and that had the effect of forcing a number of vendors to add IPv6 support. A few years after that, it became that the federal agencies needed to have dual-stack IPv4/IPv6.

About 18 months ago, the requirement came that federal agencies are required to be IPv6 Only, dropping the dual stack. IIRC they have until 2025 to do that. This has the neat effect of forcing all vendors to make IPv6 a first class citizen. The extra little fun from this is that it applies to the military JWCC contract that all the major clouds have been trying to land. The timescales of JWCC meant that initial offerings are pretty bare, but that won't be allowed to last.

Re: AWS Customers Cannot Escape IPv4

#130

Post by Spivak »

mkl95 wrote: 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 think it's an impedance mismatch between the feature people want -- "logical load balancers" and the feature they're offered "physical load balancers."

How nice it would be if you could just create a bunch of load balancers and all that actually meant was that it was just adding config profiles to a single physical load balancer and kept them truly isolated? Right now it's really annoying because load balancer config is global state and everyone has to either be kind neighbors when adding themselves to it or manage them top-down.

Post reply on HN