Why not just adopt ipv6 and connect to the box directly and intuitively when all ipv4 nat boxes in the middle die?
Now you have the same problem. The same solutions will need to apply here, too. So NAT isn't really the fundamental problem here.
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.
This is the problem ipv6 solves.
Sadly enough.
As for 1:1 NAT, we already support other solutions that have similar effects, such as scriptable proxying.
your client will probably have it's market eaten by someone who understand the tech. hopefully.
/me insert faster horse fallacy
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.
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.
This means that you still have the same "unconnectable from the outside" problem you have with v4 + nat.
Yes, I too wish it weren't this way.
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.
Maybe there is; I haven't checked.
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?