NAT gets the blame, and the intranet as a concept is generally a big corp term.
But I prefer my IoT devices not to need to reach out of my network. For me, NAT is an unwitting ally in the fight against such nonsense.
My university has a public IP for every computer, but you could still only connect to the servers, not random computers, from the outside. Because they had a firewall.
Obviously, those average people have a suitable firewall provided by default on their routers.
NAT/port forwarding, for all their faults make it rather difficult to write rules allowing traffic to a machine you didn't intend to expose to the world.
This is not in any way a benefit of NAT.
Just because NAT accidentally achieves some good outcomes doesn't in any way imply that said good outcomes are somehow exclusive to NAT.
Tailscale doesn't strictly need NAT traversal. They can run only their DERP servers and still continue to work. If your firewall tries to block two devices from communicating and yet allows both devices internet access, you have already lost.
They have all the upsides of NATs (i.e. an option to block inbound connections by default), with none of the downsides (they preserve port numbers, can be implemented statelessly, they greatly simplify cooperative firewall traversal, you can allow inbound connections for some hosts).
I could have all of my servers in public subnets and give them all public IP addresses, but I still prefer to put everything I can in private. Not only does the firewall not allow traffic in, but you can't even route to them. It now becomes really hard to accidentally grant more access than you intended.
I would hazard that most devices on there internet are in the boat of want to talk to the internet but not be reachable on it.
There is a distinction between being publicly addressable and publicly routable. You can have the former without having the latter.
If you want more private addresses, IPv6 has a solution too: use ULAs and not GUAs. Design your internal network so it has mostly ULAs for application servers, database servers and the like, except for the reverse proxy having both publicly accessible GUAs as well as ULAs for talking to the rest of the network.
I personally use ULAs and GUAs concurrently on my network, because I have a residential ISP where my GUA prefix is not fixed.
If it's a well-reasoned decision, sure, but I do suspect that more often than not it's a lack of knowledge about alternatives that makes people still opt for NATs, and that just makes me sad on top of being annoyed with the inconvenience of having to tunnel when a direct connection seems so close at hand.
> I would hazard that most devices on there internet are in the boat of want to talk to the internet but not be reachable on it.
I highly doubt that. One big example is VoIP: Incredibly common these days, yet so much of it is going through centralized relays, and often for absolutely no technical reason.
Being forced into a CGNAT on ipv6 is just a dick move though. And I believe that's the kinda NAT that has coloured the opinions of most NAT for ipv6 detractors.
But to your point about not cheering on NAT, well I will because I see NAT as useful tool.
It is not an opinion well aligned with the preferences of the IETF. But the purist model of transparent end-to-end networking has never sat well with me. It’s just not a thing we want.
Because that's what happens if you advocate for NAT by default. Conversely, with "IPv6 + inbound-blocking-firewall on CPEs by default", everybody gets the same behavior by default, and people that want something else can get that instead.
Security and privacy is of course critical to all this, but the concept of internet itself is not wrong.
Does that VPN use certificates or a pre shared key? Do they understand the different security implications between those two choices?
But theirs uses certificates (the router UI generates the openvpn client config files with the certificate embedded inside it) and no, they do not understand the security implications between those two choices.
Mine is a wireguard VPN with both the pub/priv keypair and PSK.
There's a reason IoT vendors try to do this all "in device."