I am the last person to be defending NAT, but the benefit of NAT is that it sets up a really good default: incoming connections are not routable by default, and it's very hard to accidentally change this. There are many good ways to have "not routable by default" with IPv6, but you have to do that at the software level, while NAT forces it at a protocol level.

> incoming connections are not routable by default, and it's very hard to accidentally change this

Not just difficult, but impossible, even in principle, because there are more than one device sharing the same IP so at most one host would be vulnerable. Not the same as with IPv6, where screwing up the defaults leaves your entire network vulnerable.

You can forward all ports to a device, pretty common feature.

Right but that only leaves that device vulnerable. The other devices are not.

In practice, that makes the entire network vulnerable.

Yeah, server-side NAT + use of a reverse proxy makes hosting many websites from one IPv4 a possibility, albeit a relatively difficult one. You are only really in trouble if two consumers want raw TCP/UDP on one port.

> incoming connections are not routable by default

Tons of firewalls ship with this as a default logic, it doesn't require NAT in the slightest.

Parent poster is making the (good and underrated) point that NAT makes this logic failsafe: Turn an IPv6 firewall off and you’ve got all incoming connections allowed. Turn IPv4 NAT off and you’ve got no connectivity at all

So gate it behind a "here be dragons" option or hide it in the GUI entirely for the basic home version.

Or make the "turned off" state block all traffic, just like closing a water valve, or a road gate. I never understood why network firewalls did not default to this.

Turning off the firewall could just as easily be a unnoticed configuration error that causes it to die on startup

How are you gonna get the IPv6s of your targets? Can’t scan a /64, and with ephemeral ”security” addresses used for outbound conns, an adversary won’t be able to guess the address anyway. At least that’s my understanding. So I guess my question is: is this a real threat?

Only if you trust your ISP:

https://www.anvilsecure.com/blog/dhcp-games-with-smart-route...

This reminds me of a company where the admin used public routable IPs for the internal subnet. The gap is always the human in the loop.

There's nothing wrong with this, and it's common at universities that have large IPv4 allocations.

The subnet that he used internally was "officially" used and owned by oracle and our printers regularly send traffic falsely to Silicon Valley.

This was the norm for most of the 90's and earlier. NAT was supposed to be the exception, but it became the rule. Now we have an entire generation that doesn't understand that the Internet was always supposed to support end-to-end connectivity.

Plus too many of that generation see NAT as a "security feature" not an "IP bug" and can't seem to (re-)imagine traditional firewall/router design from the time before NAT. "end-to-end connectivity" is not the same thing as "open and unsecured connectivity", we have the security tools to deal with that and they are not and have never been named "NAT".

To say NAT has nothing to do with "security" is a lie. The most common NAT (PAT) configurations are basically acting as stateful firewalls with a default deny policy for all unsolicited inbound traffic to a private, non-routeable network.

They aren't doing that though. The most common NAT (PAT) configurations don't deny unsolicited inbound traffic.

They are of course commonly deployed together with a firewall that does deny that traffic, but claiming that NAT blocks connections because it's usually deployed together with a different technology that handles all of the blocking would also be lying.

> The most common NAT (PAT) configurations don't deny unsolicited inbound traffic

That doesn’t make sense.

If I have a single routable IPv4 addresses and 100 machines behind it with RFC1918 addresses, how can any possible router “allow by default” say, port 22? Which machine would it route it to? Would it pick the first one? Randomly select one?

Of course NAT has to drop incoming unsolicited packets. Unless you tell it which machine to route them too, it couldn’t possibly know how to “allow” them in the first place.

IP packets have a "destination IP" header field that specifies where the packet goes. The router reads that to figure out where to send the packet.

The only thing NAT does is rewrite the dst or src headers of packets. If there's no rule or state entry that applies to a packet, it doesn't drop the packet. It just leaves the original headers on it.

How would a packet with a destination IP of my internal RFC1918 address have landed on my WAN interface in the first place? It would require my ISP to have a routing rule that sends it to my router. Is that the threat model you’re thinking about?

He's assuming your non-routeable RFC1918 addresses are actually routed from the Internet, which won't be happening in the normal consumer use case.

