> I had to downvote you for conflating NAT with security.

I specifically didn't.

I said that nobody sane connects to the internet without a firewall. That firewall will of course be default-drop because otherwise why bother.

With that firewall in place, nodes on the outside of the firewall cannot talk to nodes on the inside without some configuration. So the fact that the nodes share an address space is moot.

My point was that punching a hole in that firewall requires a similar effort or solution that adding a NAT rule does.

The difference is that you can give an IP to a device semi-permanently and you can route to it directly if needed. This allows you to configure a firewall in your device specifically, rather than having to orchestrate with the router. For instance, you can give your laptop an IP and your partner's laptop another IP and you can just route everything to those two specific devices, which you know is handled properly by two responsible people. I agree with the point that you probably want to be more restrictive in the router level when you connect your fridge, printer, etc.

Moreover, the router is a lot simpler as it doesn't need to keep track of connections, which works well with TCP, but not necessarily with UDP. So, you can actually use other protocols other than TCP easily too. The only downside of IPv6 is that it is not backwards compatible, but being able to identify devices uniquely has no down sides.

You don't just need configuration on the fw, you are also limited to having at most one service of each kind per NATted network, because you use up their default ports.

> you are also limited to having at most one service of each kind per NATted network

That's not entirely true. It's possible to assign source port/address combos that route to different hosts.

For example, I can say that:

* 1.1.1.1:80 routes to 192.168.1.2:80,

* 8.8.8.0/24:80 routes to 192.168.1.3:80, and

* everything else on port 80 routes to 192.168.1.4:8080

It's possible to get even more convoluted, though not recommended.

That's already quite convoluted, and it means that one remote address can only connect to one of the services at a time and you need to reconfigure your router to change which one. It also gives you no selectivity for remote networks that use NAT, so if 1.1.1.1 is actually an ISP using CGNAT for thousands of customers then they're all stuck with going to only one of your services.

(If I read your post as written, it also seems to say that the client needs to pick a custom source port and if they're using NAT then they also need to get that source port unaltered through all of their layers of NAT. And they'll be limited to one connection at a time, perhaps one connection for however many people are behind the same CGNAT, because only one connection can use a specific source port at a time.)

So yes, you can pile hacks on top of hacks on v4, but it's not similar effort to just permitting the connection in a firewall, and it has a bunch of extra limitations too.

Correction about link-local: v6 link-local doesn't really work for this - LL addresses are meant to be used for low level stuff like address autoconfiguration and neighbour discovery. They don't even work with the normal socket APIs without doing some extra gymnastics (specifying interface indices etc).

What does work though is ULA (Unique Local Addresses) - they're also designed to prevent conflicts when you eventually end up making a mashup of your and someone else's network who also wanted to use their own addresses.