Technical and Economic Assessment of Internet Protocol Version 6 (IPv6)

 

Benefits and Costs

2  of Adopting IPv6
 
 
   

Industry stakeholders and Internet experts generally agree that IPv6-based networks would be superior to IPv4-based networks.  The increased address space available under IPv6 could stimulate development and deployment of new communications devices and new applications, and could enable network restructuring to occur more easily. The redesigned header structure in IPv6 and the enhanced capabilities of the new protocol could provide significant benefits to Internet users, network administrators, and applications developers.    IPv6 could also simplify the activation, configuration, and operation of certain mobile networks and services.

Widespread adoption of IPv6 would likely entail substantial transition costs, because the Internet today is comprised almost entirely of IPv4-based hardware and software.  Furthermore, as noted above, many of IPV6’s enhanced capabilities have also been made available in IPv4.  As a result, producers and consumers may continue to use IPv4 for some period of time (perhaps with further augmentation) to avoid or to defer the costs of upgrading to IPv6.  Many of the prospective benefits of IPv6, moreover, appear to be predicated on the removal or modification of Network Address Translation (NAT) devices (see Section 2.1.1), and modification of firewalls and other "middleboxes" that affect direct communications between end-user devices via the Internet.  It remains to be seen whether or when such devices will be either phased out or made transparent to end-to-end (E2E) Internet communications and applications.

In this section, we discuss the benefits and costs of adopting IPv6.  After first evaluating the potential benefits of deploying IPv6, we discuss the nature and relative magnitude of the costs that enterprises and individuals may incur to deploy IPv6.  To make this general discussion more concrete, we also provide a case study that illustrates potential transition costs for a small or medium-sized business.  Finally, we discuss transition issues and costs that are of particular importance in assessing the net economic impact of adopting IPv6.  We intend to supplement this general benefit-cost analysis with a more detailed assessment to be conducted in the next stage of our work.

2.1   Relative Benefits of IPv6 vs. IPv4

There appears to be a general consensus about the types of benefits that could follow from widespread adoption of IPv6.  There is, however, disagreement about the size of those benefits and whether the incremental benefits of IPv6 (versus IPv4) for some or all users would outweigh the costs of an accelerated transition from IPv4 to IPv6.^[1]  This section discusses the potential net benefits of adopting IPv6, as identified by RFC commenters, RTI interviews, and the available literature. 

                                      2.1.1  Increased Address Space

The principal by-product of deploying IPv6 would be a large increase in the number of available IP addresses.  The 32-bit address field in the IPv4 packet header provides about 4 billion (4x10⁹) unique Internet addresses.^[2]  The 128-bit address header in IPv6, in contrast, provides approximately 3.4x10³⁸ addresses, enough to assign literally trillions of addresses to each person now on earth or even to every square inch of the earth’s surface.^[3]

The vast pool of addresses available under IPv6 would, at a minimum, "future proof" the Internet against potential address shortages resulting from the emergence of new services or applications that require large quantities of globally routable Internet addresses.^[4]  In this regard, there are reasons to believe that demand for IP addresses could expand considerably in future years.  The very success of the Internet will likely increase pressures on existing IPv4 address resources, as more and more people around the globe seek IP addresses to enjoy the benefits of Internet access.^[5]  The burgeoning demand for “always-on” broadband services (e.g., DSL and cable modem services) and the expected proliferation of wireless phones and wireless data devices (e.g., personal data assistants [PDAs]) may further deplete the available IPv4 address space.^[6]  If consumers are drawn to devices (e.g., smart appliances, in-home cameras and entertainment systems, automobile components or subsystems) that can be remotely accessed and controlled via the Internet and that require fixed, globally accessible Internet addresses, the demand for IP addresses may overwhelm the remaining pool of IPv4 addresses.^[7]  Although it is difficult to predict whether or when these developments may threaten the existing supply of IP addresses, the availability of virtually unlimited IPv6 addresses would enable Regional Internet Registries (RIRs)^[8] and Internet service providers (ISPs) to accommodate any sharp spike in demand.

At the same time, adoption of IPv6 could provide an opportunity to reform and rationalize the current system for allocating Internet addresses, because IPv6 would create a vast new and unpopulated address space.  The historical allocation of IPv4 addresses has provided organizations in North America, Europe, and Australia with the majority of currently assigned IPv4 address blocks.  A large portion of those addresses remain unused.  Although, as discussed below, current allocation policies have improved, no incentives have been created to prevent “warehousing” of IP addresses^[9] or to encourage the return of unused IP addresses.  As a result, many organizations still have very large address blocks that have never been fully used and may never be reclaimed in the absence of concerted action by governments or by Internet registries.^[10]  Deployment of IPv6 creates an opportunity to use the lessons learned from the past to develop more efficient allocation policies for IPv6 addresses.

Finally, the massive increase in IP addresses made available by IPv6 deployment could reduce the need for NATs.  A NAT is a hardware device often placed between a private network and the Internet to allow a large number of hosts on the private network to share a smaller number of globally routable, “public” IP addresses for communications over the Internet.^[11]  For internal communication, each host is assigned a locally-unique private IP address (see Figure 2-1).  As the term implies, a NAT converts the private source address in outgoing communications to a

Figure 2-1.  NAT Operating between a Private Network and the Internet

 

globally routable IP address.  In many implementations, an external address is assigned only for the duration of a communications session originated by an internal host, and the internal host cannot receive communications originated from the outside.  Because NATs are an effective way for many hosts to share a single or a small group of public IPv4 addresses, they have proven to be a popular way to slow the consumption of IPv4 addresses.  Because adoption of IPv6 would eliminate concerns about address conservation, NATs would not be needed for that purpose in an IPv6 environment.^[12]

Although NATs provide benefits for end users, as discussed below, they also complicate the use and development of new E2E networking applications.^[13]  Without NATs, applications such as Voice-over IP (VoIP) and real-time videoconferencing could be implemented much more simply, because a direct connection (i.e., IP address to IP address) could be initiated to any host, without the need to establish additional protocols and procedures to traverse one or more NAT devices.  Some commenters assert that without NATs, various features of IPv6 (such as connectivity via a wider range of media and delivery mechanisms, the ability to maintain several simultaneous access paths for multiple parties without manual intervention, improved speed, and quality of connections) could spur the deployment of new E2E applications.^[14]

