spacer

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

IPV6 TASK FORCE
U.S. DEPARTMENT OF COMMERCE
National Telecommunications and Information Administration
National Institute of Standards and Technology


Previous Section Table of Contents Next Section

2 BENEFITS AND COSTS OF ADOPTING IPv6

Industry stakeholders and Internet experts generally agree that IPv6-based networks [ 44 ] would be technically 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 networks and services.

Widespread adoption of IPv6, however, could entail significant transition costs because the Internet today is composed 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, albeit with varying levels of performance. 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 “middleboxes” that affect direct Internet communications between end-user devices, such as Network Address Translation (NAT) devices (see Section 2.1.1.2), firewalls, and intrusion detection systems (IDS). 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 in Appendix A 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.

2.1 Relative Benefits of IPv6 vs. IPv4

A general consensus appears to exist regarding the technical improvements of IPv6 versus IPv4 and the types of benefits that could follow from widespread adoption of IPv6. Disagreement exists, however, regarding the size of those benefits and whether the incremental benefits of IPv6 (versus IPv4) for some or all users would outweigh the costs of a greatly accelerated transition from IPv4 to IPv6. [ 45 ] This section discusses the potential net benefits of adopting IPv6, as identified by RFC commenters, RTI’s discussions with industry experts, the available literature, and participants at the July 28, 2004 public meeting.

2.1.1 Increased Address Space

A 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 (4x109) unique Internet addresses. [ 46 ] The 128-bit address header in IPv6, in contrast, provides approximately 3.4x1038 addresses, enough to assign trillions of addresses to each person now on earth or even to every square inch of the earth’s surface. [ 47 ]

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 and unforeseen services or applications that require large quantities of globally routable Internet addresses. [ 48 ] Pressures on existing IPv4 address resources will likely increase in coming years, as more and more people around the globe seek IP addresses to enjoy the benefits of Internet access. [ 49 ] The burgeoning demand for “always-on” broadband services (e.g., DSL and cable modem services) and the expected proliferation of wireless phones, wireless data devices (e.g., PDAs), and eventually wireless video services may further deplete the available IPv4 address space. [ 50 ]

Further, if consumers are drawn to devices that can be remotely accessed and controlled via the Internet and that require fixed, globally accessible Internet addresses (e.g., smart appliances, in-home cameras and entertainment systems, and automobile components or subsystems), demand for IP addresses may overwhelm the remaining pool of IPv4 addresses.[ 51 ] Although it is difficult to predict exactly when these developments may threaten the existing supply of IP addresses, the availability of virtually unlimited IPv6 addresses would enable Regional Internet Registries (RIRs) [ 52 ] and Internet service providers (ISPs) to accommodate any sharp spike in demand.

2.1.1.1 Improving Address Allocation

Adoption of IPv6 could provide an opportunity to reform and rationalize the current system for allocating Internet addresses, because deployment of IPv6 has created 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 current allocation policies have improved, no incentives have been created to prevent “warehousing” of IP addresses [ 53 ] or to motivate 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. [ 54 ]

Deployment of IPv6 creates an opportunity to use the lessons learned from the past to adopt more efficient allocation policies for IPv6 addresses. On July 2, 2002, ARIN adopted IPv6 address allocation policies developed jointly with the Réseaux IP Européens Network Coordination Centre (RIPE-NCC) and the Asia Pacific Network Information Centre (APNIC). Policy 6.3.5 states that “[a]lthough IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided.” [ 55 ]

Although concerns about IPv4 address exhaustion drove development of IPv6, [ 56 ] steps have been taken to conserve addresses and to improve the efficiency of address allocation. [ 57 ] As a result, a number of observers believe that the United States, Western Europe, and Australia may not experience address space concerns for some time. [ 58 ] 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 question whether the problem is so severe as to warrant accelerated adoption of IPv6. [ 59 ]

Additionally, in response to concerns about the perceived shortage of IPv4 addresses stemming from historical address allocation policies, [ 60 ] the RIRs have reorganized themselves in recent years to ensure that, prospectively, all regions are allocated IP addresses through a fair, transparent, and efficient process. [ 61 ] IPv4 address blocks are currently allocated to the RIRs from a common global pool, using agreed upon criteria and methodology. [ 62] When a region requests more addresses, they are allocated to the RIR on a need-justified basis. [ 63 ] 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. [ 64 ]

To capture fully the address benefits of IPv6, those entities involved in the process should continue working to ensure that IPv6 addresses are allocated fairly and efficiently. [ 65] 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. [ 66] At the same time, VeriSign emphasizes the need for allocation policies that discourage “warehousing” of IPv6 addresses to prevent inefficient consumption of those addresses. [ 67 ]

2.1.1.2 Facilitating End-to-End Services and Applications

Proponents of IPv6 contend that the massive increase in IP addresses afforded by IPv6 deployment could stimulate development of innovative end-to-end (E2E) applications by eliminating the need for network address translation (NAT) equipment. A NAT is a 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. [ 68 ] For internal communication, each host is assigned a locally unique private IP address (see Figure 2-1).

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

Local Private Network
Source: RTI

As the term implies, a NAT converts the private source address in outgoing communications to a 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. The massive increase in address space available under IPv6 would obviate the need for NATs as means of address conservation. [ 69 ]

Although, as discussed below, NATs provide some benefits for network administrators and end users, they also complicate the use and development of new E2E networking applications. 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. [ 70 ] 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. [ 71 ]

To the extent that use of IPv6 obviates the need for NATs, adoption of IPv6 could stimulate the development and deployment of innovative E2E applications. This may occur because applications designers would be able to “focus on core products and services, rather than network logistics.” [ 72 ] More specifically, designers could avoid the time and effort needed to develop work-arounds (also known as NAT transversals) that enable specific E2E applications to operate in a “NATed” environment. [ 73 ] These work-arounds may not scale well in all environments, [ 74 ] may reduce the performance and robustness of the associated applications, and may increase the cost and complexity of network management. [ 75 ] 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.

Without NATs, moreover, 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. [ 76] 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. [ 77]

Indeed, advocates contend that widespread deployment of IPv6 and a concomitant removal of NATs would permit a return to the original “open scheme” of the Internet, based on E2E connectivity. [ 78 ] Devices that are globally addressable so that they can be remotely accessed and controlled on an end-to-end basis via the Internet represent a huge potential application of IPv6 addresses. Automobile components or subsystems, refrigerators, cameras, computers, and other home appliances could be assigned unique IP addresses, linked together on home networks, and connected to the Internet, so that home owners could control such devices remotely. In general, IPv6 offers 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. [ 79 ]

The growth in such individually addressable and controllable devices and subsystems could, among other things, increase the life expectancy of large ticket items such as automobiles and appliances (durable goods) due to remote monitoring of these items’ operation to determine preventive servicing requirements with the result of a decrease in service/repair costs. RTI estimates that if such remote monitoring could extend the life expectancy of an automobile or appliance by only one percent, and reduce service costs for those items by one percent, the potential economic benefits to society could exceed $3 billion per year. [ 80 ] To the extent that the benefits from this one type of E2E application are achievable by other types of applications, the overall economic gains could be substantial.

