> Not having this local/wide address distinction makes it more likely that firewalls will simply block all traffic until, as you say, similar systems to those u

> Not having this local/wide address distinction makes it more likely that firewalls will simply block all traffic until, as you say, similar systems to those used with NAT are implemented. Yes, and that would be the sensible thing to do. This "public/private" distinction doesn't even work: What if you have two LANs that aren't bridged? Possibly because they are connected through a VPN? Or maybe one Ethernet and one WiFi? Can you communicate between them? Or only on "public addresses"? What if the VPN is between two companies, say, who don't trust each other? And why would you make it depend on the "address type" anyhow, why not just have the application drop connections that come from outside the LAN? Blocking all inbound connections by default is no real problem as long as you have a protocol for telling the firewall which addresses/ports to open to the public - the problem with the "port forwarding" that you need with NAT is that ports collide and that you create asymmetric address translations or bottlenecks and all that crap, a simple protocol that tells the firewall to open a specific port or address would be trivial to implement and to use. Also, IPv6 has link-local addresses, which are essentially "private addresses for a LAN", so you can actually set up services that are reachable only on a given LAN (and nowhere else) - but that really only makes sense for local LAN management (neighbour discovery and such), not for application protocols, those really should just be reachable from everywhere, as far as the local API is concerned, and access control should then happen based on source addresses, possibly implemented as a stateful packetfilter at the network boundary, as you otherwise severely limit which network architectures can be used.