Even if there's no blocking, using internal RFC-1918 addresses still adds a layer of security since they are not reachable globally.

> basically acting as stateful firewalls

Stateful Firewalls are the security tool. NATs being mediocre to somewhat alright stateful firewalls "out-of-the-box" before adding a real Firewall is the accident (and sometimes bug). Something doing security by accident (or as a bug) isn't a security tool (just like security through obscurity isn't a security tool). You can have Stateful Firewalls without NAT. Everyone saying that you "need" NAT to have Stateful Firewalls doesn't understand Firewalls or even possibly why "firewall" is and has always been a different word from "NAT". NAT has something to do with security, but that's being generally always paired with a good firewall, not being a mediocre firewall mostly by accident.

I wouldn’t want to relay on random caffee’s router to do this for me. I would still end up running firewall more carefully on my end devices. Which for my iPhone I’m not even sure if I can. So probably a personal VPN would be a must.

Sure... But wouldn't you want to treat this random network as hostile anyway? The router might already have port forwarding to the IP you grab from DHCP, not to mention other clients on the network. I'm also unsure how a VPN would help against inbound traffic regardless?

Does a VPN prevent inbound traffic on other IPs? If I put my laptop on a VPN, I can still SSH to it on its RFC 1918 address.

A VPN can’t prevent inbound traffic but if the VPN alters the routing table it can prevent the return leg from working. This probably isn’t enough to prevent compromise.

It depends on the VPN and its policies. Some deny all local traffic when active, routing everything through the VPN, and only leave a IPv4 /32 route for the default gateway. Some are more permissive.

> I wouldn’t want to relay on random caffee’s router to do this for me. I would still end up running firewall more carefully on my end devices.

Are you not doing that already? If you trust whoever else happens to be on the same wifi in the cafe you're a braver man than I.

> Having globally allocated address space doesn’t actually imply openness of connectability

Of course not, that's not my point. My point is that because of the fact that your home router still firewalls with both IPv6 and IPv4, any software which relies on being able to "just" connect to a peer over the internet, is doomed. Our networks don't work that way any more (they probably did in the early 90's though.)

My point is that even if we had global routability, we still wouldn't have open connectability, because open connectability is a stupid idea. Which means any software ideas people might have that rely on connectability, are already a non-starter. So why do we need open routability in the first place? (Honest question. This is the crux of the issue. Yes, open routability means you can have a host listen on the open internet, but fewer than 1% of people know how to configure their home firewalls to do this, so it's effectively not possible to rely on this being something your users can do.)

Yeah, I've had to make this point several times. Getting rid of the NAT doesn't rid you of the need for NAT hole-punching and whatnot, since any sort of firewall will need a hole-punching scheme to allow incoming connections.

I'd say the biggest practical objection (not just "NAT is ugly" or "DHCP is ugly" or "NAT is evil since it delayed IPv6") is CGNAT, which really does put a lot of restrictions on end-users that they can't circumvent. The more active hosts stuffed behind a single NAT, the more they have to compete for connections.

> but fewer than 1% of people know how to configure their home firewalls to do this, so it's effectively not possible to rely on this being something your users can do.

And a chunk of that 1% are on WANs that they aren't authorized to configure even if they wanted to.

> * My point is that* because of the fact that your home router still firewalls with both IPv6 and IPv4, any software which relies on being able to "just" connect to a peer over the internet, is doomed.

With IPv6 the only thing you need is PCP (or equivalent).

With IPv4 you need PCP/whatever plus a whole bunch of STUN/TURN/ICE infrastructure.

Just hole punching is a lot easier to support than more-than-just hole punching.

If you have PCP (NAT-PMP or whatever), why would you need STUN or TURN? (You still might like ICE, but ICE also makes sense to have on IPV6.)

It's still basically another mac address or unique identifier for the system, regardless of which local network it happens to be on. Great for being tracked by FAANG, I guess, but I'd rather for my devices use a generic local IP and a randomized mac. There's no reason why the refrigerator needs to be uniquely identifiable on the Internet.

No, v6 addresses are assigned by (or chosen based on) the current network, not permanently associated with a given system. They aren't MAC addresses or unique identifiers.