Live data from Hacker News

AWS Customers Cannot Escape IPv4

tty.neveragain.de

41–50 of 316 posts

Re: AWS Customers Cannot Escape IPv4

#41
post #4

It seems obviously against AWS incentives to offer working v6 - all their influencing tools ("well architected" criteria, certificates) strongly herd you towards building mazes of ambigously addressed 10.x RFC1918 networks, and not internet style architectures with end-to-end addressing. In the world of their recommendations, even the concept of a "public ip address" is a red flag, and AWS even recommends (for an add…

Maybe just maybe. Customers don’t really want IPv6 but are forced onto it. Ipv6 is not human usable and gets rid of a bunch of network design norms.

Re: AWS Customers Cannot Escape IPv4

#42
post #32
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

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.

The easiest firewall in the world is one that is set up to deny all traffic from all sources. Which is how any decent firewall is configured by default anyway.

I'm not saying that running a private network doesn't provide genuine security value, only that it drastically complicates your networking architecture for very little security benefit. Organizations can decide whether that trade-off is worth it, for organizations with deep threat models like militaries and banks, it's probably worth it. For 99% of the private sector, it's folly.

Re: AWS Customers Cannot Escape IPv4

#43
IMO services like Lambda and S3 not supporting IPv6 is the real issue, and AWS shouldn’t have made the pricing change without first making them dual-stacked, accessible over IPv6.

(Technically S3 does have a separate dual stack endpoint, however it doesn’t really help as I have to change application configuration anyway to deal with this change.)

Re: AWS Customers Cannot Escape IPv4

#44
post #12

Half the reason AWS has leading IPv6 support in the first place is due to mandates from the US government to start migrating. Author is correct that, from a cost perspective, the new costs are immaterial to large customers, but I wouldn't discount the power of policy mandates from the largest customers, where the threat of building an in-house alternative to comply with policy might be sufficient to force AWS to fina…

Indeed. I really don't like the thought, but I more and more believe that there is no other way to incentivize IPv6 at the "server side". The client (end user) side seems to do well, considering that Google reports IPv6 end user traffic of almost 50% these days.

Re: AWS Customers Cannot Escape IPv4

#45
post #14

There needs to be a body of law relating to technical matters like this (and interoperability etc) that is adjacent to competition law. Some things we just need everyone to be on the same page about. It is manifestly the case that ipv6 is never going to be that, because the incentives to invest simply don't exist for companies like AWS. This distorts the market in eyeball networks and hosting - the former are under l…

Lots of AWS customers want IPv4 because that's what they know, and that's what they benefit from.

To me, the question is: what stops me today from spinning up an IPv6-only website and having 99% of the world's browsers use it? If the answer is "nothing", then AWS shouldn't be forced to offer IPv6 (or only IPv6) - IPv4 is just part of what they offer customers. If the answer is "these 7 things" then those 7 things need to be fixed[0] before we pay civil servants to try and force companies to do things that they barely understand.

[0] E.g. in the UK, it's some of the big ISPs that don't do IPv6, so there's no point forcing someone way upstream (and way more optional) in the process to do something https://www.ispreview.co.uk/index.php/2021/11/update-on-ipv6...

Re: AWS Customers Cannot Escape IPv4

#46

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…

> In all scenarios, the traffic goes over Azure networks and/or Microsoft's private backbone.

That's the whole selling point of private links. How could you possibly missed that? That's exactly why companies onboard onto the service. They say exactly this exactly on the marketing brochure. That's why customers line up to pay for it: to get their traffic flow only through private networks instead of through the wild.

What kind of confusion reigns in your mind to come to the conclusion this was some obscure conspiratorial gotcha?

It boggles the mind how you felt the need to come up with absurd conspiracies involving IPv4 to arrive at a claim that the marketing pamphlets show front and center as their whole reason of existence: avoid traffic to go through the internet, and instead pay extra to go through private pipes they own.

It's as if the name actually means something!

Re: AWS Customers Cannot Escape IPv4

#47
post #4

It seems obviously against AWS incentives to offer working v6 - all their influencing tools ("well architected" criteria, certificates) strongly herd you towards building mazes of ambigously addressed 10.x RFC1918 networks, and not internet style architectures with end-to-end addressing. In the world of their recommendations, even the concept of a "public ip address" is a red flag, and AWS even recommends (for an add…

Maybe just maybe. Customers don’t really want IPv6 but are forced onto it. Ipv6 is not human usable and gets rid of a bunch of network design norms.

This “human usable” argument gets trotted out so much on here and elsewhere, but the same people would be surprised to know about HTTP/2, TLS and the like, which by that definition, isn’t human usable either because of binary formats and encryption.

People never interact with these protocols directly and use a layer of indirection such as a HTTP/2 client for HTTP, and the same applies for IPv6: use DNS (or your hosts file).

Re: AWS Customers Cannot Escape IPv4

#48
post #19
post #9

Earlier quoted context omitted.

I'm not convinced these 2 are related. If AWS wanted, they could start promoting IPv6 as a panacea to all internal network problems (if they had it working, that is), and the competition would have a hard time catching up. My guess is the reason is more mundane: supporting IPv4 is just easier, especially if you take into account the number of their services.

While this is probably exactly the spin the AWS sales team head in mind, it conveniently glosses over all the IPv4 related products customers won’t need anymore if they use IPv6, and thus pay a lot less for their simplified network infrastructure. AWS has no incentive to support IPv6 from a sales perspective.

In addition, IPv4 addresses are an asset that has monetary value; and there’s no reason AWS would want to drive down the value of the asset by helping customers migrate to IPv6.

Re: AWS Customers Cannot Escape IPv4

#49
There's one viable solution to be able to run IPv6 only subnets in AWS, their (or your own) NAT gateways support v6->v4 NAT. So it allows you to create large IPv6 only subnets for your compute services (ec2, ecs, k8s, elb, all supports that), allowing your containers to scale without worrying about IP addresses. Then you use dual stack subnets for other AWS services that may not support IPv6 and your compute services can access them through the NAT gateway.

Re: AWS Customers Cannot Escape IPv4

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

> By making it necessary to use automated tooling

It isn't.

> and even obtain certifications

No, not really.

> just to set up everything required for private networking.

Frankly, no.

I'm tempted to agree only in one aspect, which is apparently you are completely unfamiliar with the topic, and the degree of confusion you are showing in your comments suggest you would benefit from an introductory course on the topic, or in the very lease a 5-minute read through the service's documentation.

Certification wold only help because you would need to learn the basics to pass those, and learning the basics would be enough to prevent you to fill in the gaps in your understanding with fabricated nonsense.

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

People being way over their head because they can't even grasp a FAQ will definitely hurt security, but the root cause of this failure mode is sheer incompetence.

As the saying goes, poor craftsman blame their tools, and here you are with a tool-blaming fest.

Post reply on HN