IPv6 deployment faces a number of challenges, including: 1) the IPv6 costs and risks, 2) the fact that NAT is required to incrementally deploy IPv6 yet appears to eliminates the need for IPv6, and 3) the inability to really use the IPv6 features effectively during incremental deployment. This section considers possible initial deployment scenarios to illustrate the difficulties and then discuss some further risks.
One view is that IPv6 should be first deployed at the enterprise level. However, to deploy IPv6 in some portion of the corporate network would require network address translation between the IPv6 portion and the ``legacy'' IPv4 portion, including the rest of the Internet. However, given network address translation, it would be lower risk to instead deploy more IPv4 using a private address domain and thereby gain sufficient addresses for the immediate enterprise needs. This route would eliminate the risks of disrupting the end hosts, routers and multi-layer switches, and network management systems to upgrade to IPv6. NAT-based solutions are widely deployed and well-understood whereas IPv6 support is still largely experimental. Thus, it seems difficult to get IPv6 deployed initially in an enterprise network.
Another view is that IPv6 should be deployed first in the backbone of the Internet. Yet, this appears to expose the ISP to unjustified costs and risks. The backbone has relatively few nodes so it does not have the demand for addresses to compel going to IPv6. Moreover, the ISP would have to support both IPv4 and IPv6 unless its customers simultaneously convert. (Dual-stack mechanisms and tunneling consume extra network and human resources over supporting just IPv4.) Finally, the ISP would have to provide backbone routers with adequate performance. However, there is no existing market for such products and relatively little investment in this direction because there is no significant amount of IPv6 traffic. So, it is not clear where and when an ISP would get these routers from even it decided to convert to IPv6.
Yet another view is that IPv6 might be widely deployed by some wireless
service such as cellular phones.
However, this move would incur higher packet overhead
unless header compression can be very effective
.
Also, the average packet size with wireless tends to be smaller,
both because the technology and because voice uses small packets.
Moreover, a key challenge with wireless is dealing with many units collecting
in the same cell, whether they are cell phones, wireless appliances in the
home or other wireless mobile devices.
If IPv6 does increase the packet overhead significantly,
it effectively reduces the maximum number of units that can be served per
cell in the worst case, thus increasing the cost.
Moreover, wireless only has to transmit to the nearest (wired) receiver,
which offers an opportunity to translate the
packets to another format for the wired infrastructure,
as proposed in the widely supported WAP standard [19].
The arguments for IPv6 based on autoconfiguration may also be less compelling
given that wireless devices have to authenticate themselves when entering
a realm, giving ample mechanism and opportunity to do
DHCP-like address assignment at that point.
Finally, having fixed IPv6 addresses for mobile hosts is mostly interesting
to support mobile IP, yet mobile IP has received relatively little
deployment to date, given the routing difficulties and solutions
that exist at the higher level.
Until mobile IP is more compelling and excessive header overhead is
shown to not be an issue,
or until another compelling reason is identified for IPv6 on cellular phones,
it is hard to see IPv6 being deployed in this domain.
A final view is that some country such as China will so desperately need
addresses that it would deploy IPv6.
However, this scenario raises a number of issues.
To communicate with the rest of the existing Internet,
China would require sufficient (global) IPv4 addresses in any case
for NAT-based communication from its internal IPv6 to these IPv4 addresses.
However, if it has these addresses,
it would be far easier to run the whole country behind a NAT boundary
using IPv4 addresses,
given that that would allow the use of existing routers, switches and
host software.
It seems inadvisable for a country with limited Internet expertise and
industry
to commit to the least proven technology and possibly be forced to largely
develop its own products, especially with uncertain prospects
of other markets for these products.
Besides all the above impediments to deployment, there are significant technical risks to deploying IPv6, in part because of the ancillary changes made compared to IPv4 besides just the change in address size. Although the IPv6 work has shown admirable restraint in avoiding gratuitous changes over IPv4, there are enough of these differences from IPv4 to have legitimate concern that unanticipated problems will arise, given that existing applications were designed, debugged and deployed up based on IPv4.
In particular, with IPv6, the address assignment in the high-order 64 bits is allocated to ISPs so, if an enterprise network is served by two ISPs (for fault-tolerance or choice of service), every IPv6 host in the enterprise is effectively multi-homed, with two separate addresses per host, one for each of the ISPs. If one of the ISP's service fails, the addresses used by those sending to this network have to change to those associated with the other ISP for fail-over to occur, unless one of the complex tunneling or rerouting schemes currently being researched to handle this problem can be made to work reliably, or some other solution is available.
IPv6 introduces a privacy risk because it encodes information in the addresses, making this information externally visible. For instance, with IPv6, one can determine a company's ISP based on the addresses used by its hosts. IPv6 also makes every host that uses multiple ISPs effectively multi-homed. IPv6 addresses can also encode MAC addresses that can reveal the manufacturers of the Ethernet interfaces in the hosts. These issues have already caught the attention of privacy groups.
IPv6 relies on ``renumbering'' [6] for efficient routing to keep the mapping of address to topology reasonably compatible. It is reasonably considered a research issue because there is no prior system to the authors' knowledge that has proven this is in fact practical.
IPv6 also changes the way that options and IP fragmentation are handled. In particular, IPv6 disallows fragmentation at intermediate hops, making it even more difficult to use multicast efficiently in a highly diverse environment. Some networks impose fragmentation on large packets to provide delay guarantees for latency-sensitive traffic. This fragmentation may only come into play when such applications are running. It seems inappropriate to force a small MTU on a distant multicast source, for all receivers, just because a local low bandwidth link is carrying voice, for instance.
The large IPv6 header also introduces significant overhead and risk in some network settings. Besides the overhead in low bandwidth settings and/or risk that header compression will not be effective, the larger header may cause some applications with fixed packet sizes, like those tuned to Ethernet maximum packet size, to incur fragmentation at the IP level because of the larger header, a further deployment risk. IPv6 requires extensive changes to existing end-user host software and the network infrastructure of routers, switches, firewalls and network management. This IPv6 software and equipment is far less tested, less well-supported and far less cost-effective than the comparable IPv4 facilities.
Furthermore, routers are making a rapid transition to hardware support for
IPv4 wire-speed forwarding, especially for core or backbone routers.
There is the risk that IPv6 hardware support will be lagging and
far more expensive,
leading to substantially lower performance and/or much higher cost.
Finally, early adopters risk being orphaned if IPv6 is not be widely deployed soon after they make the move, incurring the cost of backing out of IPv6 as well as the risks and costs of conversion. The lack of IPv6 deployment to date provides empirical support to the above concerns.
Given mission-critical nature of networks and the rapid growth of traffic that most networks are confronting, few can afford to take on the IPv6 challenges and risks at this time.