> NAT automatically prevents attackers from scanning for and attacking listening ports on the hosts behind it.
That the firewall, not NAT. NAT on it's own - without a firewall, a very unusual configuration - will route packets to your "private" addresses if that address is in the packet's DST address field (maybe; it depends on the rules the router uses when deciding how to rout a packet, which is also not NAT). NAT is only about changing the address field. RFC 2663 even recommends that NAT should usually be "used in conjunction with firewalls to filter unwanted traffic". Unless you're referring specifically to changing the address/port fields in the packet header, you are probably referring to a stateful firewall. That's the feature that is usually responsible for dropping packets, preventing scanning of your LAN.
TL;DR - address translation (NAT), and choosing what to do with a packet (firewall, routing rules) are separate, independent features. NAT - by itself - isn't really involved in routing/firewall step. That's why it's extremely unusual to see NAT in isolation. The thing you see on e.g. most home routers is basic use of NAT combined with a simple router and (hopefully) a powerful stateful firewall.
> should also know enough to forward the ports
That's nice iff you get to decide which ports are forwarded. Good luck getting a carrier to forward ports. It isn't going to happen if you're in some parts of China behind 7 layers of NAT. Port forward in that situation would be a nightmare, assuming it was even theoretically possible to convince the 7 upstream authorities that they should forward a port to you.
However, minutia about port forwarding doesn't address my main point: that NAT limits the type of software that is developed. Are you really going to write a network app that only works if people setup port forwarding? Would business use telephone for as many purposes if phone numbers were all shared party lines?
> That requires extra action on the part of the "attackee"
That "extra action" is probably the most common vector of infection for modern malware. Ignore it at your own peril.
That the firewall, not NAT. NAT on it's own - without a firewall, a very unusual configuration - will route packets to your "private" addresses if that address is in the packet's DST address field (maybe; it depends on the rules the router uses when deciding how to rout a packet, which is also not NAT). NAT is only about changing the address field. RFC 2663 even recommends that NAT should usually be "used in conjunction with firewalls to filter unwanted traffic". Unless you're referring specifically to changing the address/port fields in the packet header, you are probably referring to a stateful firewall. That's the feature that is usually responsible for dropping packets, preventing scanning of your LAN.
TL;DR - address translation (NAT), and choosing what to do with a packet (firewall, routing rules) are separate, independent features. NAT - by itself - isn't really involved in routing/firewall step. That's why it's extremely unusual to see NAT in isolation. The thing you see on e.g. most home routers is basic use of NAT combined with a simple router and (hopefully) a powerful stateful firewall.
> should also know enough to forward the ports
That's nice iff you get to decide which ports are forwarded. Good luck getting a carrier to forward ports. It isn't going to happen if you're in some parts of China behind 7 layers of NAT. Port forward in that situation would be a nightmare, assuming it was even theoretically possible to convince the 7 upstream authorities that they should forward a port to you.
However, minutia about port forwarding doesn't address my main point: that NAT limits the type of software that is developed. Are you really going to write a network app that only works if people setup port forwarding? Would business use telephone for as many purposes if phone numbers were all shared party lines?
> That requires extra action on the part of the "attackee"
That "extra action" is probably the most common vector of infection for modern malware. Ignore it at your own peril.