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.