Over the years there have been an enormous number of pilot and showcase projects around IPv6. Japan’s WIDE Project probably holds the distinction of the most IPv6-related programs. Under the leadership of Professor Jun Murai of Keio University, WIDE’s projects have ranged from the development of stable IPv6 stacks such as KAME (home of the famous dancing turtle) and USAGI to TAHI, the most widely used IPv6 conformance verification software, to showcase projects such as InternetCAR and the famous Yokohama taxi experiment.

While such projects highlight IPv6, there is an interesting contradiction in the practical implementation of IPv6: It should be invisible to its users.

The way I’ve been putting it in my own presentations is that for the most part, users do not care about IP or even know what it is; users care about services. To users, IP is just the unseen plumbing inside the walls.

Or to put it yet another way (and I forget where I heard this), you do not need to be a mechanic to drive a car. My wife knows next to nothing about what goes on beneath the hood of her automobile, yet she can operate it just fine. In fact if she were required to open up the hood and tinker with the engine before driving, she would use it much less.

So on the one hand, we IPv6 advocates have an urge to showcase the advantages of IPv6 over IPv4; on the other hand, service providers who simply see IPv6 as a technical necessity to the continuance of their business distinctly want to avoid IPv6 visibility: As IPv6 is implemented, they want it to be as transparent to their users as possible. As services begin being delivered over IPv6, users must not be required to go out of their way to continue getting the services they are accustomed to using.

“IPv6 killer applications” might be out there somewhere, but for now there are really no applications that work only with IPv6 that are attractive enough to cause users to go to any special trouble to enable IPv6 on their systems.

And there’s the challenge. Windows Vista works pretty much seamlessly with IPv6, but there are plenty of users of other operating systems – including my beloved MAC OS – that have at least a few problems with IPv6. Then there’s the problem of enabling IPv4-only users and services to connect with IPv6-only users and services. If the implementation of IPv6 causes an application to break, or creates a roadblock between a user and a service he wants, the implementation must be considered unsuccessful.

I had a discussion the other day with Arthur Xiang, the CTO of Digital China’s R&D Center. Digital China is a router and switch manufacturer who sells primarily to Chinese academic networks. (CERNET, the network interconnecting universities throughout China, was an early adopter of IPv6). Mr. Xiang tells me that on the campuses they entice students to use the IPv6-only network by making it free, while charging for the IPv4 network. The content available on the IPv6-only network is primarily entertainment that appeals to students, such as high-definition movies and NBA basketball games.

That sounds, at first, like an attractive incentive for attracting users to IPv6: Free service and access to content not available on the IPv4 network.

Unfortunately, that won’t fly in the commercial world. Service providers are unlikely to spend the money necessary to make their networks IPv6 capable and then give that capability away for free. Even structuring it as a “limited time offer,” in which the IPv6 service is free for, say, the first year, is risky because users are more likely to just switch back to IPv4 when the free offer expires.

And trying to make content or services available only over IPv6 can be a competitive liability: Should the content prove popular, a competitor could come along and offer the same content over IPv4, removing the special incentive.

And finally, there is still the problem of transparency. Mr. Xiang tells me that in order for students to use the IPv6 services, they must attend training to learn how to set up for the dual-network access. Commercial users are not likely to tolerate having to be trained to continue using Internet services.

So the bottom line is that we can wait for some “IPv6 killer app” to justify the transition, and continue waiting right up to the time IPv4 addresses run out. Or we can work on IPv6 deployment now, working n the hard problem of making it completely invisible to the end-user. A successful IPv6 implementation means that at the end of the project, your users should have no idea whether the services they are using are being delivered over IPv4 or IPv6. To them, they’re just services.