Adding socks support to everything is just as daunting as supporting a migration to ipv6 via transition mechanisms such as 6to4/6in4 and leaves us with something that is even MORE restrictive and less scalable than NAT. It also provides no upgrade path to solve these issues (it is much easier to switch from 6(to|in)4 to native ipv6 than socks to anything). This is not a workable solution.
"I don't wanna use IPv6! I'll have to change things! Waaaah!"<p>Just shut up. Do it. Do the transition. Yes, it will be hard. Yes, it might break shit. No, IPv6 is not perfect. But do this transition <i></i>once<i></i> and we have enough address space to make it to the galactic civilization level. 2^128 addresses is big. It's a one-time thing.
Of course, what I'm proposing here - fixing the problems with NAT as a way of making IPv4 address exhaustion not be a problem <i>for clients</i> - doesn't help with IPv4 exhaustion for servers.<p>What would I propose for that?<p>* Using them more efficiently by having protocols support endpoint identification within a server (HTTP supports virtual hosting, SSL has spreading support for host identification in the SSL handshake process, SMTP has been fine with it for years, etc).<p>* Using incoming connection proxies / load balancers to have a small number of external IPs, connections to which are handled by a large number of backend servers<p>* Perhaps in the longer run, better usage of SRV records so that well-known ports fall into disuse, and server ports can be assigned by the administrator and then placed into the SRV record for that service, in effect making IPv4 addresses be 48 bits long.
The real reason for low adoption of IPv6 is that it would decrease demand in hosting and clould services at least for personal use as everyone will be able to access their home computers from everywhere. Service providers does not want IPv6.