Not as cool then. Though, if its summer and the enemy city is experiencing a heatwave, giving it "extra sun" could be useful.

It may be BS and really inefficient, but it could also be an awesome weapon. I they manage to put up a solar power satellite that can do, say, 1GW of useful power (probably 5GW of total power), instead of beaming power to the ground-based power plant, you can also aim it to the enemy country and some spot there gets really hot...

I guess that's the difference between theory and practice.

Yes, in theory, a NAT router will not block incoming connections without a firewall rule to do so. In practice however, for the vast majority of people and even companies (as in, everyone who gets a single public IP from their ISP), it will be the same as if the router did block incoming connections, because those incoming connections are not possible as a consequence of using RFC1918 IPs in the LAN.

After all, the argument for IPv6 is that with it you have enough addresses to not need NAT and be able to have incoming connections.

Yes, there is an attack, but it requires very specific circumstances:
1. Be a subscriber of the same ISP.
2. Be on the same VLAN.
3. The ISP cannot have IP filtering (ip-mac-port binding or similar) and no traffic segmentation (pvlan).
It reduces the set of potential attackers from "anyone with an internet connection" to only a few people who actually have to try to do this and not merely be infected with some worm.

If you have a brand new Windows XP installation with its firewall disabled and connect it directly to the ISP (so it gets a public IP), it will get hacked within seconds or minutes. If the same Windows XP PC is behind a NAT router and has a RFC1918 IP even if the router's firewall is set to allow all, it won't be hacked at least until one of the neighbors deliberately tries to do it.

It does not matter that the router does not block inbound connections if those inbound connections are not possible as a consequence of using RFC1918.

NAT protects even without the drop/reject rule, because the LAN IPs are not publicly routable or the ISP does not have a route to the LAN subnet (in most cases it's both). As such, without an explicit port forwarding rule (or something like uPnP), no incoming connections can be made to devices behind NAT.

Yeah, it's working, just my internet connection isn't working without that rule. Apparently, my ISP does not accept packets from 10.0.0.2, it only accepts packets from the public IP it assigned my router. Weird. Maybe its because multiple subscribers may have a device with 10.0.0.2 IP and the ISP cannot distinguish which one the packets came from or something.

Yes, the packets arrived without issue because it's an outgoing connection, so the router can forward the reply packets back to the device which originated them.
However, there is no way to initiate a connection to a device behind NAT unless there is a port forwarding rule. Without such rule, even if the firewall is set to allow everything, there is no real way to initiate a connection to a device behind NAT.

Alternatively, maybe there is an easy way to do that, in that case why do we need IPv6 at all? IPv4 and NAT works just as well, right?

Because my LAN uses RFC1918 IPs, which are not routable over the internet. You cannot connect to 10.0.0.2 on my LAN.
Similarly, without the masquerade/snat rule the router passes an outgoing packet with source IP 10.0.0.2, which then gets dropped by the ISP because the ISP has IP filtering or, if the ISP allows the outgoing packet, a reply packet will not come.

So, let's say I have a typical home internet connection. My router gets a public IP and my LAN is one of the RFC1918 subnets. My ISP does not have a static route to my LAN.

With just ip.forward enabled and no iptables rules (allow all), in theory my LAN would be accessible from outside, but for that the ISP would have to have a route to my LAN and even then, my LAN would only be accessible from my ISP, not the rest of the internet.
A subscriber to my ISP could add a static route to his router to access my LAN, but for that he would need to be on the same VLAN as me and the ISP has to not have IP filtering or something similar implemented.

It's not that difficult to forget it when writing the rules.

On a default Debian installation, iptables are set to allow everything. So, I enable ip.forward and immediately my router starts forwarding everything without me explicitly setting iptables -P FORWARD DROP or adding a drop rule.

With NAT (does not matter, v4 or v6). I enable ip.forward, nothing works. I then add the masquerade rule, now outgoing connections work and incoming ones are dropped (excluding the case mentioned in my previous post), even with -P FORWARD ACCEPT.

To make a non-nat router/firewall pass all packets, I just need to forget/remove the drop all rule.
To make a nat router/firewall pass all packets, I need to explicitly add a NAT rule and even then packets would be forwarded to only one internal host.

So, how will you or some hacker be able to access 10.0.0.2 on my LAN from outside without me adding a specific rule to forward some port to it?

If a packet comes to my external IP and there is no NAT rule matching it (and no service runs on that port on the router) the router will just discard or reject it, because it does not know where to forward that packet.

Yes, -P ACCEPT and then the masquerade rule.

How does that allow anyone from other countries to connect to 10.0.0.2 on my network?

I am not saying this is perfect and I would rather ad a rule that allows outgoing connections and drops incoming, but even without those rules, just the fact that my LAN is on a RFC1918 subnet would make it pretty difficult to access anything inside.
The only way to do it probably is:
1. be a subscriber of my ISP
2. be on the same VLAN as me
3. the ISP to not have IP filtering on switches and no traffic segmentation (pvlan).
4. route add -net 10.0.0.0/24 gw my_wan_ip
Now you would be able to access my LAN.
This reduces the set of potential attackers from "anyone anywhere, including automated systems" to "depending on the ISP some of my neighbors who know how to do this or got hacked and the hacker is deliberately trying to attack me or the ISP employees".

As I said, not perfect (it would be much better to have actual firewall rules), but much better than my LAN having publicly routeable IPs and forgetting the "drop all" rule on the end.

You can VPN into your home network. Though, I guess, allowing the device to be accessed by anyone from anywhere (I mean, you may want to access it from a hotel, so you don't know what your IP would be ahead of time) may be fun too.

Right, because otherwise the companies would give up their control, right. They can already do that, just provide a Web UI to the device directly, I can forward a port or use a VPN.

Let's say I configure NAT to allow all traffic, but do not add any port forwarding rules, just the single outgoing masquerade rule.

How would you, from another country, would be able to exploit that to connect to 10.0.0.2 on my network?

You are correct, I use nano. I also remember the IPs of my devices, though, I guess, if I had to use IPv6, I could assign fd80::0:1, fd80::0:2 and so on instead of 10.0.0.1, 10.0.0.2. Numpad does not have letters and : though, so it would be a bit harder to type those IPs.

NAT even with "allow all" gives some protection. While it does not protect from more specific cases (such as my neighbor adding a static route to 10.0.0.0/24 through my WAN IP) it protect from most incoming connections from anyone outside my VLAN in the ISPs network.

With NAT, I have to add a rule to forward a port to some internal device. If I don't do that, it won't be possible to connect to it (outside the specific cases mentioned above). Without NAT, all it takes is forgetting the "drop all" rule on the end.