Indeed, advocates contend that widespread deployment of IPv6 (and removal of NATs) would permit a return to the original “open scheme” of the Internet, based on E2E connectivity.^[15]  One commenter suggests that the existing IPv4 infrastructure can be compared to the code of a large software application—after years of adding work-arounds and patches, it is sometimes simpler to replace the application and develop a streamlined program with which to move forward, rather than to continue patching.^[16]  Representatives of Nortel Networks have stated that designing the next generation of Internet applications will be simplified when using IPv6 because it avoids the more than 20 years of work-arounds embedded in IPv4, in part, to support E2E applications.^[17]

Supporters of IPv6 also believe that, to the extent that use of IPv6 obviates the need for NATs, adoption of IPv6 would stimulate the development and deployment of innovative E2E applications.  This would occur, they claim, because applications designers would be able to “focus on core products and services, rather than network logistics.”^[18]  More specifically, designers could avoid the time and effort needed to develop work-arounds that enable specific E2E applications to operate in a NATed environment.  IPv6 supporters contend that those work-arounds may not scale well in all environments,^[19] may reduce the performance and robustness of the associated applications, and may increase the cost and complexity of network management.^[20]  In their view, if designers are not distracted by the need for NAT work-arounds, new services and applications could be brought to market quicker and at a lower cost.

Although deployment of IPv6 promises significant benefits from the concomitant increase in address space, several factors may limit full realization of those benefits, at least in the near term.  For example, although concerns about IPv4 address exhaustion drove development of IPv6,^[21] steps have been taken to conserve addresses and to improve the efficiency of address allocation.^[22]  As a result, many observers believe that the United States, Western Europe, and Australia may not experience address space concerns for some time.^[23]  Even in those areas of the world that are most concerned about potential exhaustion of IPv4 addresses (e.g., India and the Pacific Rim countries), some observers still question whether the problem is so severe as to warrant accelerated adoption of IPv6.^[24]

Additionally, in response to concerns about the perceived shortage of IPv4 addresses stemming from historical address allocation policies,^[25] the Regional Internet Registries (RIRs) have reorganized themselves in recent years to ensure that, prospectively, all regions are allocated IP addresses through a fair, transparent, and efficient process.^[26]  IPv4 address blocks are currently allocated to the RIRs from a common global pool, using agreed upon criteria and methodology.^[27]  When a region requests more addresses, they are allocated to the RIR on a need-justified basis.^[28]  As a result of these changes, the regional distribution of remaining IPv4 addresses now mirrors the global distribution of IP networks themselves.  Consequently, the allocation scheme should no longer be the cause of any perceived regional shortages of IPv4 addresses.^[29]

To capture fully the address benefits of IPv6, stakeholders will need to take early steps to create mechanisms that allocate IPv6 addresses fairly and efficiently.  The North American IPv6 Task Force (NAv6TF) indicates that some organizations have had trouble getting IPv6 addresses recently and suggests that allocation procedures may need to be changed so that IPv6 addresses can be obtained more easily.  Otherwise, NAv6TF avers, widespread IPv6 adoption (and the potential associated benefits) might be stalled or precluded.^[30]  At the same time, VeriSign emphasizes the need for allocation policies that discourage “warehousing” of IPv6 addresses to prevent inefficient consumption of those addresses.^[31]

More importantly, adoption of IPv6 may not prompt a return to the “open architecture” originally envisioned by the designers of the Internet.  In fact, as the commercialization of the Internet has proceeded, the network has diverged considerably from the original end-to-end design, and there is little evidence that a substantial number of stakeholders want to return to that design.^[32]  Although NATs may frustrate application designers and service providers, users and network administrators often realize economic and security-related benefits from using NATs in their networks.  By reducing the number of “public” Internet addresses that an organization may need, use of NATs can reduce that organization’s payments to Internet service providers (ISPs) for address space.  Moreover, although it was not their original purpose, NATs are often used to provide anonymity for a network and its hosts.  In effect, NATs provide a form of “security through obscurity,” thereby enabling network operators to block externally initiated contacts and to hide internal hosts.^[33]  Networks that adopt IPv6 may therefore be reluctant to dispose of their NATs, even if address conservation is no longer a concern.

Additionally, concerns about security in the rambunctious Internet environment have prompted organizations to deploy a range of “middleboxes” (e.g., firewalls, intrusion detection and prevention systems) that, like NATs, break or purposely inhibit E2E communications.  Indeed, those devices have become essential elements of most current enterprise networks and are commonly used to enforce network security policies that have emerged since the Internet was first developed.^[34]  Few, if any, network operators will be likely to remove those devices should they decide to implement IPv6.  In short, the ability to exploit the virtually unlimited IPv6 address space to support a growing number of networked devices or to stimulate development of innovative E2E Internet applications and services will likely be offset by several relevant factors—a continuing supply of IPv4 addresses, any perceived difficulties with obtaining IPv6 addresses, a possible reluctance to eliminate NATs and other middleboxes that affect E2E applications, and an absence of compelling applications that require E2E connectivity.

                                      2.1.2  Increased Security

A number of commenters contend that IPv6 will provide a greater level of security than is available under IPv4.  NTT/Verio states that because IPv6 was “designed with security in mind,” it is inherently more secure than IPv4, which does not have integrated security fields.^[35]  Other commenters note that support for Internet Protocol Security Architecture (IPsec) is “mandatory” in IPv6, but only “optional” in IPv4, which should lead to more extensive use of IPsec in IPv6 networks and applications.^[36]  BellSouth suggests that incorporating IPsec into the IPv6 protocol stack may reduce incompatibility between different vendors’ implementations of IPsec.^[37]

Widespread deployment of IPv6 may indeed produce security benefits in the long term.  The near-term benefits are less clear, however.  Although IPsec support is mandatory in IPv6, IPsec use is not.  In fact, many current IPv6 implementations do not include IPsec.^[38]  On the other hand, though optional, IPsec is being widely deployed in IPv4.^[39]  Several commenters state that there are no significant functional differences in the performance of IPsec in IPv6 and IPv4 networks.^[40]  Any differences in performance are attributable to the presence of NATs in most IPv4 networks, which interfere with E2E communications using IPsec.^[41]  Thus, to the extent that NATs persist in IPv6 networks, they may reduce the security benefits available via the new protocol.^[42]

