Why IPv6 has not been deployed on a large scale is discussed by Geoff
Huston in this article for the Cisco Internet Protocol Journal. Huston
examines the timing of the IPv4 address exhaustion and the nature of
the intended transition to IPv6 as well as considering the shortfalls
in the implementation of this transition, and identifying their
underlying causes. Finally he considers the options available at this
stage and identify some likely consequences of such options.
Using figures from August 2008, Huston says the anticipated rate of
increasing address consumption will see the remaining unallocated
addresses that are held by IANA reach the point of exhaustion in
February 2011. The most active RIRs are anticipated to exhaust their
locally managed unallocated address pools in the months following the
time of IANA exhaustion. However there is uncertainty in his prediction
that could come about from last minute acceleration of demand,
activities of the recipients of the one per cent of recipients who
received 50 per cent of the allocated address space and lastly, that
the policy for address allocation does not change.
The transition process is also examined, with a "dual stack" transition
process where more and more hosts use both IPv4 and IPv6 simultaneously
and revert to use IPv4 only when an IPv6-based end-to-end conversation
is not possible. As more and more of the Internet converts to dual
stack, it is anticipated that use of IPv4 will decline, until support
for IPv4 is no longer necessary.
"Clearly, waiting for the time of IPv4 unallocated address pool
exhaus¬tion to act as the signal to industry to commence the deployment
of IPv6 in a dual-stack transition framework is a totally flawed
imple¬mentation of the original dual-stack transition plan."
Huston also looks at why the current situation has arisen. Reasons
given are "a perception of the technical imma¬turity of IPv6 as
compared to IPv4. It is certainly the case that many network operators
in the Internet are highly risk-adverse and tend to operate their
networks in a mainstream path of technologies rather than constantly
using leading-edge advance releases of hardware and software
solutions." Another possible reason why industry has not engaged in
dual-stack transition deployment is that of the business landscape of
the Internet. Huston then gives an explanation that involves new
players in a "deregulated industry searching for a competitive edge to
unseat the dominant position of the traditional incumbents found the
Internet as their competitive lever."
The value of IPv6 is not something that was ever meant to be visible to
the end user Huston writes. And how the average internet user uses the
internet will not change whether they use IPv4 or IPv6. "Email is
e-mail and Web-based delivery of services is just the Web. Nothing will
change that perspective in an IPv6 world, so in that respect customers
do not have a particular requirement for IPv6, as opposed to a generic
re¬quirement for IP access, and will not value such an IPv6-based
access service today in addition to an existing IPv4 service."
Huston says the current situation has come about from "an inability of
a highly competitive deregulated industry to be in a position to factor
longer-term requirements into short-term business logistics."
In the future, there will be a need for both IPv4 and IPv6 to be used. Even when IPv4 addresses are exhausted.
Huston concludes the shortage of IP addresses will be an effective
barrier for new ISP entrants or that addresses will change hands for
money, that is, a market will develop for addresses. He says there is
"one remaining mechanism that will motivate the industry to
significantly increase the address usage efficiency: monetizing
addresses and exposing the costs of scarcity of addresses to the
address users. The corollary of this approach is the use of markets to
perform the address distribution function, creating a natural pricing
function based on levels of address supply and demand."
To read this 7,500 word article by Geoff Huston in full in Cisco Internet Protocol Journal, see cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-3/ipj_11-3.pdf.