Despite the potential benefits of unlimited IP addresses and a NAT-less world, adoption of IPv6 may not prompt a return to the “open architecture” originally envisioned by the designers of the Internet. It has been noted, for example, that the E2E Internet model was developed in a very specific environment—one characterized by a relatively small number of sophisticated users working in trusted relationships towards a common purpose. [ 81 ] Today, the commercialized Internet operates in a very different environment—tens of millions of users, most of whom have no connection or affinity with other users. Some of those users, moreover (e.g., hackers, snoopers, and spammers), are working at cross-purposes with other users. Little evidence exists to suggest that, in this more wide-open Internet environment, a substantial number of network administrators would want to return to a network design that will enable any other Internet user to connect with them on an end-to-end basis. [ 82 ]

Although NATs were not designed to, and thus cannot provide, reliable security, their use in conjunction with local addressing schemes can conceal users to some degree from unwanted communications. [ 83 ] Because NATs generally preclude outside parties from initiating communications with host devices sitting behind a NAT, they can help block many of the common virus and worm probes that are constantly scanning the Internet for vulnerable hosts. By so doing, NATs can provide a limited form of “security through obscurity,” thereby enabling network operators to block externally initiated contacts and to hide internal hosts. [ 84 ] It remains to be seen how similar effects will be achieved with IPv6 technologies. Ongoing design and specification work for IPv6 “Network Architecture Protection” and “Unique Local IPv6 Unicast Addresses” are attempting to address some of these issues.

More importantly, concerns about security in the Internet environment have prompted organizations to deploy a range of “middleboxes” (e.g., firewalls, intrusion detection and prevention systems) that, like NATs, may inadvertently affect or purposely inhibit E2E communications. 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. [ 85 ] Few, if any, network operators will be likely to remove those devices should they decide to implement IPv6, at least in the absence of tools or techniques that can reliably provide an equivalent level of security in an E2E world. [ 86 ] Consequently, most observers believe that, even if NATs were to disappear tomorrow, many devices would remain in place that could impede the smooth development and deployment of E2E services and applications. [ 87 ]

In short, the ability to exploit the virtually unlimited IPv6 address space to support a growing number of networked devices or to stimulate the development of innovative E2E Internet applications and services will likely be limited by several relevant factors—a continuing supply of IPv4 addresses, possible difficulties with obtaining IPv6 addresses, a potential reluctance to eliminate NATs, firewalls, and middleboxes that affect E2E applications, [ 88 ] and an absence of compelling applications that require E2E connectivity.

2.1.2 Simplified Mobility [ 89 ]

Mobile services and mobile users could be major beneficiaries of the massive address space available via IPv6. 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. [ 90 ] Sprint suggests that the emergence of mobile data services such as wireless data, picture mail, and text messaging could drive the adoption of IPv6. [ 91] 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. [ 92]

Quite apart from IPv6’s address benefits for mobile services, 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. [ 93] According to Microsoft, “IPv6 better handles mobile applications and services.” [ 94] The North American IPv6 Task Force 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. [ 95] Sprint suggests that IPv6 will permit more optimal routing of mobile traffic because IPv6 mobility specifications are being designed to eliminate “triangular routing.” [ 96]

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. [ 97] 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. [ 98]

2.1.3 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. [ 99] For business IP-based services to flourish, service providers will likely need to provide Quality of Service (QoS) [ 100 ] 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).

Several commenters suggest that, as presently implemented, IPv6 provides no better QoS support than does IPv4. [ 101 ] Nevertheless, 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 those traffic flows for which the provider requests special handling by network routers with greater specificity (or “granularity”) than is available under IPv4. [ 102 ] The expanded capabilities of IPv6 are not yet available to users and service providers, however. 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.” [ 103 ] 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.” [ 104 ]

The IETF has begun to develop standards and specifications that would allow users and service providers to exploit the potential benefit of the IPv6 flow label. In March 2004, it released a foundation document that specified the flow label field and identified minimum requirements for IPv6 source nodes that wish to label packet flows, for IPv6 routers forwarding labeled packets, and flow state establishment methods. [ 105 ] Additional work will be needed to build on these basic requirements to create flow label specifications for particular uses, such as QoS. [ 106 ] It, therefore, appears that significantly more work is needed before a mature QoS standard is specified and, in turn, the potential QoS benefits of IPv6 can be realized.

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

2.1.4 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. [ 108 ] 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. [ 109 ] 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. [ 110 ]

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. [ 111 ] Removal of NATs could also simplify use of multivendor networking solutions. [ 112 ] 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. [ 113 ]

To the extent that the administrative cost savings of IPv6 depend on the removal of NATs, however, the potential savings may be constrained or even negated by the likely persistence of those devices in an IPv6 environment. More generally, immediate reductions in administrative costs flowing from adoption of IPv6 will likely not exist, [ 114 ] although the cumulative savings should eventually exceed transition costs. Many networks may not see a net reduction in costs for at least five or more years after initial IPv6 deployment, depending on the priority assigned to upgrading of systems, specific network complexities, and other issues that may arise during transition. [ 115 ]

Additionally, some experts have stated that aggregate administrative reductions will not be realized because new IPv6 issues related to new/advanced applications and projected increases in Internet traffic could incur added costs, including additional administrative activities. [ 116 ] However, this development still implies a decrease in the cost per unit of information exchanged.

In summary, during the extended transition period in which both IPv4 and IPv6 support will be required, total operational expenses (OPEX) for network operations will likely increase, rather than 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 ten or more years.

2.1.5 Increased Overall Network Efficiency

Removing NATs, firewalls, and middleboxes, and/or restructuring network routing mechanisms (and administrative activities) would likely result in fewer processing steps and reduced transmission bottlenecks. [ 117 ] 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. [ 118 ] Some experts have said that such benefits will result only when IPv6 use is widespread. [ 119 ] 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.

Table 2-1. Overview of IPv6 Benefits
spacer
Benefits Magnitude of Potential Benefits Timing Issues Likelihood of Occurence Key Factors in Realizing Benefits of IPv6
spacer
Increased address space Large No near-term shortage in U.S. 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
Improved overall network efficiency Modest Efficiency may not improve until after large scale transition Low Removal of NATs
Improved QoS capacbilities Modest/Small Few benefits in the near future Low Ongoing standardization and subsequent implementation of QoS "flow label" field
spacer
Source: RTI estimates based on RFC responses and discussions with industry stakeholders.

