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

61–70 of 316 posts

Re: AWS Customers Cannot Escape IPv4

#61

Post by anyoneamous »

devoutsalsa wrote: post #28
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…

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

I read that as "Tolkien ring" - which would also be appropriate, since "...and in the darkness bind them" is a good summary of cloud vendor lock-in.

Re: AWS Customers Cannot Escape IPv4

#63

Post by pantalaimon »

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…

It's almost as if those big cloud providers want to prevent a transition to IPv6 as relying on IPv4 will solidify their oligopoly.

Any new competitor would have to cough up a huge upfront cost for IPv4 addresses, if they could even get them at that scale.

Re: AWS Customers Cannot Escape IPv4

#64

Post by pantalaimon »

rad_gruchalski wrote: post #20
jojobas wrote: 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’m pretty confident that this statement is mostly true without sarcasm, and that you are in the minority.

How is managing a NAT easier than managing a firewall?

Re: AWS Customers Cannot Escape IPv4

#65

Post by jen20 »

ttegloma wrote: post #55
supriyo-biswas wrote: post #48

Earlier quoted context omitted.

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.

Sure there is. AWS has a vested interest in the value of IPv4 going down as much as possible. Owning IPv4 addresses is a requirement of AWS’s core business. Unless people stop using IPv4, then AWS cannot sell those addresses. There is no incentive for the addresses to increase in value. Further, if people continue to use IPv4, then AWS has to continue to acquire even more IPv4, and AWS wants the price of those to go…

> Unless people stop using IPv4, then AWS cannot sell those addresses. There is no incentive for the addresses to increase in value.

But if people stop using IPv4, the asset (billions of dollars by some accounts) becomes worthless... AWS are passing on the cost for public IPv4 addresses now, so there's even less incentive.

Re: AWS Customers Cannot Escape IPv4

#66

Post by jiggawatts »

eddythompson80 wrote: post #39
jiggawatts wrote: post #29

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…

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.

Most of the complexity is a side-effect of having to do IPv4 far past the scale where the ~17 million private addresses might be sufficient.

Re: AWS Customers Cannot Escape IPv4

#67

Post by iopq »

kaliszad wrote: post #59
iopq wrote: post #40

I migrate my proxy's IPv4 address from time to time to avoid blocks This is not so easy to do with a IPv6 address, AWS tends to want to keep it the same

If you get a /48 you can probably evade the problem by assigning a /64 for your proxy at a time. You will have another ~65,500 such blocks for use. Yes, some might just block the /56 (you would still have another ~250 chances) or /48 but nothing is perfect.

but how do I change the IPv6 address in AWS? I can just assign a new Static IP for IPv4

Re: AWS Customers Cannot Escape IPv4

#68

Post by huijzer »

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 is my only option

Maybe Starlink is another option. It has some drawbacks like reduced performance during heavy rain, but I've seen some positive reviews as well.

Re: AWS Customers Cannot Escape IPv4

#69

Post by JackSlateur »

jiggawatts wrote: post #31
rewmie wrote: 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.

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 security point of view, but also for managing your stuff (especially if there are multiple teams in the compagny): because you now have a resource, you can easily list the services you expose to other people, and whom are your customers

Re: AWS Customers Cannot Escape IPv4

#70

Post by jeroenhd »

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.

This is one example where it's clear IPv6 isn't the problem, actually. A lot of problems with AWS would disappear if they would just support IPv6 like your average budget ISP does.

IPv6 just works. Amazon, Github, and Azure don't. That's not really a problem in most cases (very few people go IPv6 only because it's just not necessary with CGNAT, and even then network translation tricks can put up IPv6IPv4 bridges easily). In Amazon's case, they don't even need to bother setting up a real network, they could abuse an fd00::/8 network to mimic their 10.0.0.0/8 network if they wanted to.

Amazon is terrible at implementing modern standards. Just look at how long it took them to support DNSSEC on their domains, and even that didn't exactly roll out great the first time.

Post reply on HN