<!--StartFragment-->
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.
<!--EndFragment-->
Jeff Doyle is president of Jeff Doyle and Associates, an IP network consultancy. Jeff is the author of Routing TCP/IP, Volumes I (read an excerpt) and II and of OSPF and IS-IS: Choosing an IGP for Large-Scale Networks. He is a frequent speaker on IPv6, MPLS, and large-scale routing.
No end user benefits
No such thing as a IPv6 only killer app. Anything which currently runs over IPv4, will run over v6 just fine. The app only needs to be modified to change IP addressing. Nothing hugely major. We're only talking about layer 3 IP and transport. We're not talking about layer 7 application or presentation. Those things are independent of what shuffles the data across the Internet.
Changing over to IPv6 isn't something you can or should sell to the end user. It should be sold to the network managers/CTO's. There are mostly IT related benefits involved, with very little having anything to do with the average Joe. Those benefits include: native IPSEC encryption, elimination of NAT, address auto assigning (elimination of DHCP)
Furthermore, converting IPv4 networks to v6 can take place at the router, eliminating the need for all end nodes to be v6 compliant. That is, at least until the nodes can be upgraded/replaced.
Yes, the slow conversion to IPv6 will likely be painful as well. But the benefits of doing so will be felt for the next 50 years. We shouldn't need some killer-here-today-gone-tomorrow app to push us into upgrading.
The sooner the better I say.
conversion at router
Conversion of IPv6 to IPv4 at the router is not trivial, since NAT-PT is depreciated.
Other advantages are superior ipv6 multicast, reachability by ipv6-only clients.
conversion at router
Note the initial comment was regarding converting the network over, not individual packets.
Converting the network to IPv6 should be done by enabling IPv6 at the router without disabling IPv4. The large majority of end-devices which are already there and waiting for IPv6 connectivity are dual-stack and can seamlessly prefer IPv6 when its usable and IPv4 when they need to.
You can then experiment making individual applications dual-stack as well. Start with the low-level admin, security, and tracking ones and grow it out. To watching your network morph from IPv4-only to IPv6 with outsiders stuck on IPv4 being the only residual need to keep any v4 at all.
You can then repeat the process with glee turning all the unused IPv4 services to IPv6-only.
I speak with 18 months experience here. The whole process took me under 10 days for an entire cable+wifi+colo+dmz network.
The biggest two problems were getting a stable tunnel, and making myself ignore the IPv4-only devices once I got the conversion itch.
The "killer " app
the killer app will be multicast over ipv6 something like
the "democracy broadcaster" IMHO
just my 2 cents