2.1.6 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 innovations in services and applications) and improved mobility. Additional work must be done (e.g., removal of NATs, restructuring of networks, and 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 a greatly accelerated basis.

2.2 Stakeholder Costs of Adopting IPv6

The potential costs associated with deploying IPv6 consist of a mixture of hardware, software, labor, and miscellaneous costs. [ 120 ] 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 large groups of customers will likely incur the largest transition costs per organization, while independent users will bear little, if any, costs. [ 121 ] 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 relative costs that may be 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 interpreted as representing the actual size of each stakeholder group’s cost. Further, small Internet users (e.g., home and small businesses) are not captured in Table 2-3 because they will likely incur virtually no costs. Small Internet users will receive software upgrades (e.g., operating systems and email software) as new versions are purchased, that their IPv4-only hardware (e.g., routers and modems) will be replaced over time as part of normal upgrade expenditures, and that IPv6 will eventually be provided at no additional cost. [ 122 ]

Table 2-2. Overview of Relative IPv6 Costs
spacer
Stake-holders Relative Cost Transition Cost Breakdowna

spacer
Timing Issues Key Factors in
Bearing Costs
Hard-Ware (HW) Soft-ware (SW) Labor
spacer
Hardware Vendors Lowb 10% 10% 80% Currently most are providing IPv6 capabilities Rolling in IPv6 as standard R&D expense; international nterest 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 (large) Medium 10% 20% 70% Very few currently using IPv6; HW and SW will become capable as routine upgrade; 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 Users (small) Low 30% 40% 30% Availability and adoption schedules With little money to spare, these users must see a clear return on investment (ROI)
Internet Service Providers (ISPs) Highd 15% 15% 70% Very few 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
spacer
Source: RTI estimates based on RFC responses, discussions with industry stakeholders, and an extensive literature review.

a These 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. Hardware and software costs are one-time costs. Labor costs could continue for as long as the transition period and possibly longer.

b For hardware vendors producing high-volume parts that require changes to application-specific integrated circuits (ASIC), the costs could be very high and would not be offered until the market is willing to pay.

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

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

Table 2-3. Relative Costs of IPv6 Deployment by Stakeholder Group a
spacer
Item Hardware, Software, Service Providers ISPs Enterprise Users
spacer
Hardware      
Replace interfacing cards H   M
Replace routing/forwarding engine(s) b M M  
Replace chassis (if line cards will not fit)   M M
Replace firewall   M M
Software      
Upgrade network monitoring/management software   H H
Upgrade operating system    M H
Upgrade applications c      
• Servers (Web, DNS, file transfer protocol (FTP), mail, music, video. etc.)     L
• Enterprise resource planning software (e.g., PeopleSoft, Oracle, SAP, etc.)     H
• Other organization-specific, network-enabled applications     H
Labor      
R & D M L  
Train networking/IT employees H H H
Design IPv6 transition strategy and a network vision M H M/H
Implement transition:      
• Install and configure any new hardware L H H
• Configure transition technique (e.g., tunneling, dual-stack, NAT-port address translation M M M
• Upgrade software (see Software section above)   L/M L/M
• Extensive test before "going live" with IPv6 services   H H
Maintain new system   M/H M/H
Other      
IPv6 address blocks     L
Lost employee productivity d      
Security intrusions e   H H
Foreign activities   M M
Interoperability issues   M/H M/H
spacer
Source: RTI estimates based on RFC responses, discussions with industry stakeholders, and a literature review.

a The relative designation (L = low, M = medium, and H = high) indicates the estimated level of cost to members of each stakeholder group. These costs are not incremental, but reflect differences in costs between stakeholder groups. The blank spaces indicate that a particular cost category does not affect all stakeholder groups.

b The “brains” of the router are commonly found on line cards.

c Portions of the first column, principally relating to software upgrades by hardware, software, service providers, is blank because the costs of these activities are reflected in the corresponding categories in the “Enterprise Users” column.

d Because of unexpected down-time during transition period.

e Based on unfamiliar threats.

As part of the discussion in this section we provide some insight into which stakeholder groups will end up bearing the costs and which are most likely to appropriate the benefits associated with IPv6.

2.2.1 Hardware, Software, and Service Vendors

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, including companies that offer training, service and support. Obviously, these companies will need to integrate IPv6 capabilities into their products and services, if they have not already done so, in order for IPv6 capabilities to be available to end users and ISPs. Once IPv6-capable products are installed in user networks and their labor forces have been trained, 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-capable products and services largely because of demand outside the United States (e.g., Asia).

Comments received suggest that the majority of the costs being incurred by hardware and software developers include labor-intensive research and development (R&D) costs and training costs. [ 123 ] These costs, however, have not been large enough to deter most of those companies from beginning to develop IPv6 products and capabilities. R&D activity has generally been conducted in small intra-company 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 issues. [ 124 ]

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. [ 125 ] NAv6TF, in collaboration with the DoD and the University of New Hampshire, has launched the Moonv6 test bed, which has stimulated interoperability testing by U.S. and foreign vendors wishing to offer IPv6 products or services. [ 126 ]

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. [ 127 ] 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. A point of diminishing returns will likely be reached at some future date, however. [ 128 ] In addition, several commenters stated that substantial foreign competition could drive up the relative prices of U.S. companies’ products and services because with less market share they would not be able to spread R&D and other costs across a large customer base. [ 129 ]

2.2.2 ISPs

ISPs comprise two main categories: (1) companies (e.g., AOL, Earthlink, and myriad smaller companies) that provide Internet access service to corporate, governmental, nonprofit, and independent Internet users and (2) companies that own and maintain the backbone hardware and software of the Internet (e.g., MCI, Sprint, AT&T). The categories overlap because companies that own the backbone Internet infrastructure (i.e., Category 2 companies) often provide Internet access service to customers, either directly or through a subsidiary. Today, most backbone transport networks have already upgraded their major routers and routing software to accommodate IPv6. As a result, providing IPv6 connectivity to customers who do not require additional equipment, service, or support would be relatively low cost. Consequently, this analysis focuses on those ISPs in Category 1 that have large customer service provision capabilities.

These ISPs will likely incur relatively high transition costs as they enable IPv6-capable hardware and software and work through system interoperability problems. To date, however, little demand has appeared in the United States for IPv6 services or applications. [ 130 ] 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. [ 131 ]

For Category 1 ISPs to offer a limited amount of IPv6 service, they would need to integrate some transition mechanism(s), such as tunneling. [ 132 ] The costs of doing so will probably not be large. [ 133 ] 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, some of those ISPs are performing some limited testing. [ 134 ] Before ISPs elect to offer widespread IPv6 service, however, they will need assurances that current service offerings would not be affected in any way. Such assurances would likely require much more testing and significant additional hardware, software, and training costs, [ 135 ] possibly increasing the costs by 200 to 300 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. [ 136 ]

If IPv6-capable products and services being offered in foreign markets (e.g., Asia) are transferable to the U.S. market, those ISPs offering IPv6 services abroad will have absorbed some of the initial costs of developing deployment strategies for those products and services. A majority of R&D costs attributable to IPv6 implementation, like any other advanced technology, may be borne by early adopters. Thus, one possible scenario is that U.S. ISPs may be able to take advantage of the lessons learned overseas to roll out those products domestically at a lower cost than would have been the case if the U.S. ISPs had deployed those offerings first. Such costs, however, are not likely to be a dominant factor for most application services in the long run. [ 137 ]

In the United States today, NTT/Verio is currently the only ISP providing end-to-end IPv6 service. [ 138 ] NTT/Verio began their move to IPv6 as early as 1997, replacing and upgrading hardware and software components to be IPv6 capable. By spreading out transition costs, including hardware and software costs, training, and the development of network administration software tools, NTT/Verio has been able to upgrade for very little additional costs above standard upgrade, training, and testing costs. [ 139 ] Although the transition may not be as inexpensive for other ISPs, NTT/Verio’s experience illustrates how careful planning can help reduce transition costs whether or not “first-mover” advantages are realized.

Most experts agree that a shift to IPv6 over a short period of time will be more expensive than making the transition as part of a normal life-cycle update. [ 140 ] 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 for ISPs and Internet users 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. [ 141 ]

Thus, until customers begin demanding IPv6 service, most U.S. Category 1 ISPs have little incentive to incur any major additional costs to transition; as such, in the short term, most ISPs are likely to continue testing IPv6 and offer limited IPv6 connectivity as requested. However, as more hardware and software become IPv6 capable through cyclical replacements, continued standardization efforts by the IETF, [ 142 ] and testing by many parties, these ISPs will probably be in a position to recoup investment costs associated with IPv6 service.

2.2.3 Internet Users

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

Larger organizations, such as corporations, government agencies, and nonprofits, will incur considerably more costs than home or small network users. The relative level of these costs, however, will depend on existing network infrastructure and administrative policies across organizations, the extent to which a specific organization wants to operate IPv6 applications, and whether it intends to connect to other organizations using IPv6. This section will focus on these larger costs.

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. However, Internet2 indicated that their experimental system was implemented and maintained by leading industry experts. It is unclear what issues might arise from implementation by less experienced staff. [ 143 ] Another commenter points out, however, that if normal upgrade cycles are assumed to provide IPv6 capabilities, transition costs will be limited to training and some reconfiguration. [ 144 ]

Internet users, as a whole, constitute the largest stakeholder group. The robustness of and diversity within this group demands 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 IPv4-based network hardware will need to be upgraded with IPv6 capabilities. [ 145 ] Specifically, high-end routers, switches, memory, and firewalls all will need to be upgraded to provide the memory and processing needed to enable large scale IPv6 use within a network at an acceptable level of performance. 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 every three to five years for most routers and servers, but potentially longer for other hardware such as mainframes). [ 146 ] 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. [ 147 ] Software upgrades include server software, server and desktop 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 costs that user organizations envision pertain to element management, network management, and operations support systems that are often network specific and will need revised software coding to adjust for IPv6. Given the anticipated growth in IPv6-capable software, it is likely that if Internet users upgrade their commercial application software in three or four years, they will acquire IPv6 capabilities. However, 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, [ 148 ] although most view it as a one-time cost that could be spread out over several years. The magnitude of these training costs will, of course, depend on existing staff’s familiarity and facility with IPv6. On a daily basis, the change in operating procedure for IPv6 will be minimal. Most network staff, however, will need some understanding of the required network infrastructure changes and how they might affect security or interoperability. [ 149 ] NAv6TF notes that the relative programming skills of software engineers at a particular company could substantially affect upgrade costs. [ 150 ] 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 five or more years. Additionally, increased network maintenance costs following IPv6 implementation could be more pronounced depending on the relative level of IT staff skills and technical understanding. Similarly, training costs should be minimal for large organizations with existing IPv6 expertise (e.g., universities).

For mid-size organizations where IT staff perform multiple functions, staff training could be a significant share of the IPv6 transition costs. If non-IT staff need to alter their activities based on IPv6 use, training will be necessary for them, though generally this should not occur. [ 151 ] 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 resources (e.g., personnel and/or time) 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. For example, in a dual-stack network, two standards will have to be supported; thus, security intrusions will likely increase in the short term (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 internally over an extended period or through shared initiatives. [ 152 ] For U.S. users and vendors, costs would also be lower in a scenario where the early deployment issues are encountered and resolved in foreign countries. [ 153 ]

2.3 International Competitiveness

The pace of IPv6 deployment in the United States potentially raises issues broader than the costs incurred by individual producers and users. For example, actions by governments in Asia and Europe to promote deployment of IPv6 in their countries suggest that those governments believe that their domestic firms may gain competitive advantages from early adoption of the new protocol. More specifically, some foreign governments appear to see an opportunity to use the development and deployment of IPv6 to strengthen their position in global IT markets, particularly in Internet equipment, software, and services. [ 154 ] Some U.S. stakeholders worry that if the United States loses its current technical and market leadership in the Internet sector, recapturing that position will be difficult. [ 155 ]

2.3.1 First-Mover Advantages

Companies that first introduce or adopt a particular technology (“first movers”) may in some circumstances have the ability to create barriers to subsequent entry or to influence the adoption decisions of other companies. [ 156 ] By so doing, the first mover may be able to dominate the markets associated with that technology and generate monopoly profits. [ 157 ]

Some experts question whether first movers will be able to capture sustainable competitive advantages in Internet markets, including those for IPv6 equipment, services, and applications. In applications markets, for example, the rapid pace of technological advances makes sustaining first-mover technology or information advantages difficult. [ 158 ] In addition, the short life expectancy of Internet technologies and the regular replacement of hardware and software applications reduce lock-in costs, as long as legacy systems are not a major obstacle.

Moreover, deployment costs are typically higher for innovators and early adopters of new technologies compared to the costs for imitators and later adopters. In any R&D-intensive industry, information spillovers counter first-mover advantages. [ 159 ] If U.S. companies are able to learn from the international community’s early IPv6 adoption activities, U.S. deployment costs may be lowered and lead to competitive products and services with lower entry costs. Finally, empirical research has shown that the greater learning curve requirements for first movers lead to higher failure rates for these first-to-market participants. [ 160 ]

On the other hand, while imitators can take advantage of “lessons learned” by the innovator, later entrants into the relevant markets still must acquire infratechnologies [ 161 ] and other infrastructure, appropriate skills, and market experience in order to be competitive in emerging markets. The cost advantage gained from “borrowing” an innovator’s learning curve may or may not be sufficient to overcome the scale and installed base advantages that accrue to first movers. Moreover, successful imitation frequently requires time compression with respect to acquiring infrastructure and applications capabilities. As the economic analysis summarized in section 2.3 indicates, more rapid transition will likely raise costs and may do so to a greater extent than the amount of time compression.

2.3.2 First-Mover Advantage and U.S. Competitiveness

Judging from the published literature, the RFC comments, and the discussion at the July 28, 2004 public meeting, U.S. stakeholders are aware of first-mover concerns, but some question whether significant adverse potential competitive effects would ensue if the United States lagged behind other nations in deployment of IPv6. [ 162 ] At this time, most markets for IPv6 products and services are in their infancy. Until applications and services markets begin to mature, determining whether efficiency gains or learning curve effects will generate sustainable first-mover advantages will be difficult.

An important point for this analysis is the fact that first-mover strategies are usually discussed with respect to the benefits and costs of innovation in applications. However, the issue here is the evolution of a critical infrastructure—a standard. Standards provide several functions that enable innovation: 1) reducing variety (e.g., one standard versus several incompatible protocols), which thereby presents larger potential markets and thus economies of scale; 2) providing information (e.g., format and timing of message transmissions), thereby reducing the costs of innovation; 3) assuring quality (e.g., accuracy and assurance of message delivery); and 4) assuring compatibility/interoperability (e.g., seamless integration of subnetworks and applications), thereby realizing network externalities. [ 163 ]

