Live data from Hacker News

AWS Customers Cannot Escape IPv4

tty.neveragain.de

161–170 of 316 posts

Re: AWS Customers Cannot Escape IPv4

#161

Earlier quoted context omitted.

Why? What's the (supposed) fear? Disclaimer: I have never worked for Amazon but I can add some input from the assorted medium to large companies I have been employed with. I won't mention any names. This is for someone I know reads my comments wink wink I am not justifying it, just adding some of the bits I experienced. There are many security devices that do not have the same capabilities on IPv6 as IPv4 yet. Some e…

The biggest issue is IPv6 is a privacy, wide open wild west, there is no privacy on IPv6. Every device's IP is literally public, on the public Internet, 24/7. All so called privacy extensions or improvements do not change the lack of privacy of IPv6 and one more thing, the address structure sucks.

IP-based "privacy" is an illusion. With IPv4, your public IP (NAT router IP address) may not change for months, years, and possibly not until your change your router/MAC address. With IPv6 privacy extensions, your address changes regularly. This seems like an improvement.

Re: AWS Customers Cannot Escape IPv4

#162

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.

While your sentiment is valid, this is the type of argument people make on low code solutions. Which has never worked in reality and never will. There's just too much nuance and detail that needs to be considered when you have to do and optimize real workloads.

Of course but it pushes the abstraction forward to what we really want. It turns out that most applications don't actually want to mess with IP except as an implementation detail and optimization. Which is why most of the time you don't and you just get some application layer HTTP payload, RPC thing or WSGIish type call on the incoming side and let the ops people deal with the networking bits and it works well enough that people mostly don't complain. The request is that more outgoing services adopt this model where you had it off to your application server and it does the work and just gives you the data you want back.

I don't think it's that crazy, it's just formally standardizing where we're already going.

Re: AWS Customers Cannot Escape IPv4

#163

Earlier quoted context omitted.

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.

It's also "best practice" to learn a new, foundational technology (like IPv6) sooner than later, perhaps less than 20 years after it was first available.

Re: AWS Customers Cannot Escape IPv4

#164
post #51

Earlier quoted context omitted.

That's what I thought at first, but that's not quite right. Service Endpoint: Allows a PaaS service (that itself uses public addresses) have firewall rules for overlapping private vnet addresses. E.g.: You can have have two VMs both on 10.0.0.123 addresses (in separate VNets) using individual "Allow" rules to the target service. Essentially Azure tags the traffic at the VXLAN level with the source network ID on top o…

> In all scenarios, the traffic goes over Azure networks and/or Microsoft's private backbone. You have to go out of your way to route traffic "via the Internet". Remember: Network addresses are just numbers! Routing rules determine how they flow, and public addresses can be used on private networks. My understanding is that if you don't have a private endpoint, your traffic to an Azure cloud service won't be routed o…

You’re exactly right that the main point of private endpoints is to allow customers who aren’t allowed to open firewalls to public internet to still connect to their public services like Azure Storage, Key Vault, or SQL

Re: AWS Customers Cannot Escape IPv4

#165

Earlier quoted context omitted.

Why? What's the (supposed) fear? Disclaimer: I have never worked for Amazon but I can add some input from the assorted medium to large companies I have been employed with. I won't mention any names. This is for someone I know reads my comments wink wink I am not justifying it, just adding some of the bits I experienced. There are many security devices that do not have the same capabilities on IPv6 as IPv4 yet. Some e…

The biggest issue is IPv6 is a privacy, wide open wild west, there is no privacy on IPv6. Every device's IP is literally public, on the public Internet, 24/7. All so called privacy extensions or improvements do not change the lack of privacy of IPv6 and one more thing, the address structure sucks.

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.

Re: AWS Customers Cannot Escape IPv4

#166

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…

Tell me more about these "pizza teams".

Re: AWS Customers Cannot Escape IPv4

#167
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…

Even cheap consumer hardware supports ipv6. There are significant financial incentives to continue the capitalism of ipv4 addresses. Like NFT's - an artificially limited capital. To create more addresses means more competition, loss of capital. Therefore they will spend billions on continually reworking internal IPV4 than going for the proper solution.

You obviously have never been on the backend of a big enterprise deployment.

The world is bigger than your apartment.

Re: AWS Customers Cannot Escape IPv4

#168
One major weirdness with ipv6 is that it occasionally works with ipv4 and it's unclear why.

Example: we run a bunch of endpoints on ipv4, but get ipv6 IPs in our logs. How? Are there 6-to-4 translators out there at ISP edges?

Unknowns in networking are bad.

Re: AWS Customers Cannot Escape IPv4

#169
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...

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 t…

Yep.

I work a federal entity tied to DoE and that's the biggest workstream cut out for us. 90% of our environment is either dual stacked or IPv6 native. We would love to kick IPv4 out under us and go full IPv6. Problem is that the vendors who are largely private don't have the same mandate so there's varying degree of "we support IPv6" which makes planning bit more difficult (especially at the discovery stage).

Re: AWS Customers Cannot Escape IPv4

#170
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…

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.

Right?? How old of a device you would have to get to NOT have IPv6 support?

EDIT: But maybe bugs, IDK.

Post reply on HN