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?

How does the router know not to work before you've even added the masquerade rule? I could understand the effect applying forwards in time, but backwards in time?

Also, how does the masquerade rule drop incoming connections? The manpage says it's equivalent to an SNAT rule, which "specifies that the source address of the packet should be modified" and doesn't mention anything about dropping them. It should just change which IP they look like they're coming from.

Yeah, they'll get dropped before they even leave my network. What does this tell us about how NAT handles inbound connections? Nothing at all.

For connections that actually reach your router, NAT does precisely nothing to stop them. That's why it's not security.