Several parties voiced strong concern that other countries are advancing IPv6 at a much faster rate than the United States, and that without government action to stimulate or assist U.S. deployment, the United States could lose its leadership role in Internet infrastructure and applications markets. [ 164 ] Another commenter indicated that a lack of U.S. technical experience in new IPv6-based equipment and applications development could put domestic firms at a disadvantage, as other countries would be able to work without NATs and other IPv4 work-arounds. [ 165 ] Other commenters focused on resource constraints. If the transition to IPv6 in the United States lags behind the international community, U.S. vendors will need to allocate resources to support both IPv4 and IPv6 to a greater degree. [ 166 ] As a result, U.S. firms would have fewer resources to devote to IPv6-only products and services.

In addition, the lack of a robust standards infrastructure for IPv6 in the United States that would be available to potential first movers could conceivably act as a barrier to innovation because the inefficiencies resulting from continued use of the existing standard could significantly reduce expected profits. Conversely, the cost of implementing a new standards infrastructure (as discussed in Section 2.2 above) is substantial and not returnable to individual private firms. This situation raises a potential “chicken-or-egg” problem, although the IETF has attempted to eliminate such a concern by creating mechanisms to promote interoperability between IPv4 and IPv6 networks, thereby facilitating a gradual but reasonably efficient transition strategy. [ 167 ]

