[alexfreska]

Yeah IPv6 is valuable but it seems NAT is the smallest inconvenience since a p2p connection can usually still be made. Briefly giving it thought, I don't think IPv6 could rid the use of TURN servers or close the other 5% of anomalies. Am I wrong?

[AshleysBrain]

NAT only exists to workaround IPv4 address exhaustion. I think it's more likely the 5% edge cases have firewalls that block anything that doesn't look like normal HTTP traffic.

[derefr]

> NAT only exists to workaround IPv4 address exhaustion.

Untrue; people were using NATs long before they were concerned with running out of IPv4 addresses. I think it was a bit of paranoia combined with lack of trust in firewalls: corporate sysadmins just didn't want their internal networks to have routable addresses.

This seems to have been mostly calmed by the explosion of "cloud" IaaS offerings, which need publically-routable addresses to do much of anything.

[rictic]

I don't think that's so. A NAT also prevents random hosts from directly opening connections to the machines that it's obfuscating (module port forwarding), which serves a nice security purpose.

[pdkl95]

You're confusing NAT with the firewall. Without a firewall, a pure-NAT will often let you route to the internal network addresses from the outside. There isn't really much "obfuscation" of the LAN addresses either, as they are almost certainly a 1/256-guess away on the 192.168.1.x network.

This confusion is very common, probably because it's incredibly rare to find NAT by itself. Every home router is basically guaranteed to have a basic stateful firewall in addition to providing NAT.

[zanny]

And every modern IP stack also provides a firewall, be it iptables or whatever the Windows Firewall is. I don't think the "NAT is necessary because putting our computers on the public internet is scary" is anything close to a reason to keep the hodge podge mess we have.

[rictic]

I suspect I am confused. If you're feeling generous (and notice this comment 6 days later, heh), would you mind correcting my mental model and slicing up the difference between NAT and firewall?

Suppose that there is one external ip, we'll say 1.1.1.1 which is NATting two internal ips, 10.0.0.1 and 10.0.0.2. When a packet comes in, say a TCP packet attempting to open a connection on port 80, what are the options that a non-firewalling NAT has to figure out which internal ip to route it to? Assume that both ips are running webservers.

I know of two answers to this question, one is port forwarding, where the NAT is explicitly configured to forward incoming port 80 traffic to one of the internal hosts (meaning that only one of them can listen for traffic on a given port). The other doesn't work for new incoming connections but just has the NAT watching for outgoing traffic and allowing incoming traffic to come back (using (foreign ip, receiving port, sending port) up to route packets to the internal IP that started that conversation). My understanding is that NAT traversal techniques typically try to first ask the NAT to forward a port for them (uPnP / NAT-PMP), and if that fails then they try to exploit the second method using ICE.

What am I missing?