The principal impediment to widespread use of IPsec appears to be the absence of a public key infrastructure (PKI) and associated trust models, which are necessary to effectively manage widespread IPsec operations.^[43]  In this regard, the social and business aspects of establishing identities and trust relationships (e.g., privacy concerns and legal considerations) will likely be more difficult to resolve than the technical issues.^[44]  Until these issues are resolved and the required security infrastructure is created, IPv6 is not likely to stimulate any more use of IPsec than IPv4 does today.^[45]

Furthermore, experts generally agree that implementing any new protocol, such as IPv6, will be followed by an initial period of increased security vulnerability and that additional network staff will be necessary to address new threats posed by a dual network environment.^[46]  IPv4 currently benefits from 20 years of identifying and addressing security issues.  As IPv6 becomes more prevalent, many security issues will likely arise as attackers give it more attention.  On the other hand, the experience gained from running IPv4 networks will help bring security levels in IPv6 networks up to the level of current IPv4 networks fairly rapidly.^[47]

The implications of IPv6 and IPsec deployment for law enforcement are similarly ambiguous.  Widespread use of IPsec to encrypt communications may reduce law enforcement agencies’ ability to monitor criminal activities over the Internet, particularly when IPsec is used in conjunction with IPv6 mobility.^[48]  To the extent that deployment of IPv6 enables the assignment of static IP addresses to most or all end-user devices, adoption of IPv6 could enhance the traceability of illegal or harmful communications back to their source.^[49]  Users could still employ NATs to give themselves some anonymity, even in IPv6 networks, and thus limit traceability of their communications.^[50]  Furthermore, IPv6 has a “privacy extension” option in its autoconfiguration feature that enables users to randomize their IPv6 addresses or to generate temporary addresses that are independent of the identification label embedded in user devices.^[51]  Such addresses are traceable to the ISP or customer demarcation point but are more difficult to trace beyond those points.  As a result, it may be challenging for law enforcement authorities to trace a specific node or device as it moves between attachment points or over extended periods of time.^[52]  Authorities will have to develop new tools and procedures to address these potential problems.^[53]

In summary, it is likely that in the short term (i.e., the next 3 to 5 years) the user community will at best see no better security than what can be realized in IPv4-only networks today.  During this period, more security holes will probably be found in IPv6 than in IPv4, and IPv4 networks will continue to have at least the same level of security issues as they do currently.  In the long term, however, security may well increase as a result of increased use of IPsec.

                                      2.1.3  Simplified Mobility^[54]

Various commenters anticipate a rapid growth in the potential number of mobile or portable devices that may connect to the Internet.  NTT/Verio notes that the use of mobile phones for email and database browsing in Japan has been growing rapidly.^[55]  Sprint suggests that the emergence of mobile data services such as wireless data, picture mail, and text messaging could drive the adoption of IPv6.^[56]  Motorola argues further that IPv6 offers exciting opportunities for wireless sensor networks and for machine-to-machine communications, potentially leading to a large proliferation of devices that will connect to the Internet.^[57]   

Many experts believe that, whether used in a mobile or a portable environment, IPv6 can better support such devices than currently available options under IPv4.^[58]  According to Microsoft, “IPv6 better handles mobile applications and services.” ^[59]  NAv6TF suggests that IPv6 allows devices to attach to networks at different points more easily than is currently achievable using IPv4 alternatives, principally through the use of stateless address autoconfiguration and neighbor discovery capabilities.^[60]  Sprint suggests that IPv6 will permit more optimal routing of mobile traffic because IPv6 mobility specifications are being designed to eliminate “triangular routing.”^[61]  The simplification of mobile networking in IPv6 could enable Internet users to remain seamlessly connected and easily reachable when portable or mobile devices move from their home networks to other unaffiliated networks.^[62]   The possibility of continuous Internet connectivity for laptops, mobile phones, PDAs, sensors, and other mobile or portable devices, in turn, could spur development of myriad new applications in both the public and private sectors.

                                      2.1.4  Improved Quality of Service (QoS)

Internet transmission currently is a “best effort” scheme—users cannot expect that “high priority” traffic will be handled any differently from other traffic.^[63]  For business IP-based services to flourish, service providers will likely need to provide quality of service (QoS) support for those customers.  This would require, among other things, the ability to identify different classes of traffic and to provide sufficient instructions to the connecting networks so that messages are delivered with acceptable performance characteristics (e.g., error rates, delay).^[64]

The evidence suggests that, as presently implemented, IPv6 provides no better QoS support than does IPv4.^[65]  However, the IPv6 packet header contains a field—the “flow label”—that is not found in IPv4 and that is intended to assist with QoS.  The flow label allows a user or provider to identify, with greater specificity (or “granularity”) than is available under IPv4, those traffic flows for which the provider requests special handling by network routers.^[66]  The IETF has not yet finalized the standards needed to enable developers and service providers to use IPv6’s expanded QoS capabilities.  According to IETF RFC 2460, “There is no requirement that all, or even most, packets belong to flows, i.e., carry non-zero flow labels [such as QoS] . . . [and] protocol designers and implementers [should] not assume otherwise.”^[67]  One expert has indicated, however, that “without the flow label and hop-by-hop option processing of IPv6, [optimal QoS operations] would not be possible.”^[68]  Accordingly, more work, particularly more standardization work, is needed before any potential QoS benefits of IPv6 can be realized.^[69]

Another constraint on the widescale implementation of QoS, either in IPv6 or IPv4, would be the lack of QoS support in any network segment in the transmission path.  Such a deficiency could negate QoS gains realized in the rest of the network path.  From a commercial standpoint, moreover, service providers will not offer QoS support unless the offered differential in service quality translates into increased revenues from customers (i.e., only if QoS utilization translates to improved service for the user and higher revenue for the provider).

                                      2.1.5  Reduced Network Administration Costs

Experts have suggested that IPv6 will reduce network administration costs in the long run if enterprises reorganize their networking structure and operating processes to take advantage of IPv6’s capabilities and remove NATs from their networks.^[70]  For example, the autoconfiguration feature available in IPv6 can simplify the connection of hosts and other devices to the Internet, thus reducing management overhead for network administrators.^[71]  The vast number of addresses available under IPv6 could simplify (and thus reduce the costs of) subnet management because each subnet could be given substantially more address space than the number of nodes that could be connected to it.^[72]

