This won't happen. When IPv4 dies, then so will NAT. But we'll all need IPv6 stateful firewalls at home. Generally, they'll block all incoming attempts to make new connections, and allow any outbound connection attempts.
Now you have the same problem. The same solutions will need to apply here, too. So NAT isn't really the fundamental problem here.
But a firewall I can open. heck most consumer routers came preinstalled with holes on the firewall/NAT for FTP,IRC,MSN and a bunch of long dead protocols that required the server to connect to the client...
with ipv4+nat often I can't allow a connection because i don't have the IP visible. i'd have to have the server to add my internal IP (which will surely conflict) to their routing table passing trhu my external IP on the router.
NAT'ing is such an ingrained way of doing things, and it also happens to be a great way to separate your network from the rest of the network/internet. I don't think it'll go away any time soon.
Please allow me to be pedantic here. What actually separates your network from the rest of the Internet is called a firewall. It is unfortunate that common usage has conflated the two terms to the point that many people believe they must be inside a NAT to be firewalled from the outside. It's actually one of many misunderstandings related to the IPv6 transition.
A Firewall is exactly the same thing as a bouncer at a club. The firewall-bouncer decides if you, the packet, get into the club. He might let you in, he might ignore you, he might tell you no.
NAT is a dinner party at a house on a block. There's no bouncer. If you know the right house, you walk right in the front door. But there sure are a lot of houses! So it seems unlikely that someone will crash your party, but don't you trust the bouncer more, now that you're thinking about it?
I'm not sure I follow your analogy. With a NAT configured to only forward certain ports to certain machines, the "bouncer" exists as much as in the firewall case. The question is not whether a NAT can be an effective firewall; it's that it brings some other, rather unsavory features along with it.
Don't get me wrong, I know the difference between NAT and a firewall, but NAT'ing automatically (and by definition) hides the network behind, firewall or not.
Then you are using NAT as a simple firewall. You could have the firewall part without the translation part (or with deterministic two-way translation), which would eliminate 99% of problems. let me explain:
A NAT "hides the network" behind it because it does two things:
1. drops incoming connections (or more precisely, incoming traffic when there was no outgoing traffic from that ip:port on that protocol)
2. obscures internal network addresses
Dropping incoming connections is what makes it a simple firewall and you could set up a "real" firewall to do the same (there are probably products doing that out of the box). Most firewalls are more complex than that, but they don't _have to be_.
What makes NATs different is the address translation that obscures the structure of the network behind it. Traditionally this is needed because you have lots of internal addresses and few external addresses (often just one). But if you have more hosts than external IPs then you can't have a static mapping without collisions because you have more internal ip:port pairs than external ip:port pairs. Which is why NAT generates internal-external mappings as it goes and why old mappings need to be discarded and why it needs to drop incoming connections (it can't know where to forwarded it to if there is no mapping). THIS is the part people hate, because it means you can't reliably connect two NATed hosts. If hole punching worked reliably it wouldn't be a problem, it feels like a hack, but the internet is a patchwork of much worse hacks.
A true firewall and a NAT-as-firewall are sort of duals of one another. A true firewall sits on a path that would normally let packets pass, and it stops them. A NAT-as-firewall sits on a path that would normally not let packets pass (because the private side is some unroutable, private, 10.* network), and it helps them through.
As an admin, NAT-as-firewall feels reassuring, because it seems less likely to fail in a dangerous direction. If i screw up my iptables configuration, i might drop my firewall, but i am very unlikely to create a new NATted path into my private network.
I do believe you know the difference; your wording was clear enough. I just took the opportunity to dispel what seems to be a common misconception (not as common on HN, I hope!)
Most soho ipv6 routers (that also do v4 nat) do connection tracking for their v6 subnet, blocking inbound connection attempts by default, to emulate the security properties of v4 nat.
This means that you still have the same "unconnectable from the outside" problem you have with v4 + nat.
At least with a decent, non-greedy ISP you have the option of turning off said connection tracking and enjoy your fully routable /48. But I do understand how it remains a problem when most people don't know or want to do that.
Ideally, there could be some kind of uPnP-like protocol to open ports on an IPv6 middlebox, so that you can have a firewall on by default but still be able to punch a hole through it, without user intervention, when an application needs so.
I actually think that's a sane default. With NAT it's a PITA to undo that and in some cases impossible (e.g. when you have 2 machines on a LAN using a protocol that requires a static port, so you can't just forward to a specific machine). With stateful firewalls, it should be much easier to just say "Allow port X through" and have a single application "just work"