To help ensure against the possibility of substantial catch-up expenditures, several commenters suggested that government incentives could be used (e.g., tax breaks or grants) to help offset transition costs. [ 168 ] However, other stakeholders have warned that government incentives would be unwise because they might skew the natural path of technology development or interfere with ongoing activities in the commercial marketplace. These stakeholders prefer that government simply participate in the market by adopting IPv6 when it is beneficial to its own needs. [ 169 ]

This report finds that corporate or industrial users have yet to realize significant productivity benefits from operating IPv6 versus IPv4, and may incur higher costs from early adoption of IPv6. [ 170 ] When more advanced IPv6 applications become available that represent efficiency gains, U.S. companies should be sufficiently well-positioned via ongoing hardware and software upgrades to take advantage of these opportunities. As discussed in Section 5.1, no market failures have been identified that would limit rapid deployment of IPv6 once future applications emerge.


Previous Section Table of Contents Next Section


FOOTNOTES

[44] See, e.g., Microsoft Comments at 4-6; Motorola Comments at 2-4.

[45] The timing of the transition from IPv4 to IPv6 for any particular adopter, as well as the existing network infrastructure, could dramatically affect the costs incurred and the benefits realized.

[46] See Microsoft Comments at 3 (4.3 billion addresses); Sprint Comments at 3 (same). Because some of these addresses are needed for administrative purposes, all 4.3 billion cannot be assigned for use by individuals or organizations.

[47] See Sprint Comments at 3 (1x1030 addresses for every person); Joe St. Sauver, “What’s IPv6 . . . and Why Is It Gaining Ground?”, at http://cc.uoregon.edu/cnews/spring2001/whatsipv6.html (last visited Dec. 15, 2004) (3.7x1021 addresses per square inch). As with IPv4 addresses, not all of these IPv6 addresses can be assigned to users.

[48] See, e.g., NTT/Verio Comments at 10-11 (identifying future applications that could benefit from expanded IPv6 address space).

[49] See North American IPv6 Task Force (NAv6TF) Comments at 4.

[50] See Cisco Comments at 1; MCI Comments at 3; Motorola Comments at 4; NTT/Verio Comments at 5, 10. In contrast, one commenter questions whether each new mobile device will need its own IP address. See Network Conceptions Comments at 7.

[51] See Cisco Comments at 2; Dillon Comments at 1; GSA Comments at 2, 6; NTT/Verio Comments at 10. See also Public Meeting Transcript, supra note 41, at 65 (remarks of Paul Liao, Panasonic USA) (availability of IPv6-addressable electronic equipment in the home could make it easier and cheaper for companies to deliver software upgrades that could expand or modify the capabilities of that equipment); id. at 48-49 (remarks of Paul Liao and Stan Barber, NTT/Verio) (IPv6-addressed taxicabs in Tokyo can inform meteorologists when the cabs’ windshield wipers are on, providing the weathermen with more detailed information about rainfall patterns in the city).

[52] RIRs are responsible for allocating IP address space to organizations (and in some cases individuals) in their respective regions. The American Registry of Internet Numbers (ARIN) is the RIR for the United States.

[53] See VeriSign Comments at 2. Some address reclamation has occurred. Stanford University, which was originally allocated nearly 17 million IP addresses, restructured its network in 2000 and gave back a Class A address block equal to approximately 16 million IP addresses. See Carolyn Marsan, “Stanford Move Rekindles ‘Net Address Debate,’” NetworkWorldFusion (Jan. 24, 2000), at http://www.nwfusion.com/news/2000/0124ipv4.html.

[54] Currently, the American Registry of Internet Numbers (ARIN) policies state that unused address space designated for return should be returned as agreed to the upstream provider that allocated the addresses and that 80 percent of the numbering space allocated must be utilized before additional addresses are requested. See ARIN’s Number Resource Policy Manual at §§ 4.2.2.1.4, 4.2.2.2.3, 4.2.4.1, 4.2.4.2 (Oct. 15, 2004), at http://www.arin.net/policy/.

[55] Id. § 6.3.5.

[56] See, e.g., Network Conceptions Comments at 1; Sprint Comments at 1.

[57] See Alcatel Comments at 2 (e.g., deployment of NATs, implementation of CIDR, use of Dynamic Host Configuration Protocol (DHCP)).

[58] See, e.g., Cisco Comments at 1. But see Public Meeting Transcript, supra note 41, at 55-56 (remarks of Latif Ladid, NAv6TF) (excluding addresses controlled by the U.S. government and about 100 companies, “U.S. economy has only about 10 percent of the [IPv4] address space worldwide which is less than what Europe has and almost the same number as Asia”).

[59] See John Lui, “Exec: No Shortage of Net Addresses,” CNET News.Com (June 24, 2003), at http://news.com.com/Exec+No+shortage+of+Net+addresses/2100-1028_3-1020653.html (interview with Paul Wilson, director general of the Asia-Pacific Information Centre (APNIC)); Ikeda and Yamada, supra note 38. Indeed, there are widely different estimates as to when the existing supply of IPv4 addresses may finally run out. See, e.g., Lui, supra (estimate of Paul Wilson); Geoff Huston Comments passim; NTT/Verio Comments at 2-10.

[60] See supra notes 53 and 54, and accompanying text.