If adoption of IPv6 motivates an organization to dispense with NATs, network administrators could more effectively use ping, traceroute, and other tools to diagnose network problems or to debug applications between pairs of hosts.^[73]  Removal of NATs could also simplify use of multivendor networking solutions.^[74]  Furthermore, decreasing the number of processing functions in a network (e.g., by eliminating NATs) could reduce the number of components that can fail, increase network resilience, and reduce management complexity and support costs.^[75] 

To the extent that the administration cost savings of IPv6 depend on the removal of NATs, the potential savings may be constrained by the likely persistence of those devices in an IPv6 environment.  More generally, immediate reductions in administrative costs flowing from adoption of IPv6 will probably not offset the costs of transition to IPv6,^[76] although the cumulative savings could eventually exceed transition costs.  Most networks will likely not see a net reduction in costs for at least 5 to 10 years after initial IPv6 deployment, depending on the priority assigned to upgrading of systems, specific network complexities, and other issues that could arise during transition.^[77]  Additionally, some experts have stated that there will not be aggregate administrative reductions because new IPv6 issues related to new/advanced applications and projected increases in Internet traffic could require added costs, including additional administrative activities.^[78]  However, this development still implies a decrease in the cost per unit of information exchanged.

In summary, during the extended transition period in which IPv4 and IPv6 support will be required, the operation expense (OPEX) for network operations will likely see a measurable increase not decrease.  Any OPEX cost reduction will probably not be realized until significant operational experience has been gained at all levels of the network, including the application developer and user levels.  This may not accrue for 10 or more years, if ever.^[79]

                                      2.1.6  Increased Overall Network Efficiency

Removal of NATs would likely result in fewer processing steps and reduced transmission bottlenecks.^[80]  The change to a fixed header size in IPv6 could yield processing efficiencies, and deployment of IPv6 could also allow routing tables to be reduced in size and redesigned for maximum efficiency.^[81]  Some experts have said that such benefits will result only when IPv6 use is widespread.^[82]  The potential increase in overall network efficiency, moreover, may be difficult to correlate with adoption of IPv6.  A much better benchmark, and the metric of greatest interest to the user community, is whether the performance of E2E and other applications improves significantly when using IPv6 transport.

                                      2.1.7  Summary

As the foregoing discussion indicates (and as Table 2-1 summarizes) adoption of IPv6 can potentially produce measurable benefits for users, equipment vendors, and service providers.  The largest likely benefits will be realized in the areas of increased address space (and associated

 

Table 2-1.  Overview of IPv6 Benefits

Benefits	Magnitude of Potential Benefits	Timing Issues	Likelihood of Occurrence	Key Factors in Realizing Benefits of IPv6
Increased address space	Large	U.S. does not face a near-term shortage	Medium/High	Removal of NATs Growth in number of end-to-end and other applications
Simplified mobility	Large	New applications will likely flow from Asian test markets	Medium/High	Growth/demand for new applications
Reduced network administration costs	Modest	Cost may increase during transition	Medium (in the long term)	Removal of NATs
Increased security	Modest	Unclear when large scale adoption of IPsec will occur	Low/Medium	Development of PKI Removal of NATs
Improved overall network efficiency	Modest	Efficiency may not improve until after large scale transition	Low	Removal of NATs
Improved QoS capabilities	Modest/Small	Few benefits in the near future	Low	Ongoing standardization and subsequent implementation of QoS “flow label” field

Source:  Estimates based on RFC comments and discussions with industry stakeholders.

innovations in services and applications) and improved mobility.  Additional work must be done (e.g., removal of NATs, standards setting) to fully capture the potential benefits.  Although the long-term benefits may be considerable, the short-term benefits for many organizations may not exceed the costs of moving from IPv4 to IPv6 on an accelerated basis.

2.2   Stakeholder Costs of Adopting IPv6

The potential costs associated with deploying IPv6 comprise a mixture of hardware, software, labor, and miscellaneous costs.  The transition to IPv6 is not analogous to turning on a light switch; instead, many different paths to some level of IPv6 deployment can be forged.  Each organization or user throughout the Internet supply chain will incur some costs to transition to IPv6, primarily in the form of labor and capital expenditures required to integrate IPv6 capabilities into existing networks.

Expenditures and support activities will vary greatly across and within stakeholder groups depending on their existing infrastructure and IPv6-related needs.  By and large, ISPs offering service to a large group of customers will likely incur the most transition costs, while independent users will bear little, if any, costs.^[83]  Factors influencing these costs include

·     the type of Internet use or type of service being offered by each organization;

·     the transition mechanism(s) that the organization intends to implement (e.g., tunneling, dual-stack, translation, or a combination);

·     the organization-specific infrastructure comprised of servers, routers, firewalls, billing systems, and standard and customized network-enabled software applications;

·     the level of security required during the transition; and

·     the timing of the transition.

Table 2-2 provides a list of potential costs incurred by stakeholder group and gives a percentage breakdown by cost category.  Table 2-3 provides

an item-by-item list of the costs to deploy IPv6 by stakeholder group; this is a relative comparison of costs and should not be used to infer the actual size of each cost.  As part of the discussion in this section we

Table 2-2.  Overview of IPv6 Costs

Stake-holders	Total Cost	Transition Cost Breakdowna			Timing Issues	Key Factors in Bearing Costs
		HW	SW	Labor
Hardware Vendors	Low b	10%	10%	80%	Currently most are providing IPv6 capabilities	Rolling in IPv6 as standard R&D expense; international interest and future profits incentivize investments
Software Vendors	Low/Mediumc	10%	10%	80%	Currently some are providing IPv6 capabilities	Interoperability issues could increase costs
Internet Users	Low/Medium	10%	20%	70%	Very few currently running IPv6; HW and SW will become capable as routine upgrade; size of enabling cost should decrease over time	Users will wait for  significantly lower enablement costs or (more probably) a killer application requiring IPv6 for end-to-end functionality before enabling
Internet Service Providers (ISPs)	Highd	15%	15%	70%	Very few are offering IPv6 service; no demand currently; very high cost currently to upgrade major capabilities	ISPs see low or nonexistent ROI, high costs, and high risk

Source:  RTI estimates based on discussions with 26 industry stakeholders, RFC responses, and extensive literature review.

