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

21–30 of 316 posts

Re: AWS Customers Cannot Escape IPv4

#21

Post by 9dev »

rewmie wrote: post #16
fulafel wrote: 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…

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

Re: AWS Customers Cannot Escape IPv4

#22

Post by mike_d »

pnpnp wrote: post #2

AWS has a way to go with their IPV6 services, but IPV6-only is very doable right now in EC2. I have a WireGuard server that was dual-stack. I turned off IPV4 to see what would happen, and it kept chugging along very nicely.

...if you are running one service and not really using AWS in any meaningful way other than as a VPS provider.

Re: AWS Customers Cannot Escape IPv4

#23

Post by 9dev »

donor20 wrote: post #8

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.

It’s really not a headache in and of itself. The technology is beautiful and enables lots of cool things - just look at all the awesome stuff the fly.io team makes it do.

The headache are vendors that still refuse to properly implement IPv6, in 2023.

Re: AWS Customers Cannot Escape IPv4

#24

Post by thebytefairy »

jojobas wrote: post #13
beoberha wrote: 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

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.

Re: AWS Customers Cannot Escape IPv4

#25

Post by alias_neo »

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!

Re: AWS Customers Cannot Escape IPv4

#26

Post by 1ncorrect »

gnopgnip wrote: post #5
mjevans wrote: post #3

It would really help if there were real ISP competition in the USA. There's only one actually broadband ISP provider where I rent, which is in the suburbs near Seattle. It's NOT a rural area by any definition, and yet Comcast is my only option. Their price and service reflect that reality...

Comcast supports ipv6 though, in 2016 they hit 98% ipv6 support.

And Comcast were the biggest proponents of building IPv6 support into the DOCSIS specs, because they exhausted 10/8 in the management network for their modem fleet.

Re: AWS Customers Cannot Escape IPv4

#27

Post by mike_d »

mjevans wrote: post #3

It would really help if there were real ISP competition in the USA. There's only one actually broadband ISP provider where I rent, which is in the suburbs near Seattle. It's NOT a rural area by any definition, and yet Comcast is my only option. Their price and service reflect that reality...

IPv6 adoption is only going to further the consolidation of customers onto the big monopoly providers. They will be the only ones who can afford to add the dedicated network engineering staff to make it work reliably.

Most people don't realize there are two IPv6 internets right now, the Cogent side and the Hurricane Electric side. Both are equally sized and refuse to connect to each other, so you need to know that and either buy transit from both or buy transit from a network that buys from both. At least one major provider I know of is still running v6 over tunnels. In many places your v6 traffic is taking suboptimal routes, whereas an enterprise network may have v4 connectivity at each datacenter, v6 all gets sent to that one box under Dave's desk.

But we continue to measure v6 adoption at places like Google and Cloudflare where dedicated teams make sure packets arrive and pat ourselves on the back.

Re: AWS Customers Cannot Escape IPv4

#28

Post by devoutsalsa »

jiggawatts wrote: post #7
fulafel wrote: 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…

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…

If you're not using token ring, it's not a real network.

Re: AWS Customers Cannot Escape IPv4

#29

Post by jiggawatts »

benterix wrote: post #11
jiggawatts wrote: post #7

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…

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 of the IP address, making it a "fat IP address" that is unique within Azure and can be used in firewall rules.

Private Endpoint: Makes a PaaS service appear on a private network address range instead of the default public range. This allows your on-prem firewalls to isolate your specific PaaS instance from other customers -- otherwise the traffic gets "blended in" with everyone else in the same public service tag ranges. This also allows you to use your ExpressRoute fibre links to route traffic from on-prem to the public service.

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.

Fundamentally, all this exists just to enable the ability to firewall things. With overlapping IPv4 addresses and small shared blocks of IPv4 addresses with NAT behind them, it would be impossible otherwise.

With IPv6, using firewalls would be much simpler because overlapping addresses aren't needed any more. Similarly, PaaS services could trivially allocate IPv6 addresses per customer instance, so that customers could apply selective firewall rules.

Re: AWS Customers Cannot Escape IPv4

#30

Post by lloeki »

thaumasiotes wrote: post #15
jiggawatts wrote: post #7

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…

Comcast at some point stopped letting you administrate your own router. You can log in to it, but port forwarding is no longer available through the administration interface. If you want port forwarding, they recommend that you do... something. It's not clear what; what you can find on the internet is mostly just people complaining that they insisted to customer support that they needed port forwarding, customer supp…

> port forwarding is no longer available through the administration interface.

Sounds like the CGNAT experience, possibly blanket applied even if you have a globally routable public IPv4 in order to have consistent behaviour and reduce network management / support case complexity.

Post reply on HN