When you're using a private network v4 address exhaustion doesn't matter much and the simplicity of only 4 octets helps with IP memorability and simplicity. I would still prefer a v6 option though, as keeping private networks on v4 might be contributing to the slow adoption of v6.
Life sure would be easier if "cloud native" meant IPv6-only (except the load balancer) with non-overlapping unique addresses everywhere. 10/8 doesn't go far if you give each VM a /24 and each k8s cluster a /16.
Wow. In France, home ISP give you a /64 generally (Free for example, known for Online/Scaleway).
I think 80 % of their fiber deployments comes with IPv6 enabled now. And in few years, it should be 100 %.
As a (former) network security guy, I shudder at the thought that you WANT to expose your internal routing details. That's a recipe for security disaster.
It is also an administration problem - you've given out an internal IP network to someone else -- and now your ability to move it to a different IP address for whatever reason depends on the change processes at the other enterprise, which can take months -- or on the ability of your own network infrastructure to NAT it to the new location.
It tends to work much better all around if you have a well defined "external" interface, that gets properly monitored and filtered with a network/app firewall, and gets routed to the right server -- and then internal change for your organization are decoupled from change processes in the others.
And for that, v4 exhaustion really doesn't matter.
I don't get this. IPv4's address space is so small I can trivially scan any internal network, and there are a ton of ways to gather that data covertly from behind the firewall via maliciously crafted web pages or apps, abuse of any number of P2P apps or protocols (VoIP, video chat, WebRTC, etc.), and so on. IPv6 actually makes scanning harder since the address space is massive. E.g. if I have a /64 routed internally I have to scan 2^64 addresses to find internal hosts!
If knowing internal IP addresses is a security risk, then IMHO you have serious security problems. I used to do netsec too and the cornerstone was internal scans for unpatched or rogue systems and services and keeping systems patched and locked down. A network is only as secure as what is connected to it! We also had smart switches and APs where you could lock port to MAC and IP and thus could prevent rogues.
My personal rule was: any system that would not be safe to directly connect to the Internet without a firewall is insecure and needs to be fixed. The only exception is backplanes for things like internal databases/services or testing/dev, and those were separate networks for that purpose only. Separation was either physical or virtual/cryptographic. Back then we didn't have stuff like ZeroTier so we did that with IPSec and it was ugly, but we did it. Those nets could sometimes access the Internet (with restrictions) but could not even see the controlled internal LAN. They accessed the net via a port to outside the DMZ.
Next up was auditing software installed on internal systems. Next up was monitoring network traffic to detect anomalous activity. Firewalls are always the last line of defense. NAT is not a security feature at all.
I never once worried about keeping internal IPs secret (why?) and we ran IPv6 internally without NAT because IPv6 NAT is dumb.
We had two incidents when I was there. Both were the result of phishing to get malware onto personal PCs or phones.
My very strong personal opinion is that security people worry about the wrong things. They worry about network security and firewalls when what should really terrify them is phishing, auto-updating software made by who-knows-who, popular apps and SaaS services that are invisible security dumpster fires (Zoom anyone?), and of course barbarous demonic evocations like "npm install ...". Your firewall will do very little to save you from any of that, and NAT won't do crap because once again NAT is not a security feature.
Obscurity is NOT security. But obscurity as one layer in a larger defense-in-depth setup IS helpful.
Do note that scanning IPv4 through a fishing page is still about a million times harder (literally) than targeting a known address.
And NAT is not security, but in some context is still helpful as one layer in a defense-in-depth setup - you can’t directly attack something that’s not routable.
Security is not binary; there are costs and there are benefits to various setups. My point was that the benefits provided by being able to provide an internal IPv6 address to an external entity are dwarfed by both Netsec and netadmin costs.
Also, if you can so easily scan my internal network with malicious web pages, you can probably passively listen for the v6 addresses. On the networks I managed, browsing happened through VNC to a browser on tightly controlled host that could only connect outside and only through a proxy. How do your fishing pages counter this?
My approach is and was always edge-first. Security begins at connected devices; everything else is an afterthought. The only time you try to secure something primarily at the network level rather than the device level is when it's legacy junk you can't secure otherwise and that you must use.
I am not opposed to network firewalls and such, but they're just defense in depth. If the whole network wouldn't remain secure if it were connected to the Internet with no firewall, it's not secure.
Given that these things are afterthoughts, I am not willing to prioritize them much over efficiency, complexity reduction, and user experience. Afterthoughts should be sacrificed to complexity reduction because complexity negatively impacts security a lot more. Inefficiency and poor UI/UX also have security implications. They increase the amount of "shadow IT" type activity and also seem to make phishing easier. If you secure something in ways that prevent people from getting their work done, they will get their work done insecurely.
Treating NAT as a must-have or should-have rather than the ugly hack you don't want to have increases complexity and negatively harms UI/UX by making P2P stuff not work and making people have to work harder to do simple things. If removing NAT makes you insecure, you were insecure to begin with.
Needless to say I am a fan of the BeyondCorp/deperimeterization approach. Ideally physical networks should be dumb pipes and everything should be virtual. The LAN itself is legacy baggage.