[61] The policies that govern management of IP resources at the various RIRs, including address allocation, are developed by stakeholders from the Internet community. The RIRs themselves do not develop those policies. For example, according to ARIN’s “Internet Resource Policy Process,” any individual may submit a proposal to alter these existing policies. See ARIN, “Internet Resource Policy Evaluation Process,” (Jan. 22, 2004), at http://www.arin.net/policy/ipep.html.

[62] Andrew McLaughlin, “Bad Journalism, IPv6 and the BBC,” Circle ID (Nov. 7, 2003), http://www.circleid.com/article/369_0_1_0_C/.

[63] Lui, supra note 59.

[64] Steps taken to improve the allocation of IP addresses on a going-forward basis will not correct imbalances in past allocations. The relevant authorities may need to enact measures to reclaim previously allocated but unused addresses or address blocks.

[65] The Internet Corporation for Assigned Names and Numbers (ICANN) allocates blocks of IP addresses to each RIR according to established needs. It performs this function as a result of a contract with the U.S. Department of Commerce. See Dep’t of Commerce, NTIA, “IANA Functions Purchase Order,” at http://www.ntia.doc.gov/ntiahome/domainname/iana.htm. When an RIR requires more IP addresses for allocation or assignment within its region, IANA makes an additional allocation to the RIR. End users in the U.S. are assigned addresses by ISPs, which obtain addresses from the RIR serving the United States, ARIN. See Internet Assigned Numbers Authority, “IP Address Services,” at http://www.iana.org/ipaddress/ip-addresses.htm (last modified Apr. 12, 2005). Deployment of IPv6 addresses through this process began in 1999.

In July 2004, ICANN added IPv6 to the root DNS zone, thereby enabling those servers to handle such addresses. Soon thereafter, the top-level domains of Japan and Korea (.jp and .kr, respectively) became the first to support IPv6. See ICANN, “Next-Generation IPv6 Addresses Added to the Internet’s Root DNS Zone” (July 20, 2004), at http://www.icann.org/announcements/announcement-20jul04.htm; John Blau, “ICANN adds IPv6 to root servers,” Computerworld (July 22, 2004), http://www.computerworld.com.au/index.php/id;586624082;fp;4;fpid;78268965.

[66] NAv6TF Comments at 34.

[67] VeriSign Comments at 2, 8.

[68] See NEWTON’S TELECOM DICTIONARY 563 (20th ed. 2004). Because NATs use port address translation (PAT), NAT/PAT could be used where NAT is referenced in this discussion.

[69] See Hain Comments at 3.

[70] See id. at 11.

[71] RTI Telephone Conversation with Rod Wallace, IPv6 Leader, Office of the Chief Technology Officer, and Elwyn Davies, IPv6 Technologist, Nortel Networks (Oct. 10, 2003) (“Nortel Discussion”).

[72] Hain Comments at 2. See also Cisco Comments at 8 (unfettered E2E communications will allow for more rapid prototyping of new services, which is critical to developing those services); Alcatel Comments at 3; MCI Comments at 3.

[73] See, e.g., Public Meeting Transcript, supra note 41, at 60 (remarks of Tony Hain, Cisco) (removing NATs would allow companies to redirect personnel resources currently used to create work-arounds for particular applications towards development of the applications themselves); id. at 132 (remarks of Rick Summerhill, Internet2) (elimination of NATs would simplify the writing of applications software).

[74] See Cisco Comments at 5-6 (work-arounds scale well in most consumer markets, less well for enterprises and service providers).

[75] See Internet2 Comments at 4. The task of creating work-arounds typically must be repeated for each new application and frequently for different types of NATs.

[76] See, e.g., Cisco Comments at 9.

[77] See id. at 2; Internet2 Comments at 2-3; Microsoft Comments at 5; NAv6TF Comments at 6.

[78] See, e.g., Internet2 Comments at 1-2.

[79] See, e.g., OMB House Government Reform Testimony, supra note 42, at 1.

[80] RTI’s estimates are based on Census Department data on automobile and appliance manufacturing and repair. Some of this remote monitoring capability is of course available today through unidirectional communications (i.e., from the appliance to the service provider) that do not require that the appliance be uniquely addressable. These applications would not need the expanded address space afforded by IPv6, or the removals of any NATs between the appliance and service provider.

[81] See, e.g., Marjory S. Blumenthal and David D. Clark, “Rethinking the design of the Internet: the end-to-end model vs. the brave new world,” 1 ACM Transactions on Internet Technology 70, 71, 92-93 (2001), available at http://cybersecurity.stanford.edu/forum/files/blumenthal_clark.pdf.

[82] See BellSouth Comments at 4-5. See also Interview by RTI with John Streck, Centaur Labs, Research Triangle Park, N.C. (Mar. 16, 2004) (“March Streck Interview”) (likelihood of the world, or even United States alone, moving completely back to the “open architecture” Internet model is not very high).

[83] Additionally, 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. See Public Meeting Transcript, supra note 41, at 15-16 (remarks of Vint Cerf, MCI) (indicating that his cable company allotted each customer one IP address and charged $5 per month for each additional address).

[84] See Alcatel Comments at 4; NTT/Verio Comments at 13-14.

[85] See Cisco Comments at 5.

[86] See infra Section 3.

[87] See Public Meeting Transcript, supra note 41, at 15 (remarks of Vint Cerf, MCI), 58 (remarks of Paul Francis, Cornell University), 178 (remarks of Preston Marshall, DARPA).

[88] NAT boxes and firewalls can be modified, albeit at some cost, to coexist in an IPv6 networked environment, possibly allowing some forms of direct E2E communications to take place. March Streck Interview, supra note 82.

[89] For an IETF working document that describes how mobility support can be provided in IPv6, see D. Johnson, et al., “Mobility Support in IPv6” (June 30, 2003), at http://users.piuha.net/jarkko/publications/mipv6/drafts/mobilev6.html (expired Dec. 29, 2003) (last visited May 2, 2005).

[90] NTT/Verio Comments at 10.

[91] Sprint Comments at 11.

[92] Thus, devices commonly found in the home (such as lights, dishwashers, refrigerators, cameras, home computers, and other home appliances) can be assigned IP addresses, linked together on home networks, and connected to the Internet, allowing home owners to control such devices remotely. See Motorola Comments at 4; March Streck Interview, supra note 82.

[93] Cisco suggests that IPv4 networks can also handle any mobile applications that exist today. Cisco believes, however, that a large scale deployment of mobile IP “will be done more easily through Mobile IPv6 and its feature set.” Cisco Comments at 6.

[94] Microsoft Comments at 5.

[95] NAv6TF Comments at 12-13. The autoconfiguration and neighbor discovery mechanisms of IPv6, which are used for node discovery, also eliminate the need for DHCP or foreign agents currently used to route mobile traffic. See Wolfgang Fritsche and Florian Heissenhuber, “Mobile IPv6: Mobility Support for the Next Generation Internet,” at 18 (Aug. 16, 2000), at http://www.6bone.sk/zaujim/MobileIPv6_Whitepaper.pdf.

