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.
AWS Customers Cannot Escape IPv4
251–260 of 316 posts
Re: AWS Customers Cannot Escape IPv4
#252Earlier 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".
Re: AWS Customers Cannot Escape IPv4
#253Earlier 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!
Re: AWS Customers Cannot Escape IPv4
#254Many 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…
Re: AWS Customers Cannot Escape IPv4
#255Earlier 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.
Re: AWS Customers Cannot Escape IPv4
#256It 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.
Re: AWS Customers Cannot Escape IPv4
#257Earlier 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.
Re: AWS Customers Cannot Escape IPv4
#258Earlier 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.
Re: AWS Customers Cannot Escape IPv4
#259Earlier 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
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
#260Earlier 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 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`