^aThese costs are estimates based on conversations with numerous stakeholders and industry experts.  Several assumptions underlie them.  First, it is assumed that IPv6 is not enabled (or “turned on”) or included in products and no IPv6 service is offered until it makes business sense for each stakeholder group.  Additionally, the hardware and software costs are one-time costs.  However, labor costs could continue for as long as the transition period and possibly longer.

^bFor hardware vendors producing high-volume parts that require ASIC changes, the costs could be very high and would not be offered until the market is willing to pay. 

^cSoftware developers of operating systems have and will incur a relatively low cost; however, application developers will incur greater costs, designated as medium.

^dThe cost for ISPs is particularly high if the ISP manages equipment at user sites, because premises equipment is more costly to manage and maintain.

Item	ISPs	Enterprise Users
Hardware
Replace interface/line cards		M
Replace routing/forwarding engine(s)b	M
Replace chassis (if line cards will not fit)	M	M
Replace firewall Replace billing systems	M L	M
Software
Upgrade network monitoring/management software	L	L
Upgrade operating system	M	S
Upgrade applications:
·     Servers (Web, DNS, FTP, mail, music, video, etc.)		S
·     ERP software (e.g., PeopleSoft, Oracle, SAP, etc.)		L
·     Other organization-specific, network-enabled applications		L
Labor
Train networking/IT employees	L	L
Design IPv6 transition strategy and a network vision	L	M/L
Implement transition:
·     Install and configure any new hardware	L	L
·     Configure transition technique (e.g., tunneling, dual-stack, NAT-PAT translation)	M	M
·     Upgrade all software (see Software section above)	S/M	S/M
·     Extensively test before “going live” with IPv6 services	L	L
Maintain new system	M/L	M/L
Other
IPv6 address block(s)		S
Lost employee productivityc	M	M
Security intrusionsd	L	L
Foreign activities	M	M
Interoperability issues	M/L	M/L

Source:  Estimates based on discussions with 26 industry stakeholders, RFC responses, and literature review.

^aThe relative designation (S = small, M = medium, and L = large) indicates the estimated level of cost to members of the specific stakeholder group.  These costs are not incremental, rather they reflect differences in costs between stakeholder groups.   

^bThe “brains” of the router, usually in the line card form. 

^cBecause of unexpected down-time during transition period. 

^dBased on unfamiliar threats.

                                                provide some insight into which stakeholder groups will end up bearing the costs or appropriating the benefits associated with IPv6.^[84]  The following sections are qualitative in nature and focus on the costs likely to be incurred by each stakeholder group and how the timing of the transition affects these costs.

                                      2.2.1  Hardware, Software, and Services Providers

Vendors that provide products and services include: networking hardware companies, such as router and firewall manufacturers; networking software companies, including operating system and database management application developers; and service vendors comprised of companies that offer training, service and support.  These companies need to integrate IPv6 capabilities into their products and services, if they have not already done so, as a precursor to all user transitions.  Once IPv6-capable products are installed in user networks, ISPs will be enabled to offer IPv6 service (see Section 2.2.2 infra for more on ISP costs), and users will be able to purchase IPv6-enabled devices and applications.  Many companies in this category are already developing, and some are even selling, IPv6 products and services.

The majority of the costs being incurred by hardware and software developers include labor-intensive research and development (R&D) costs and training costs.  These costs, however, have not been large enough to deter development of IPv6 capabilities.  R&D activity has generally been conducted in small intracompany groups dedicated to developing IPv6-capable products with, to date, limited, small-scale interoperability testing with other hardware and software makers.   Based on industry experience with the early deployments of IPv4 equipment, large-scale deployment may bring to light additional interoperability problems.^[85]

The future cost of interoperability testing could be substantial but such testing is essential if IPv6 is to become seamlessly pervasive.  Without interoperability testing, IPv6 capabilities could have little practical use.^[86]  Recently, the Department of Defense, in collaboration with several industry stakeholders and the University of New Hampshire, launched the Moonv6 test bed, which has stimulated interoperability testing to be conducted between both U.S. and foreign vendors wishing to offer IPv6 products or services.^[87]

In the next several years, foreign activities will likely affect IPv6 transition costs borne by hardware, software, and service vendors.  Several commenters noted that, as foreign companies and corporations encounter and solve various deployment issues, U.S. vendors will see lower implementation costs.^[88]  As products mature, fewer vulnerabilities are found, thus lowering implementation costs.  The United States is likely to benefit from the current experience being gained by foreign activities.  However, a point of diminishing returns is likely, although it is difficult to say when.^[89]  In addition, several commenters stated that substantial foreign competition could drive up the prices of U.S. companies’ products and services because with less market share they would not be able to spread R&D costs across a large customer base.^[90]

                                      2.2.2  ISPs

ISPs comprise two main groups, which often overlap—regional and national companies that provide internet access service to corporate, governmental, nonprofit, and independent Internet users (e.g., AOL, Earthlink) and national companies that own and maintain the backbone hardware and software of the Internet (e.g., MCI, Sprint, AT&T).  Often companies that own the backbone Internet infrastructure provide Internet access service to customers through a subsidiary.  Today, most backbone transport networks have already upgraded their major routers and routing software to accommodate IPv6.  Thus, we focus on smaller ISPs that have large customer service provision capabilities.  This group will likely incur the bulk of the transition costs as they enable IPv6 hardware and software applications and work through system interoperability problems.  To date, however, there has apparently been little demand for IPv6 service or applications in the United States.  As a result, given the costs to reconfigure networks, experts and industry stakeholders agree that U.S. ISPs are currently not positioned to realize a positive return on investment from large-scale offerings of IPv6 service.^[91]

For ISPs to offer a limited amount of IPv6 service, they would need to integrate some transition mechanism(s), such as tunneling.^[92]  The costs of doing so will probably not be large.^[93]  If several routers and service provisioning software are upgraded and limited testing is performed, IPv6 service could be provided to a limited number of Internet users today at minimal additional cost.  Currently ISPs are performing some limited testing.^[94]  However, before ISPs elect to offer widespread IPv6 service, they will need assurances that current service offerings would not be affected in any way.  This would likely require much more testing and significant additional hardware, software, and training costs,^[95] possibly increasing the costs by 100 to 200 percent more than would be incurred for a more limited service roll-out, depending on the number of affected customers and the nature of an ISP’s infrastructure.

