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

91–100 of 316 posts

Re: AWS Customers Cannot Escape IPv4

#91

Post by xnyanta »

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

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.

I see this at work, being within such a customer. People driving these mandates barely understand IPv4, let alone know what IPv6 is. They're software developers after all, not CCIEs.

There's nothing preventing you from having a private network using unique address space that's either blocked from accessing the internet via a firewall on a router or just plain not even routed. You could even use ULA networks with stateless prefix translation to avoid using GUA addressing for your private network.

The sad part is that IPv6 support is abysmal on every cloud so just migrating to it imposes serious limitations as addressed by the blog author.

Re: AWS Customers Cannot Escape IPv4

#92

Post by xnyanta »

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

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.

>norms

More like it gets rid of band-aids

Re: AWS Customers Cannot Escape IPv4

#93

Post by fulafel »

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.

This phrasing is really problematic. Using internet addressing (vs ambiguous addresses) does not make your network "public". Just like using unique MAC addresses doesn't. Confusing global addressing with public reachabiliy is exactly the rhetoric used by AWS, Azure etc to scare people into building mazes of ambiguously addressed 10.x networks.

Re: AWS Customers Cannot Escape IPv4

#94

Post by [deleted] »

jiggawatts wrote: post #53
rewmie wrote: post #38

Earlier quoted context omitted.

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.

[deleted]

Re: AWS Customers Cannot Escape IPv4

#95

Post by ninkendo »

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.

> 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

I don’t know that this is true based on google’s IPv6 adoption data: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

It seems like developing nations have the worst IPv6 adoption, at least by a cursory look of how there’s very little green in Africa, for instance.

I think ISP’s in countries with small IPv4 blocks just use CGNAT.

Re: AWS Customers Cannot Escape IPv4

#96

Post by fulafel »

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?

Was this a jeopardy style reply?

In case not: it's about doing it the wrong way (excess complexity and ambiguity -> hard to understand/analyze/monitor). Using globally addressing is orthogonal to controlling access to your internal services - you can do it using firewalling or various other means. Eg on AWS you get a default-deny firewall.

Re: AWS Customers Cannot Escape IPv4

#97

Post by throw0101c »

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

It's not just AWS. Microsoft, security auditors, penetration testers, cyber insurance companies, etc. also largely insist on not having publicly addressable endpoints. I don't understand why, but until some large tech company starts pushing for end to end addressability as best practice, I have no choice but to follow the conventional wisdom to avoid throwing up red flags.

> Microsoft, security auditors, penetration testers, cyber insurance companies, etc. also largely insist on not having publicly addressable endpoints.

> I don't understand why […]

Excluding Microsoft, all the others find it easier to have as a checkbox to make it easier to confirm that "internal" hosts are actually (theoretically) internal since RFC 1918 isn't allowed outside.

Of course most companies' firewall and NAT rules are probably all sorts of complicated once you get to a certain size (never mind stale open-rules which were never cleaned up), so a bunch stuff is probably accidentally exposed. Also, most attacks are probably from compromised clients nowadays, so even internal hosts need to be locked down as the castle-and-moat security model isn't (as) valid.

But having "internal-only" hosts is low-hanging fruit on the security checklist.

Re: AWS Customers Cannot Escape IPv4

#98

Post by jeroenhd »

betaby wrote: post #90
jeroenhd wrote: post #73

Earlier quoted context omitted.

The EU did have a mandate for government services to use IPv6, but the programme it was part of got replaced by another that didn't include IPv6. The European Commission did advocate for IPv6 use, but, the EU being the EU, motivated their recommendation by complaining that law enforcement had issues tracking down people behind CGNAT, and made clear that they wanted every IP address to point to a specific person for l…

> ISPs can CGNAT for cheap Not really that cheap. While CPAEX is CAPEX, OPEX is still a thing and operating CGNAT requires efforts. Also some (most?) CGNAT implementations are buggy and is not a good user experience, even for users who don't understand the concept of IP at all.

> Also some (most?) CGNAT implementations are buggy and is not a good user experience, even for users who don't understand the concept of IP at all.

They're a pain, especially when you're visiting a website with CAPTCHAs, but the money they save on buying IP space seems to be worth the bad experience from an ISP point of view.

Even here in the Netherlands, with its relatively high wages, a fiber ISP decided to use CGNAT on their new fiber networks as a cost-cutting measure. Luckily, customers can disable CGNAT in their online control panel, but the cost cutting measure seems to be worth the annoyed customers from that company's perspective at least. Of course they also didn't roll out IPv6.

Re: AWS Customers Cannot Escape IPv4

#99

Post by supriyo-biswas »

ninkendo wrote: post #95
supriyo-biswas wrote: post #36

Earlier quoted context omitted.

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.

> 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 I don’t know that this is true based on google’s IPv6 adoption data: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-... It seems like developing nations have the worst IPv6 adoption, at least by a cursory look of how there’s very little green i…

Thank you for the link. I was taking about India for the most part, but it seems France, Germany, India, and Saudi Arabia are the leaders in IPv6 deployment, a weird mix of countries that I honestly didn’t expect.

Re: AWS Customers Cannot Escape IPv4

#100

Post by butlerm »

supriyo-biswas wrote: post #47
bushbaba wrote: post #41

Earlier quoted context omitted.

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…

There are a number of relevant issues here, including the general problem that DNS is not trustable and is not reliable or not reliable enough to use for configuring routers and firewalls. It is not even necessarily accessible or usable for reverse lookup at all. DNS wasn't really designed for common cases where network administrators enter IP address prefixes. That could probably fixed to some degree using a name system that was designed for security use, including operation when the network is partitioned or wildly malfunctioning.

And of course the need to maintain two sets of IP addresses and two sets of IP address prefixes - even and especially in DNS itself - is probably the number one factor slowing down the deployment of IPv6. That and far too many places, far too many interfaces, far too many protocols, and far too many APIs (notably Berkeley sockets) that are not transparent to which network layer protocol is being used or what the address format is. The wire format, transfer format, configuration format, and administration of DNS address records is a case in point.

Post reply on HN