> Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity.

Funny, because the reality is that the software has for the most part been written and the hard part is acquiring v6 addresses. The problem is it isn't just a matter of acquiring a v6 address, it's also supporting the software that the v6 address runs on, and having it work the exact same way as v4.

    The answer is that I'm actually talking about a huge number of IPv4 sites. There's nothing special about my site. When the same situation is repeated at N sites, the code is written only once, while the trivial requests and the trivial configuration changes are repeated N times.
    .
    .
    .
    Well, I'm looking at a much larger group of users, and most of them aren't putting even five seconds into IPv6. They have better things to do. If the IPv6 configuration isn't automatic, it won't happen.

> So why not go for the inverse approach for new servers? Only give the servers IPv6 addresses and for those servers that still need to be reached via the public IPv4 internet (most internal ones probably have no need of this) can be accessed via SIIT, which performs stateless mapping between IPv4 and IPv6 (for example IPv4 1.2.3.4 gets translated to IPv6 2001:db8::1.2.3.4 and vice versa).

I'm unfamiliar with SIIT, but I bet it doesn't get us closer to the "magic moment" or we would be flocking to IPv6 addresses:

    The magic moment for IPv6 will be the moment when people can start relying on public IPv6 addresses as replacements for public IPv4 addresses. That's the moment when the Internet will no longer be threatened by the IPv4 address crunch.