Assuming that IPv6 products and services in the Asian market are transferable to the U.S. market, those ISPs offering IPv6 services abroad will have absorbed some of the initial development costs.  R&D costs attributable to IPv6 implementation, like any other advanced technology, can be borne by early adopters.  However, excessive delay by U.S developers may not allow them to charge early adopter premiums if mature competing products from foreign markets are already in place.^[96]  However, such costs are not likely to be a dominant factor for most application services.^[97]

In the United States today, NTT/Verio is currently the only ISP providing end-to-end IPv6 service;^[98] however, they began replacing and upgrading hardware and software components to be IPv6 capable as early as 1997.  By spreading out transition costs, including hardware and software costs, training, and the development of network administration software tools, NTT/Verio was able to upgrade for almost no additional costs above standard upgrade, training, and testing costs.^[99]  Although the transition may not be as inexpensive for other ISPs, NTT/Verio’s experience illustrates how careful planning can help reduce transition costs.

Almost all experts agree that a shift to IPv6 over a short period of time will be more expensive than performing the transition as part of a normal life-cycle update.  Transition technologies were specifically designed to enable a prolonged overlap and to minimize deployment and operational interdependencies.  Rather than forcing a short-term shift, many experts suggest that a reasonable deployment plan would focus on replacing as much IPv4-only hardware and software as possible through normal life-cycle updates.  Over any period of acquisition, turning on IPv6 for routine use should only occur after a critical mass of IPv6-enabled replacement technology and training are in hand.^[100]

Thus, until customers begin demanding IPv6 service, most U.S. ISPs have no incentive to incur any major additional costs; in 5 to 10 years, however, as more hardware and software become IPv6 capable through cyclical replacements, continued standardization efforts of the IETF,^[101] and testing by many parties, ISPs will probably be in a position to recoup investment costs associated with IPv6 service.

                                      2.2.3  Internet Users (Corporate, Government, Nonprofit, and Independent)

Costs to upgrade to IPv6 for Internet users vary greatly.  Independent Internet users, including residential users and small and medium enterprises (SMEs) who do not operate servers or any major database software, will only need to upgrade networking software (e.g., operating systems) and one or more small routers to gain IPv6 capabilities.  This cost will be relatively minimal if the hardware and software are acquired through routine updates. 

Organizations, such as corporations, government agencies, and nonprofits, will incur many more costs than home or small network users, but the relative level of these costs will depend on the extent to which a specific organization wants to operate IPv6 applications and whether it intends to connect to other organizations using IPv6.  The magnitude of the transition costs is still uncertain because only a few test beds and universities have made large-scale transitions.  According to officials at Internet2, the time and effort needed to transition their backbone to IPv6 was minimal, and no significant system problems have been encountered.^[102]  However, Internet2 indicated that their experimental system was implemented and is maintained by leading industry experts.  It is unclear what issues might arise from implementation by less experienced staff.  Tony Hain points out, however, that if normal upgrade cycles are assumed to provide IPv6 capabilities, transition costs will be limited to training and some reconfiguration.

Internet users, as a whole, constitute the largest stakeholder group.  The robustness of this sector allows for a more detailed explanation of costs broken out by hardware, software, labor, and other costs.

Hardware Costs

Depending on individual networks and the level of IPv6 use, some hardware units can become IPv6 capable via software upgrades.  However, to realize the full benefits of IPv6 most network hardware will need to be replaced.^[103]  Specifically, high-end routers, switches, memory, and firewalls all will need to be upgraded to enable large scale IPv6 use within a network.  It is generally agreed that to reduce hardware costs, all or the majority of hardware should be upgraded to have IPv6 capabilities as part of the normal upgrade cycle (generally occurring at least every 3 to 5 years for most routers and servers, but potentially longer for other hardware such as mainframes).  At that time, IPv6 capabilities should be available and included in standard hardware versions.  In the short term, replacement of some forwarding devices and software could be used to set up small-scale IPv6 networks. 

Software Costs

Significant software upgrades will be necessary for IPv6 use; however, similar to hardware costs, many of these costs will be negligible if IPv6 capabilities are part of the routine requirements in periodic software upgrades.^[104]  Software upgrades include server software, operating systems, business-to-business (B2B) software, networked database software, network administration tools, and any other organization-specific network-enabled applications.  Currently, the main software cost that user organizations envision pertains to element management systems, network management systems, and operations support systems that are often network specific and will need coding to adjust for IPv6.  If Internet users upgrade their commercial application software in 2 or more years hence, they should have IPv6 capabilities, although they will still need to upgrade their company-specific software.

Labor Costs

According to experts, training costs are likely to be one of the most significant upgrade costs,^[105] although most view it as a one-time cost that could be spread out over several years.  The actual cost depends on the level of understanding necessary for network administration staff.  On a daily basis, the change in operating procedure for IPv6 will be minimal.^[106]   Most network staff, however, will need a full understanding of the required network infrastructure changes and how they might affect security or interoperability.^[107]  NAv6TF notes that the relative programming skills of software engineers at a particular company could drastically affect upgrade costs.^[108]  A company with more skillful programmers might have to hire one additional employee, while another might need three or four, during a transition period that could last 5 or 10 years.

Similarly, training costs may be minimal for large organizations with existing IPv6 expertise (e.g., universities).  For small to mid-size organizations where information technology (IT) staff perform multiple functions, staff training could be a significant share of the IPv6 transition costs.  If staff will need to alter their general activities based on IPv6 use, staff training will be necessary for them, though generally this should not occur.^[109]  If customers will be affected in any way, sales staff and any other employees who interact with customers periodically will need to understand the potential problems and benefits that could affect their relationships with customers.

Additional labor will be needed to run testing activities, to install and configure new hardware, software, and transition mechanism(s), and to maintain the new dual-stack (i.e., IPv4 and IPv6) network.  As the transition takes place, a more complex network will likely require additional network administration costs in the short term.  For example, in a dual-stack network, two standards will have to be supported; thus, security intrusions will likely increase significantly (attributable to a lack of awareness of or a lack of experience with IPv6 security “holes”).  These costs would be highest in an expedited deployment scenario.  Costs would be lower in a gradual migration scenario where much of the testing and problem resolution can be completed over a gradual period or through shared initiatives.^[110]  For U.S. vendors, costs would also be lower in a scenario where the early deployment issues are encountered and resolved in foreign countries.^[111] 

                                      2.2.4  Hypothetical Case Study:  Enterprise Adoption of IPv6

