It's a kludge. I can't see how it would be preferable in any way to a single global "namespace".
I have serious concerns with IPv6's practicality, even with 6in4 et al. Is trying to implement it just flogging a dead horse?
If somebody comes up with a way to actually get IPv6-only nodes widespread - not just nodes with joint IPv4 and IPv6 machines - then I'll have hope for mainstream IPv6. But while every client and server has to have IPv4 as well to be of any use, then what benefit does having IPv6 connectivity give it?
Yes, the transition is going very very slowly. But I don't think there is a problem. One could argue it's the same with IPv4 addresses as with oil. Eventually, it will get more expensive as it gets more scarce, and people will gradually switch to alternatives.
At a certain moment all the important sites will have adapted IPv6 that it's economical for some users to drop expensive IPv4. Sites will then hurry to go to IPv6 as they lose customers. But I guess there's no need to hurry yet... at least for us IPv4-rich western countries.
The only downside is you need better firewalls.
Adding features to operating systems is easy - IPv6 support has been in all the major OSes for years. Getting it out there wasn't that hard but getting people to use it has proven to be a different matter entirely, largely because it is not backwards compatible with IPv4 and because of the resulting chicken-and-egg situation.
With something like this, you could upgrade your OS, then upgrade you router, and see immediate benefit. Or you could skip upgrading your router and use an in-the-cloud provider instead. It's much, much easier.
I think we're going to see people explore application-layer proxying (things like Tor, my http://pagekite.net/, this SOCKS idea) more and more as the IPv4 shortage starts to have an impact. Sure it's less efficient and it may feel messy, but it works surprisingly well.
Until lots of people have IPv6, an IPv6 address doesn't have any benefit. It's a catch-22 situation.
With an IPv4 reverse proxy solution (socks or otherwise), you can run a server right now and it will be visible to everyone, right away.
And that's it. There's no need for ISPs to route you IPv6, or to set up tunnels. No need for dual stacks and AAAA records. No need for service providers to provide IPv6 access to their servers.
SOCKS is less restrictive than NAT - the client can know about it and find their external IP/port, it allows incoming connections, it lets the gateway device authenticate users and give them differing quality of service, etc.
The real issue here is running out of IPv4s.
We don't really need more IPs for clients - NAT fixes that problem (I just argue that SOCKS could be a better solution, that can work alongside NAT).
We need more IPs for servers. The IPv6 solution is to move clients and servers to IPv6. 6in4 gets around needing to migrate the ISP as well, which is good, but it's still a heap of work that has to be done by people who don't get any material benefit out of it for years, at best. So it won't happen.
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 once 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.
So it's in my best interests to wait until I have to.
Which means I'll continue to use IPv4.
Which means the sites I want to connect to aren't motivated to turn off IPv4.
Ad infinitum.
What would I propose for that?
* 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).
* 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
* 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.
