== making VoIP deployment hard/impossible depending on your router and phone model. :(
If the singalling protocols would allow for something like 'hi - my client $foo wants to talk to your client $bar. Please direct your response to me' and the other end would then send the packets with 'this is a packet from my client $bar to your client $foo - as you told me, I'm sending it to you', then there wouldn't be an issue - aside of a very small bit of additional latency and higher complexity of the gateway software.
If these client IDs are opaque, then the network topology stays hidden, but NAT would be completely irrelevant in between.
Now, personally, I'm really looking forward to having a /64 at the end of my cable modem. I will make splendid use of it and I will highly enjoy the additional uses I get from having my machines freely accessible to the internet.
On the other hand, people got good at understanding the feature set NAT provides and, thus, at configuring NAT gateways which also don't allow incoming connections per default.
That way, if I'm just a "normal user" and I buy myself a WiFi printer, I don't have to concern myself with configuring a firewall in order to ensure that it doesn't turn into an involuntary fax machine for example.
This could of course be solved by correctly configured firewalls on these crappy blue box routers, but how many years will it take them to reach "correctly"? Will they actually be configurable enough? Or would they just drop anything with a SYN bit set? How would these crappy firewalls deal with incoming UDP? Block it unconditionally (thus breaking VoIP even more)? Add "connection" tracking? In that case, why not just NAT?
I believe it's a good thing to have NAT back. Will I use it at home? Probably not. Will my parents use it at home? Likely. Would they be affected? Likely not as we already are used to deal with NATed clients.
That's called routing, and routers are perfectly able to do that already, much better than some possibly whacky custom application level implementation. By your reasoning, there's no reason not to have HTTP proxies everywhere.
> I don't have to concern myself with configuring a firewall in order to ensure that it doesn't turn into an involuntary fax machine for example
This has to be the most ludicrous example I keep hearing again and again. I don't see what's different from the end-user point of view between "my gateway does NAT" vs "my gateway refuses unrelated incoming packets". Seriously, take your random Airport Extreme and it's one freaking checkbox in the IPv6 tab (which should and will, in the forecoming wide availability case, be on by default, just like current NAT).
Can we stop conflating NAT with the no-incoming filtering rule already, please? Let's look at the "hello, world" of Linux NATs example:
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
First line is NAT and protects you from nothing by itself. It only happens that usually, the WAN side can't access the LAN side because LAN is on a non-wide routable IP range so packets may simply not be routed. And guess what, second and third line which do filtering, do not require NAT, and are perfectly available features on IPv6.Also it works with asterisk only, so it's not that useful in practice.