Data centers are extreme outliers on per-building power consumption, so it doesn't make much sense to use them as the standard building when talking about the requirements or capabilities of solar.

Did you see the picture I linked? It doesn't seem to be anywhere near as hard as you're imagining.

You seem pretty focused on the idea of companies charging you for things, but that's very normal. If you don't like it, you can always install your own solar panels and use the power yourself or sell it to the grid, instead of letting them install the panels and then buying the power from them. Solar is the one form of energy generation that you can do that with, even. Basically everything else is too large-scale for an individual to do -- you'll definitely be paying the power company for any power generated from a nuclear reactor, for example, and you'll probably face higher transmission losses too since it's probably further away.

You can run 480V/3 phase welders off solar if you want. You can run anything that currently runs from the mains grid from solar. You still get 20-80% power out of solar panels on cloudy days, which is far more than "a fart" implies. That's also more than the 0% you get out of fusion right now, because it doesn't exist as a commercial concern yet. It'd be nice if it did, but I suspect it'll still be more expensive than solar+wind+batteries currently are, and ultimately no more reliable for the end user anyway.

You don't need 1GW to power a building. Taking your watts and surface area numbers, the average farm size in the US (~450 acres) would be more like 250 MW for the entire farm, but that's still enough to power a hundred thousand buildings, not just one building. And... having solar panels doesn't prevent you from farming the land.

Wind turbines need less space than that. I could understand if you didn't realize that solar panels and farming can take place on the same land... but wind turbines? If you're trying to tell us a wind turbine occupies 40-70 acres of land and prevents that land from being used for anything else, you're obviously lying to us on purpose, because there's no way you could seriously think that all the open ground around the turbine is unusable for any other purpose.

Honestly, I think you had it right the first time. Get rid of the "reliable" sources of power, and we'd likely end up with fewer power cuts in the end. A grid built entirely out of wind and solar would require battery storage, and the battery storage needed to maintain power with wind and solar would also work for power cuts. It would be significantly cheaper to target (say) 99% grid uptime, instead of targetting 99.9999% and then still having downtime anyway -- it might actually be cheaper even after the cost of batteries to cover that 1% of downtime.

Also, renewable power is already cheaper than nuclear. As disappointing as it is, I think the window for nuclear has closed.

Every time I've tried, it just backs up what I already knew. Are you sure it's not your own ignorance talking here?

You're right that someone from another country is going to have trouble sending a packet to 10.0.0.2 on your network... but that has nothing to do with NAT. We're talking about what NAT does to connections your router receives, not what it does to ones your router doesn't receive.

And the answer to that, if you read everything about how NAT works or if you go and test it yourself, is that unless you have a port forward rule that matches a specific connection, it does nothing to them at all. Which means the behavior is exactly the same as it is for any non-NATing router -- in other words, NAT doesn't function as a firewall.

They are routable. You can put a private address into the dest IP field, and routers will route it.

I've done this. The packets weren't dropped, and I was able to connect from outside over a router that was NATing.

Sure, but it matters a lot if you're trying to argue that NAT will cause a router to block incoming connections!

I would call OS/2 or BeOS one of those things.

Notice how we aren't talking about CLNP or SIPP. The only reason you're talking about IPv6 is because it isn't a failure.

Then perhaps you should be less certain about your "we definitely made no other changes at the same time" assertion.

At the same time you put those machines behind NAT, you almost certainly also moved them from public IP space to RFC1918. That will have been what stopped all the random exploits, not the NAT.

Okay, yeah, that's fair. Can you at least remember if they were the same or not, before and after?

That's not weird, that's exactly what you'd expect if you're using RFC1918.

But okay. We now agree that a NATing router doesn't block inbound connections before you add the masquerade rule. What about afterwards? How does adding the masquerade rule make it start blocking inbound connections? The documentation for iptables states that masquerade will change the source IP of the connection, not that it will block other, unrelated connections, so it shouldn't have that effect.

How can the router have no concept of an internal host? It's a router. That's a key part of its job. It doesn't need a mapping in the NAT table to route packets.

If what you're saying is correct, why can I establish a TCP connection to InternalIP:Port through a router that's doing NAT without adding a port forward? Because I've tried and it worked, but that completely contradicts what you're saying should happen.

In reality, if there's no entry in the NAT table it simply means that NAT doesn't do anything to the packet, not that the packet is dropped. The router will then route the packet to whatever IP the packet was sent to.

Can you humor me for a moment and tell me what the IP range on the network was, before and after? First one or two octets is fine if you don't want to identify the Uni in question.

Everything you said here makes it sound like the router is working just fine before the masquerade rule is added. If it's passing packets both outwards and inwards, then surely it's working properly?

In order to self-host something on v6, any clients that connect will also need v6 -- even those that don't self-host anything themselves. That's why everyone needs it, not just the people that want to run servers.

Are you certain that you changed nothing else about the network setup at the same time? Because I've tried adding NAT to a network to see what impact it had on inbound connections before, and it had none whatsoever.

I think you changed more than one thing at once, then got confused about which change was causing which effect. And now you're arguing with the people who are trying to explain this to you, instead of listening to them or doing your own tests.

All v4 packets specify a destination. They have a dedicated spot in the header for a destination IP, and there's no way to omit that part of it.

Even if there was, you don't control the contents of incoming packets, so an attacker could just... put a destination into them. Declaring that they won't isn't going to stop them.

Alas, IPv4 is four octets. An eight octet IPv4 addressing system doesn't exist. You have to work with what you've got, not what you wish you had.

We could have added four octets in IPv6, but doing so would've been dumb because it wouldn't be big enough. Look how hard it's been to deploy one update to IP. Why would you set yourself up for needing to do it twice?