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

51–60 of 316 posts

Re: AWS Customers Cannot Escape IPv4

#51

Post by d-z-m »

jiggawatts wrote: post #29
benterix wrote: post #11

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. 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 out to the "big bad internet" per-say, but it will be routed within the Azure AS as mere IP traffic.

If you have a private endpoint to an Azure service in your virtual network, that means Azure has provisioned you a virtual NIC with some private IP address, and presumably alters DNS resolution within your network for that Azure service to resolve to the IP address of the NIC. The NIC provides (presumably encrypted) link layer transport out to the Azure service.

Compliance for some customers may dictate that there aren't any routes out to the public IP address space from within a network. If you still need access to cloud services, private endpoints are a necessity.

All that to say, I think Private Endpoints provide more than just a means of firewalling traffic/changing the IP address associated with a service; the actual transport from client->cloud service is fundamentally different.

Re: AWS Customers Cannot Escape IPv4

#52

Post by MayeulC »

vasachi wrote: post #32
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

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.

"Private networking" as defined by assigning private-range IP addresses are only private as long as there is no route to your network, or as long as it's isolated on a dedicated vlan (even then, there could be some rogue machines).

In the first case, you need a firewall for IPv4 anyway. In the second case, that would also work with IPv6.

Disclaimer: I know nothing about Azure/AWS internals.

Re: AWS Customers Cannot Escape IPv4

#53

Post by jiggawatts »

rewmie wrote: post #38
jiggawatts wrote: post #31

Earlier quoted context omitted.

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

If you think that either Azure or AWS loop terabits of customer traffic between two of their own services "out to the Internet" and back just because the IPv4 octets don't start with a "10", then you're the one who's missing the big picture.

Re: AWS Customers Cannot Escape IPv4

#54

Post by tyingq »

supriyo-biswas wrote: post #36
peter_retief wrote: post #17

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.

>AWS Lightsail

Read the burst/throttling page carefully before you choose this product.

https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amaz...

Re: AWS Customers Cannot Escape IPv4

#55

Post by ttegloma »

supriyo-biswas wrote: post #48
9dev wrote: post #19

Earlier quoted context omitted.

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.

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 down so that acquiring them is cheaper (or wants people to stop using IPv4 so that they can stop spending money on them altogether).

Re: AWS Customers Cannot Escape IPv4

#57

Post by d-z-m »

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

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

> That's why customers line up to pay for it: to get their traffic flow only through private networks instead of through the wild.

I believe their point is that it doesn't flow through "the wild" in any case, it is probably routing within the Azure AS(aka Microsoft controlled networks). However, as you say, people line up to pay for it, likely for reasons having to do with their architecture/security model/compliance requirements.

Re: AWS Customers Cannot Escape IPv4

#58

Post by kaliszad »

supriyo-biswas wrote: post #48
9dev wrote: post #19

Earlier quoted context omitted.

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.

Have you heard of the Jevons paradox https://en.wikipedia.org/wiki/Jevons_paradox? It is really insightful. If you make something more efficient/ easier to use, people will use more of it. That is exactly what I think about the switch from IPv4 -> IPv6. Networking is really complicated now and if you happen to make it just a bit easier and cheaper, people will use it and the related services more.

Stateful NAT is a real burden on bigger networks and is at least a chore on smaller networks. It at least doubles the complexity of managing a network especially when you have a DMZ that should be used from some "private" and some "public" endpoints.

Re: AWS Customers Cannot Escape IPv4

#59

Post by kaliszad »

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.

Re: AWS Customers Cannot Escape IPv4

#60

Post by apparentorder »

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

ECS, ELB and most other services do not support IPv6-only subnets, as mentioned in the article.

ECS does support dual-stack IPv6, but most other services do not support IPv6 at all.

Post reply on HN