The costs associated with an enterprise adoption of IPv6 can best be illustrated through a hypothetical case study.  Company A, a medium-to-large enterprise with an IPv4-only corporate network, determines that to contact Company B via an IPv6 connection, Company A needs to begin migrating its network to IPv6.  This transition will cause Company A to incur costs mainly in the areas of hardware, software, and labor costs, but other costs may arise from unforeseen security threats and other hurdles (e.g., interoperability) that are difficult to predict.

Company A’s network infrastructure, combined with its present and desired future applications strategies, will determine the appropriate transition process and costs.  For the purposes of this case study, we assume that Company A has eight core routers, 150 distribution switches, and four firewalls, all with varying individual costs.  The primary applications that the company uses include limited video conferencing, some streaming video, and a company-wide inventory database.  Company A has three full-time network specialists and allocates approximately $2,500 per year on training per employee.  Table 2-4 provides a breakdown of the infrastructure owned by Company A and its annual spending on IT staff and training.

Table 2-4.  Infrastructure Components and Associated Cost/Value

Network Component/Costs	Number of Units	Average likely Cost or Value (per unit)	Total Value/Cost
Router	8	$15,000	$120,000
Distribution Switches	150	$10,000	$1,500,000
Firewall	4	$1,500	$6,500
Network Specialist (1 FTE)	3	$55,000	$165,000/year
Training	3	$2,500	$7,500/year
TOTAL			$1,799,000

Source:  RTI Networking Staff.

In order to get immediate connection capabilities, Company A plans to establish a limited IPv6 network over a 6- to 12-month period; however, the majority of costs will be spread out over a transition period lasting several years, at a minimum.  In the most likely scenario, Company A will follow a migration path that gradually increases the number of applications running IPv6 and the ability of the network to handle more IPv6 traffic.  Table 2-5 compares the costs as Company A progresses through the various stages of its migration strategy.

In Phase 1, Company A will transition from an IPv4-only network to an IPv4 network with IPv6 tunneling.^[112]  It will employ tunneling primarily to allow IPv6 communication with outside organizations and networks at a low cost; thus, they will employ host to host tunneling using a tunnel broker.  By reconfiguring the network for tunneling and running dual-stack operating systems on hosts, this approach will provide IPv6

Table 2-5.  Transition Phases

Transition Phases	Relative Estimated Size of Cost	Costs
		Hardware	Software	Labor	Other
Phase 1 (Minimal IPv6 using tunneling in a network)	Medium	Upgrading/ replacing 1+ backbone routers; replacing firewalls	Upgrading/ replacing any applications used specifically for IPv6	Existing IT personnel must be trained; new personnel may need to be hired to help install and run a dual-protocol network and address new/additional security concerns	Scheduled downtime; unexpected equipment and service outages; security threat effects
Phase 2a (Substantial IPv6 using a dual-stack network)	Large	Upgrading/ replacing remaining routers and all other networking hardware	Upgrading/ replacing all applications to be IPv6 capable	More IT training and network administration time/effort will be required before, during and after the installation; users might need to be trained to use new applications	Security threat effects
Phase 3b (Native IPv6 with IPv4 translation)	Small/Medium	Upgrading/ replacing gateways and other devices to perform translation	Depending on the translation mechanism, new software may be required	Time/effort to install and maintain translation devices; training and support for users running only IPv6 applications	Interoperability issues with external Internet users/networksc
Phase 4 (Native IPv6 only)	Small	None	None	Time/effort to remove translation devices and software	Lost business

Source:  RTI estimates based on discussions with industry stakeholders.

^aThe costs described in Phase 2 assume that Phase 1 has been completed.

^bThe costs described in Phase 3 assume that Phase 2 has been completed.

^cSecurity threats will continue but most likely at a reduced cost since IPv6 intrusions will be better understood.

 

connectivity for a limited subset of the company’s hosts as a pilot group.  Connectivity will later be extended to the entire corporate network and user base.

The extent of the costs associated with this first phase of migration will rely heavily on the presence of IPv6 capabilities within the network and host hardware and software.^[113]  After assessing hardware and software capabilities, Company A will need to develop a plan for how and when to incorporate IPv6 into its network; this will involve contributions from not only IT administrators, but also company leaders and/or any Internet users who can communicate the desire to have certain IPv6 capabilities.  This process should take several months and could be quite costly in terms of labor effort.

Addressing specific expenditures, we note that Phase 1 equipment costs will include upgrading/replacing one or more routers to allow IPv6 tunneling and replacing firewalls and intrusion detection system (IDS) equipment for security.  Unless Company A has an urgent need to gain IPv6 connectivity, it will incur these costs during a routine 3- to 5-year equipment upgrade cycle.  Because most computer operating systems currently support IPv6 (e.g., Windows and Linux), software costs for a pilot group of IPv6 users will be limited to any upgrades of applications to be used specifically with IPv6.

Labor and training costs will be a large part of this initial migration phase.  Existing IT personnel must be trained to support IPv6.  New personnel may be hired to assist with the operational overhead of running two Internet protocols on a network and to address potential security concerns commonly associated with any major IT transition.  Scheduled downtime and unexpected outages of equipment and services related to upgrades will add additional costs.

As Company A decides to enable more internal Internet hosts to use IPv6, it will likely begin Phase 2 of its migration by integrating dual-stack capabilities into network routers that would allow more IPv6 messages to be sent and received, and would make such communication more efficient.  Although Windows-based hosts could use Microsoft’s Teredo to send IPv6 messages with no changes to existing routers, companies interested in transitioning to IPv6 will likely enable dual-stack capabilities in their network routers, as well as on most or all of its network and IT infrastructure while maintaining normal IPv4 operation.^[114]

Phase 2 will involve configuring dual-stack routers and running IPv4 and IPv6 simultaneously on most network equipment and hosts.  Hardware not upgraded to IPv6 in Phase 1 will be upgraded during this phase.  However, the majority of the costs will come from software upgrades and associated labor costs necessary to roll out new IPv6 service and applications to a large number of corporate users.^[115]  Training costs will also be incurred because these users need to be trained on new applications.  Security issues will also require labor and possibly additional hardware and software.