[96] Sprint Comments at 6. The mobility protocols within IPv6 are designed to avoid routing packets from a correspondent node to the mobile node via the home agent. This route optimization mechanism will reduce transport delay and save network capacity. Route optimization is designed to be an integral part of Mobile IPv6 and is also available as an added functionality for Mobile IPv4. See Fritsche and Heissenhuber, supra note 95, at 18.

[97] For example, a laptop linked to the Internet at home could be carried to work and then connected to the Internet there. Alternatively, a mobile phone user, who is browsing the Web, could remain seamlessly connected to the Internet while traveling from Boston to New York by linking to networks along the way. In both cases users can be reached by simply querying their home IP addresses.

[98] An improved ability to provide such seamless mobility services will likely be a significant incentive for mobile service providers to deploy IPv6. See, e.g., Public Meeting Transcript, supra note 41, at 69-70 (remarks of Mark Desautels, CTIA).

[99] See Wikipedia: The Free Encyclopedia, “Internet Protocol”, at http://en.wikipedia.org/wiki/Internet_Protocol (last modified Nov. 29, 2004).

[100] See hyperdictionary, “Quality of Service: Dictionary Entry and Meaning,” at http://www.hyperdictionary.com/search.aspx?define=quality+of+service (last visited Dec. 21, 2004) (quality of service is “the performance properties of a network service, possibly including throughput, transit delay, and priority”).

[101] See Hain Comments at 3; Internet2 Comments at 3-4.

[102] See Protocol Dictionary, “IPv6 (IPng): Internet Protocol version 6,” at http://www.javvin.com/protocolIPv6.html (last visited Dec. 21, 2004).

[103] S. Deering and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” 30 (Dec. 1998), at http://www.ietf.org/rfc/rfc2460.txt.

[104] Lawrence Roberts, “QoS Signaling for IPv6,” § 1.1, at 2 (Dec. 11, 2003), http://ftp.tiaonline.org/tr-34/tr3417/Working/Dec-03 (last visited July 16, 2004) (document is only available with a password).

[105] J. Rajahalme, et al., “IPv6 Flow Level Specification,” Internet Society, RFC 3697 (March 2004), at ftp://ftp.rfc-editor.org/in-notes/rfc3697.txt. A “flow” is “a sequence of packets sent from a particular source to a particular . . . destination that the source desires to label as a flow.” Id. at 1 (§ 1).

[106] See id. at 2 (§1).

[107] See id. at 3 (§ 4) (“To enable flow-specific treatment, flow state needs to be established on all or a subset of the IPv6 nodes on the path from the source to the destination(s).”). The presence of NATs may also complicate deployment of QoS. See Internet2 Comments at 4.

[108] March Streck Interview, supra note 82. The cost to upgrade to IPv6 and adjust a network to use the capabilities of IPv6 (e.g., remove NATs) could be very costly depending on the specific setup of a particular network.

[109] See Cisco Comments at 5; GSA Comments at 6; Microsoft Comments at 5; Sprint Comments at 8. See also Public Hearing Transcript, supra note 41, at 57 (remarks of Latif Ladid, NAv6TF) (research by Forrester Research Group suggests that autoconfiguration could pay for IPv6 implementation within one year). With autoconfiguration, a user can simply plug a host device into the network and it will automatically configure an IP address and network prefix and find all available routers. GSA Comments at 6.

[110] See Cisco Comments at 4.

[111] See Internet2 Comments at 2-3 (“expert ISP engineers and ordinary users have their time wasted trying to debug network problems either caused by the NAT boxes or made more difficult to diagnose by the NAT boxes”).

[112] NAv6TF notes that voice and data are converging into one platform. NAv6TF Comments at 23. If middleware, such as gateways and NATs, is required everywhere, the cost for single-vendor solutions may be containable, but multi-vendor solutions will be costly interoperability propositions.

[113] See Cisco Comments at 4.

[114] See infra Section 2.2 for more information on the sorts of costs that may be incurred in the transition to IPv6.

[115] This conclusion is based on RTI’s analysis of RFC comments, extensive literature reviews, and discussions with stakeholders and experts.

[116] See March Streck Interview, supra note 82.

[117] Network processing to maintain NAT translation tables can cause a bottleneck if network traffic grows very rapidly.

[118] In this statement, “routing tables” generally refers to backbone routers and national DNS routing tables. As the number of IP addresses has grown, these routing tables have tracked individual IP addresses rather than utilizing hierarchical mapping, in which one IP address can afford entry to many others. In IPv6 routing tables, a more hierarchical approach could be used to reduce the size of backbone routing tables, as well as those of all routers. The potential network efficiency gains, however, would be experienced at the backbone level.

[119] March Streck Interview, supra note 82.

[120] For a case study of how and at what pace an enterprise might adopt IPv6 and the sorts of costs it would likely incur, see Appendix A.

[121] This assumes that adoption occurs after routine cyclical upgrades provide IPv6 capabilities in hardware and software to the user community.

[122] This conclusion is based on RTI’s analysis of RFC comments, extensive literature reviews, and discussions with stakeholders and experts See also Cisco Comments at 10 (as IPv6 becomes more prevalent, "customers will be able to transition based on their need to do so without excessive regard to hardware costs").

[123] See also Hain Comments at 11; NAv6TF Comments at 28; Public Hearing Transcript, supra note 41, at 62 (remarks of Stan Barber, NTT/Verio) (labor costs will be the most significant deployment cost, but the costs will be mitigated if the labor force is familiar with IPv4).

[124] Nortel Discussion, supra note 71.

[125] See Cisco Comments at 27; Motorola Comments at 5-6. See Section 4 infra for more information on interoperability costs and considerations.

[126] See Cisco Comments at 21; Hain Comments at 8-10; NAv6TF Comments at 21, 36, 43; NTT/Verio Comments at 28.

[127] See BellSouth Comments at 6; Cisco Comments at 13.

[128] See Cisco Comments at 13. See infra Section 2.4 for more detail on such “first-mover” considerations.

[129] See Cisco Comments at 13; Dillon Comments at 1.

[130] See supra notes 19-27 and accompanying text.

[131] See NAv6TF Comments at 24.

[132] “Tunneling” is a technology that enables one network to send its data via another network's connections. Tunneling works by encapsulating a network protocol within packets carried by the second network. Isp.webopedia.com, “Tunneling” at http://isp.webopedia.com/TERM/T/tunneling.html (last visited Dec. 21, 2004). In the IPv6 context, an ISP would “tunnel” by encapsulating an IPv6 message in an IPv4 packet, enabling that message to be routed to an IPv6-enabled host via an IPv4 network. Firms could establish such IPv6-to-IPv4 on their own, or ask a so-called “tunnel broker” to establish the necessary connection.

[133] RTI Telephone conversation with Joe Houle, Technology Consultant, IP Network Architecture, AT&T, in Arlington, VA (Dec. 11, 2003).

[134] Id.

[135] Id.

[136] March Streck Interview, supra note 82.

[137] See Cisco Comments at 13.

