Live data from Hacker News

AWS Customers Cannot Escape IPv4

tty.neveragain.de

31–40 of 316 posts

Re: AWS Customers Cannot Escape IPv4

#31
post #18

Earlier quoted context omitted.

Azure is copying this wholesale. I've lost track of all of the "Private Endpoints", "Private Links", "Service Endpoints", "Private Resolvers" and "Virtual WAN" products they've introduced... all to make IPv4 work at scale. Literally none of those products would be required if they had just made IPv6 work properly. Instead, they NAT IPv6, so you can't even use it to avoid the NAT forced upon you by IPv4. They also rel…

> I've lost track of all of the "Private Endpoints", "Private Links", "Service Endpoints", "Private Resolvers" and "Virtual WAN" products they've introduced... all to make IPv4 work at scale. I'm not sure what you've been reading, but the concept of a private link has absolutely nothing to do with IPv4 vs IPv6. In fact, practically all your remarks don't involve the issue at all. The most charitable interpretation of…

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.

Re: AWS Customers Cannot Escape IPv4

#32
post #13
post #6

Earlier quoted context omitted.

I work in Azure, but my experience is that customers want this - and for good reason. Customers want their own private network to prevent intrusions and exfiltrations, just on machines they don’t own. Or even better, put the nice fancy batteries included PaaS services in these networks too.

Right, cause customers are too stupid to manage their own IPv6 firewalls, it's for their own good! /s

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.

Re: AWS Customers Cannot Escape IPv4

#33
post #21
post #16

Earlier quoted context omitted.

> These provide a strong lock-in effect when customers spend effort to build the complex infrastructure for them in the name of security, even though in reality they hurt security through unnecessary complexity, addressing ambiguity, etc. How do you hurt security by preventing external access to your internal services?

By making it necessary to use automated tooling and even obtain certifications just to set up everything required for private networking. The complexity of a properly configured service mesh in AWS is staggering, extremely hard for newbies to get right, and easy to fuck up big time down the road. That hurts security.

Are hundreds of publicly addressable services better?

Re: AWS Customers Cannot Escape IPv4

#34
post #13

Earlier quoted context omitted.

Right, cause customers are too stupid to manage their own IPv6 firewalls, it's for their own good! /s

I work with Fortune 50s in cloud, and they can barely manage ipv4. If you're in a digital native it's different, but in my experience most behemoths do not inspire confidence with how on top of their network infrastructure they are.

This is a bit like saying “customers can barely manage driving a stick shift with a manual choke — we shouldn’t let them drive automatics!”

IPv6 isn’t amazing, but it makes many of these problems simply disappear. Of course [0] networks should be isolated, but this should be achieved with a firewall that, by default, disallows connections between the public Internet and private networks. And that’s about it — every VM has a globally unique address, routing just works, one company (if permitted) can connect to another company’s endpoints, firewalls can be deployed where they make sense instead of being forced to exist exactly where inconsistently-addressed networks meet, etc.

The entire mess of designing and negotiating allocation of extremely limited IPv4 addresses for private systems simply disappears!

[0] Beyond corp has something to say about this.

Re: AWS Customers Cannot Escape IPv4

#35
post #33
post #21

Earlier quoted context omitted.

By making it necessary to use automated tooling and even obtain certifications just to set up everything required for private networking. The complexity of a properly configured service mesh in AWS is staggering, extremely hard for newbies to get right, and easy to fuck up big time down the road. That hurts security.

Are hundreds of publicly addressable services better?

Yes, because publicly addressable does not mean publicly accessible. Set the ACLs to deny by default.

In the v4 world, one can easily accidentally allow access by inadvertently sending traffic toward the wrong group of colliding addresses or otherwise messing up any of a number of things that ought not to be necessary in the first place.

Re: AWS Customers Cannot Escape IPv4

#36

I am struggling to move to IPv6, from ISP blocking to unhelpful cloud services. Who is a good provider of ipv6?

At the ISP level, you have better chances of having IPv6 connectivity if you’re based out of a developing country, whose ISPs don’t have the means to pay for too many IPv4 ranges.

For servers, there are plenty; AWS Lightsail, Hetzner and Vultr both provide IPv6 out of the box. If you don’t have an ISP which provides IPv6, you could use a server and set up a wireguard tunnel for IPv6 connectivity.

Re: AWS Customers Cannot Escape IPv4

#37

Off topic: Does anyone know if this page is generated from a Static-Site generator starting from Markdown? I currently use Hugo and my blog is in Markdown in git, but the theme is pretty heavy-weight, and I like this look of the page in OP; Looking at the source, it's so minimal!

Yes, it's Markdown and I use https://jekyllrb.com with the theme "jekyll-theme-hacker" to generate the site. I quite like how simple it is.

Re: AWS Customers Cannot Escape IPv4

#38
post #18

Earlier quoted context omitted.

> I've lost track of all of the "Private Endpoints", "Private Links", "Service Endpoints", "Private Resolvers" and "Virtual WAN" products they've introduced... all to make IPv4 work at scale. I'm not sure what you've been reading, but the concept of a private link has absolutely nothing to do with IPv4 vs IPv6. In fact, practically all your remarks don't involve the issue at all. The most charitable interpretation of…

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.

I think your comment shows a high dose of ignorance and complete lack of research on the topic. The whole point of private link is to not route traffic over the internet, and instead flow traffic between private networks through private pipes.

One of the primary usecases and design requirements for this service is regulatory compliance. They say right on the tin that the service is designed to send traffic over private networks, including AWS's own global network. The whole point of private link is to ship data through the pipes you own, instead of routing it through the wild. I don't know how you could have missed that.

More importantly, you really need to want to use private link connections. This is a value-added service. You need to want to go out of your way to avoid your traffic to go through the internet to onboard both ends of your services to private link.

Not only are your conspiratorial hypothesis completely out of base, even your baseless assumptions have absolutely no relation with what version of the IP protocol is in place.

I'm the first to join in on any good old fashioned AWS/big cloud provider bashing, but these should be grounded on reality.

Re: AWS Customers Cannot Escape IPv4

#39

Earlier quoted context omitted.

Wait a second. A private link means that a service endpoint is public so a part of your traffic goes through the Internet, which is supposed to be insecure (even if you have encryption in transit?), so you don't want to do that and they will happily route your traffic internally so it is not exposed to the bad Internet - for a fee. All these VPC Endpoints etc. cost money and you are charged by the our. I don't think…

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…

What a shit show. Seriously I can never rant enough about how awful Azure networking and their bullshit concepts is. Like they don’t know how to do networking, so they’re gonna introduce a bunch of shit and pretend that nonesense makes perfect sense because of their own ineptitude.
Post reply on HN