In Phase 3 of Company A’s migration plan, it will use IPv6 exclusively for network transmission, and use IPv6-to-IPv4 translation to interact with external IPv4 networks.  The decision to move from Phase 2 to Phase 3 will turn on cost savings – whether the costs of network support for IPv4 exceed the costs of supporting IPv6.  Estimated to be many years away, Phase 3 will most likely involve employing a predominantly IPv6 network with remaining “pockets” of IPv4 within the company.  Resources continuing to run IPv4 even after this phase may include legacy equipment such as mainframes and databases that are too expensive to upgrade during Phase 3.  The only likely equipment costs are gateways and other devices needed to perform IPv4/IPv6 translation for that legacy equipment.  Labor costs may be incurred with the installation and maintenance of these translation devices.  Additional labor costs may come from supporting a large base of users now running IPv6 natively and the associated issues that may arise.

Lastly, as IPv4 traffic becomes less common, Company A will decide not to support translation devices.  In Phase 4, any networks or hosts still operating on IPv4 stacks will have to have translation devices to communicate with IPv6-only hosts or networks.

                                2.3   Other Transition Issues and Costs

                                      2.3.1  Interoperability

The transition to IPv6 will be a long process and may never attain complete penetration before the protocol becomes obsolete.  Experts predict that in 20 years most Internet users will be using IPv6, but pockets of IPv4 will still exist as parts of legacy systems.^[116]  Some firms will not find it cost-effective to convert large segments of their existing systems.  Hardware and software interoperability is a key requirement for interconnecting networks across heterogeneous environments, and thus will be a major consideration in an enterprise’s decision to adopt IPv6.

The developers of IPv6 recognized that there would likely be a lengthy transition period from IPv4 to the new protocol and strived to accommodate that fact.^[117]  Most directly, they created several mechanisms (e.g., dual-stack, tunneling, and translation) to enable networks using either or both version of IP to communicate with each other.  Those mechanisms were intended to eliminate deployment dependencies between and among vendors and networks and thereby to allow enterprises to decide when to adopt IPv6, if at all, based upon their own needs and goals, without regard to the decisions of other enterprises.^[118]  Interoperability will not be completely seamless in practice, however.  Firms will have to address a number of issues in order to minimize interoperability problems during the transition from IPv4 to IPv6.

Interoperability Between IPv6 Hardware and Software Applications

Because IPv6 is an industry standard, hardware and software applications produced by different vendors in accordance with that standard should be interoperable.  Put another way, there is nothing inherent in the protocol that should create an interoperability barrier.  In general, experts believe that with international cooperation most implementation differences can be avoided and in the long run interoperability problems will be minimal because producers will quickly adjust to avoid any productivity losses from interoperability problems.  To date, experience shows that no obvious problems arise in implementing the IETF standards for IPv6, because major operating system and router vendors already have implemented and periodically demonstrated interoperability.^[119]

However, some experts believe that in the short run differences in the implementation of IPv6 could potentially lead to interoperability problems in some areas.^[120]  For example, the protocol allows proprietary functions to be incorporated in areas such as optional headers that could lead to incompatibility.  Conformance questions will need to be addressed.  Experts believe that additional test beds and activities (such as testing activities currently being conducted as part of the Moonv6 test bed) are needed.  In the absence of such action, future IPv6 products developed in one company might not be able to interact with those developed in another under the same general standards.^[121] For these reasons, organizations should emphasize interoperability in any transition plan to minimize costs and efficiency losses.

Interoperability between IPv4 and IPv6 Hardware and Software Applications

Interaction or intercommunication between IPv6-only and IPv4-only hardware and software applications does create potential interoperability problems.  Before a host on one network can communicate with a host on another network, the originating host will first have to determine which protocol(s) the receiving host supports and then make the necessary arrangements to send a recognizable message.  This process could increase delay or decrease network efficiency.  Both networks could mitigate these interoperability problems by deploying dual-stack capability.  The IETF has reported, however, that dual-stack equipment does not eliminate interoperability concerns.  For example, if an IPv6 node is placed in a mixed IPv6/IPv4 environment, it may encounter problems that lead to connection delays, poor connectivity, and network insecurity.^[122]

Tunneling can also facilitate interoperability between IPv6 and IPv4 networks, but it also increases packet overhead.  Although that would not create undue hardship for network routers, it would increase processing time and network overhead costs.^[123]  The interoperability benefits likely outweigh the additional costs.  Most importantly, interoperability mechanisms, such as tunneling, allow an enterprise to transition to IPv6 at its own pace, lowering hardware and software costs, and minimizing the impact on existing operations.^[124]  Nevertheless, a company should bear the costs of interoperability in mind as it decides when and how to deploy IPv6.

                                      2.3.2  Security in Transition

Section 2.1.2 discussed the security benefits of deploying IPv6, as compared to IPv4.  Security concerns are not limited to the capabilities and vulnerabilities inherent in the individual protocols, however.  As enterprises assess the merits of adopting IPv6, they must also consider the security issues that will arise during the transition period when both IPv6 and IPv4 are being used.

As noted in section 2.1.2, enterprises that operate dual-stack equipment will have to address the vulnerabilities of both protocols.  The resulting security problems may not simply be additive; simultaneous use of both IPv6 and IPv4 may expose an enterprise to more attacks than the sum of the attacks that can be launched against each protocol.  Dual-stack operation can raise other security problems, moreover, if consistent security policies are not created for both IPv6 and IPv4 traffic.  If a firewall is not configured to apply the same level of screening to IPv6 packets as for IPv4 packets, the firewall may let IPv6 pass through to dual-stack hosts with the enterprise network, potentially exposing them to attack.^[125]

Enterprises that achieve interoperability via tunneling could also expose themselves to external attacks and threats.  IPv6 packets encapsulated in IPv4 tunnels could pass through IPv6 firewalls and launch attacks on IPv6 network host equipment.^[126]  Additionally, automatic tunneling mechanisms (i.e., those in which the communicating parties do not have an active hand in establishing) are susceptible to packet forgery and denial of service attacks.^[127]  Although none of these transitional security concerns are insuperable, organizations planning to implement IPv6 must be aware of them and develop the necessary security policies to address them.