[138] NTT/Verio is not providing IPv4 to IPv6 or IPv6 to IPv4 service; therefore, customers would need to maintain dual-stack networks themselves or integrate translation techniques to continue to communicate with IPv4 networks.

[139] NTT/Verio Comments at 21.

[140] See, e.g., Cisco Comments at 12.

[141] See id.

[142] Some experts have stated that certain inadequacies exist in IPv6 standards, such as management information base and billing systems specifications, and that others may develop as IPv6 testing continues. See id. at 17; NAv6TF Comments at 32-33.

[143] RTI Telephone Conversation with Rick Summerhill, Director, Network Research, Architecture and Technology, Internet2 (Nov. 5, 2003) (“Internet2 Discussion). Internet2 is a network of approximately 200 educational and institutional Internet users. The 11 backbone routers that support the Internet2 network have recently been upgraded to new Juniper routers, which are dual-stack with IPv4- and IPv6-enabled hardware.

[144] See Hain Comments at 11.

[145] See BellSouth Comments at 5.

[146] See, e.g., Cisco Comments at 10, 12.

[147] See BellSouth Comments at 6; Dillon Comments at 2; Hain Comments at 11. Cisco additionally indicated that these costs can be amortized over a gradual development cycle. Cisco Comments at 11.

[148] See GSA Comments at 8; Hain Comments at 13, 14-15; NAv6TF Comments at 28. See also Public Hearing Transcript, supra note 41, at 62 (remarks of Stan Barber, NTT/Verio) (labor costs will be the most significant deployment cost, but the costs will be mitigated if the labor force is familiar with IPv4).

[149] See Cisco Comments at 12.

[150] See NAv6TF Comments at 29.

[151] Once dual-stack capabilities are enabled by default in a host operating system (e.g., as Microsoft plans to do in the next version of Windows, see Microsoft Comments at 8), the user should not be aware whether IPv4 or IPv6 packets are being sent or received. Thus, no training should be necessary, unless new IPv6-specific applications are requested by users.

[152] See BellSouth Comments at 6; Cisco Comments at 12; Hain Comments at 16.

[153] See BellSouth Comments at 6; Cisco Comments at 13.

[154] See, e.g., Ikeda and Yamada, supra note 38, at 2, 12; Hain Comments at 1; Motorola Comments, at 5; Dillon Comments at 1. See also Cisco Comments at 22 (Chinese carriers may feel political pressure to showcase China as a technology leader).

[155] See Alcatel Comments at 2; Cisco Comments at 24; Hain Comments at 8; NAv6TF Comments at 6-7.

[156] First-mover advantages arise from four general factors: (1) technology leadership, (2) preemption of scarce resources or assets, (3) scale economies producing an ability to charge lower prices, thereby expanding market share, and (4) an ability to “lock in” users due to the high costs of switching to alternative technologies or products. See Marvin B. Lieberman and David B. Montgomery, “First-Mover Advantages,” 9 Strategic Mgmt. J. 41 (1988).

[157] See Paul Stoneman, The Economics of Technological Diffusion 50-51 (Blackwell Publishing 2001). Monopoly profits which are frequently captured by innovators for a period of time are the reward for risk taking and provide the risk capital for investment in the next generation of the technology.

[158] See David Needle, “The Myth of the First Mover Advantage,” siliconvalley.internet.com (Apr. 5, 2000), at http://siliconvalley.internet.com/news/article.php/3541_333311.

[159] The term “spillover” refers to the fact that some benefits of a particular economic activity (e.g., R&D) frequently accrue (“spill over”) to parties other than the one that originally undertook the activity. “Information” or “knowledge spillovers” result from the movement of information from the originating firm to other producers (e.g., through publication of the originating firm’s basic research, through “reverse engineering” of the originating firm’s product by other firms, or by the movement of employees from the originating firm to other organizations). “Market spillovers” result when the operation of the market for a new product or process causes some of the benefits thereby created to flow to producers and consumers other than the innovating firm. See, e.g., Bronwyn H. Hall, "The Private and Social Returns to Research and Development", in Technology, R&D, and the Economy 140-141 (Bruce L.R. Smith and Claude E. Barfield, eds., 1995); Adam B Jaffe, "The Importance of ‘Spillovers’ in the Policy Mission of the Advanced Technology Program," 23 J. Tech. Transfer 11, 11-12 (1998), available at http://www.atp.nist.gov/eao/jtt/jaffe.pdf; Zvi Griliches, "The Search for R&D Spillovers," NBER Working Paper No. 3768 (Nat’l Bur. Economic Res. 1991), available at http://nber.org/papers/w3768.pdf.

[160] See Gerard J. Tellis and Peter N. Golder, “First to Market, First to Fail: Real Causes of Enduring Market Leadership,” 37 MIT Sloan Mgmt. Rev. 65 (1996).

[161] “Infratechnologies” are a diverse set of technical tools that are necessary to conduct efficiently all phases of R&D, to control production processes, and to execute marketplace transactions for complex technology-based goods. Examples include measurement and test methods, process and quality control techniques, evaluated scientific and engineering data, and the technical basis for product interfaces. These tools are called infratechnologies because they provide a complex but essential technical infrastructure. Many infratechnologies are adopted as industry standards, emphasizing their public good content. See Gregory Tassey, “Standardization in Technology-Based Markets,” 29 Res. Pol. 587, 595-597 (2000).

[162] See, e.g., Motorola Comments at 8-9; Public Hearing Transcript, supra note 41, at 172 (remarks of Rick White, TechNet).

[163] See Tassey, supra note 161, at 590-593.

[164] See Alcatel Comments at 4; Hain Comments at 17-18; Lockheed Comments at 5; NAv6TF Comments at 6-7. But see Public Meeting Transcript, supra note 41, at 167-168 (remarks of Rick White, TechNet) (questioning whether “lag” in U.S. deployment of IPv6 as compared to other countries would raise competitiveness concerns).

[165] Internet2 Discussion, supra note 143 (designing the next generation of Internet applications will be simpler in IPv6 because developers will not need to build on the more than 20 years of work-arounds embedded in IPv4).

[166] See Alcatel Comments at 4 (R&D activities could be diluted because new products and services will need to be dual protocol compatible, potentially causing U.S. companies to lag behind in developing next generation IPv6 applications). On the other hand, given that IPv4 and IPv6 will likely coexist for a lengthy period of time, equipment manufacturers and applications designers may be constrained to develop both IPv4 and IPv6-compatible products. Cf. Public Meeting Transcript, supra note 41, at 68-69 (remarks of Stan Barber, NTT/Verio) (emphasizing the importance of devising security tools that work with both IPv4 and IPv6).

[167] See, e.g., Hain Comments at 10-12.

[168] See Motorola Comments at 2; NAv6TF Comments at 46.

[169] See, e.g., Microsoft Comments at 12 n.8.

[170] RTI Telephone Conversation with John Streck, Centaur Labs (May 18, 2004).

Home | Publications | Newsroom | Policy | International | Spectrum | Grants | Research
National Telecommunications and Information Administration, U.S. Department of Commerce
1401 Constitution Ave., NW Washington, DC 20230