Live data from Hacker News

AWS Customers Cannot Escape IPv4

tty.neveragain.de

251–260 of 316 posts

Re: AWS Customers Cannot Escape IPv4

#251

Earlier quoted context omitted.

It's definitely "best practice" to turn off features you don't need. Who knows, maybe in five years someone will find a bad bug in the implementation of the IPv6 stack, then you'll be glad you decreased your attack surface. Not saying this is what you should do, just a common rationalization.

It's also "best practice" to learn a new, foundational technology (like IPv6) sooner than later, perhaps less than 20 years after it was first available.

Right and what is better way to learn than deploying random features to prod!

Re: AWS Customers Cannot Escape IPv4

#252

Earlier quoted context omitted.

It's simple fear of the unknown. Many folks haven't learned it, so they just turn it off... Ignore it, kick the can down the road.

It's individuals responding to the incentives before them. If something goes wrong because they're using IPv6, it's their fault. If you never upgrade anything until you're forced to, then you can never break anything by upgrading, and you're never seen as a "stuff breaker".

This is it. Having broken stuff by upgrading myself, I can say it does not make you popular. This is especially the case if what the upgrade did was tighten up some bug that it turns hid a bug in your team's code...

Re: AWS Customers Cannot Escape IPv4

#253

Earlier quoted context omitted.

It's also "best practice" to learn a new, foundational technology (like IPv6) sooner than later, perhaps less than 20 years after it was first available.

Right and what is better way to learn than deploying random features to prod!

Did I say they had to deploy it to production? If they deployed it in dev and test environments even a few years ago, they might have some experience deploying it in prod today.

Re: AWS Customers Cannot Escape IPv4

#254
post #104

Many years ago when I was a junior dev at Amazon, there was a massive project internally to split up every internal system into regional versions with limited gateways allowing calls between regions. The reason? We had run out of internal IPv4 addresses. The Principal PM in charge of the "regionalization" effort was asked in a Q&A "why didn't we just switch to IPv6?". Her answer was something along the lines of "The…

I upgraded a P2P networking library recently to add support for IPv6. That was a pure software solution and it required a lot of work. When you have to upgrade hardware as well, I can imagine it would present a massive challenge (especially logistically). You'd have to upgrade ALL the hardware before you even start thinking about the software side of the equation.

Re: AWS Customers Cannot Escape IPv4

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

Yep. Pick your poison. You're either nickle-and-dimed for a "NAT gateway" or overpaying for "VPC endpoints". Often, it's both. I preferred the EC2-classic days, honestly.

Re: AWS Customers Cannot Escape IPv4

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

If you remember the early Internet (the 90's, before NAT took off), you'd realize end-to-end connectivity, globally unique addresses is actually the norm. IPv6 is bringing that back. I remember having public IPv4 on my desktop!

Re: AWS Customers Cannot Escape IPv4

#257
post #35

Earlier quoted context omitted.

Yes, because publicly addressable does not mean publicly accessible. Set the ACLs to deny by default. In the v4 world, one can easily accidentally allow access by inadvertently sending traffic toward the wrong group of colliding addresses or otherwise messing up any of a number of things that ought not to be necessary in the first place.

You need both firewalls and private addresses, of course. Anything else is amateur hour madness.

You don't need private addresses. You may need non-routable addresses, but they do not need to come from a "private" network range.

Re: AWS Customers Cannot Escape IPv4

#258
post #204

Earlier quoted context omitted.

> two IPv6 internets right now, the Cogent side and the Hurricane Electric side Cogent engages in peering spats on IPv4 too; this dynamic is not new with or unique to IPv6, or limited to Cogent/HE. The lesson here is to not go singlehomed under Cogent, not to reject IPv6.

The takeaway here was that you need to be aware of it to make IPv6 work. Again, your average operator of a small regional WISP may try to deploy v6 because they lack v4 space and face customer complaints because they single home behind HE and can't reach the other half of the internet. Currently v6 is like connecting to the late 90s internet. It dosen't work as well as people think.

You need to be aware of it to make v4 work, too. I once saw an issue where a network similar to your example WISP (singlehomed behind HE) was unable to reach a network that was advertising its v4 prefixes NO_EXPORT to HE at a distant IX. Adding a second upstream would have fixed (and indeed, did later fix) the issue. It's been advisable since the early days to have multiple upstreams because of routing table holes created by situations like this. Again, not unique to v6, and the HE/Cogent schism is not the only one (though admittedly it is likely the largest).

Re: AWS Customers Cannot Escape IPv4

#259
post #93

Earlier quoted context omitted.

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.

What? Private networks are defined as networks, that use private address ranges[0]. They are most certainly not AWS "rhetoric". And why are unique MAC addresses a problem? [0] https://en.wikipedia.org/wiki/Private_network

Private address ranges doesn’t make a network private. Firewall does.

If I know the external, publicly addressable IP address of your router (e.g. 135.77.9.106), and no firewall whatsoever, there’s nothing at all preventing me from doing `ip route add 10.0.0.0/8 135.77.9.106`, and voila, I’d have a route to your “private” network.

Using private addresses vs globally unique offers no security benefiy whatsoever.

Re: AWS Customers Cannot Escape IPv4

#260
post #35

Earlier quoted context omitted.

Yes, because publicly addressable does not mean publicly accessible. Set the ACLs to deny by default. In the v4 world, one can easily accidentally allow access by inadvertently sending traffic toward the wrong group of colliding addresses or otherwise messing up any of a number of things that ought not to be necessary in the first place.

You need both firewalls and private addresses, of course. Anything else is amateur hour madness.

> private addresses

Private addresses offer no security benefit whatsoever. If you have no firewall, nothing at all prevents me from doing `ip route add 10.0.0.0/8 your.routers.ip.here`

Post reply on HN