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

National Telecommunications and Information Administration
National Institute of Standards and Technology

Previous Section Table of Contents Next Section


As discussed in Section 2, many of the original concerns motivating the development of IPv6, such as perceived address space limitations and security needs, may not be driving forces for rapid deployment of IPv6 in the United States, at least in the near term. That does not imply, however, that potential benefits of adopting IPv6 do not exist. Nor does it mean that a potential role for government does not exist with respect to influencing the realization of those benefits. The public comments, discussions with industry stakeholders, and views expressed by participants in the July 28, 2004 public meeting suggest that government could pursue one or more of the following strategies:

• play a role in coordinating and supporting the development of IPv6 standards, protocols, and conformance;

• be an active participant in identifying and facilitating solutions for technological and interoperability issues; and

• stimulate adoption as a major consumer of IPv6 products and services when it is in the best interest of the individual government agencies.

However, industry should continue to take the lead in developing the IPv6 standards architecture, with coordination support and participation from government. Similarly, industry consortia and academic institutions should take the lead in conformance testing and development of interoperability solutions to support implementation, with support and participation from government. Finally, government has an important role to play as a consumer of IPv6 products and services and, therefore, must carefully evaluate the security and economic factors affecting adoption and assimilation of the new technology into federal IT systems. Private-sector decisions to purchase IPv6 products and services should be market driven, without influence from the federal government.

This section addresses the circumstances that could warrant government action to stimulate deployment of IPv6 in the United States. Market failures are commonly cited as one of the primary motives for government involvement in technology development and deployment. Technological market failure refers to a condition under which either the producers and/or users of a technology underinvest relative to society’s optimal level of investment. Infratechnology research to support standardization, development of interoperability solutions, and conformance testing are all classic examples of where private returns on investment are not only less than social returns, but are below minimum private sector rates of return (so-called “hurdle rates”). In such cases, the needed infratechnologies and related services are commonly supported by some joint industry-government research and development (R&D) and technology transfer activities.

The levels of investment in such technical infrastructure will affect the potential realization of benefits from IPv6. Sufficient levels of investment are needed to minimize interoperability problems and to realize the positive network externalities generated by IPv6. [ 217 ] Because network externalities can be difficult for the private sector to appropriate, the public sector frequently supports investment in infratechnologies, such as interoperability protocols, conformance testing, and certification mechanisms, which reduce adoption costs and integrate market segments.

The timing of investments will also affect the costs and benefits of adopting IPv6. Accelerating deployment beyond normal equipment/software replacement life cycles will increase transition and replacement costs. Alternatively, lagging behind other nations in the deployment of technologies such as IPv6 may have competitiveness implications if foreign countries can capture first-mover advantages, although as discussed above, first-mover advantages do not appear to be a significant concern with respect to IPv6 at this time.

Thus, government can affect market evolution through its role as a major consumer of IPv6 products and services by stimulating private-sector investment. Its purchases for internal government use have the potential to influence the timing of IPv6 deployment by providing initial markets of sufficient size to enable learning curve progression by suppliers and to create product/service performance data for potential private sector consumers.

5.1 Potential Market Failures and Underinvestment in IPv6

The premise that markets may “fail” to invest in socially optimal amounts of R&D or new technologies has long been accepted by economists and is now being embraced by policy makers. [ 218 ] Much of the technological market failure literature focuses on underinvestment in innovation or in the creation or production of R&D-derived technology. However, these economic arguments are also applicable to the purchase and use of the technology that results from R&D.

5.1.1 Potential IPv6 Market Barriers and Underinvestment

Broadly speaking, underinvestment occurs because conditions exist that prevent firms from fully realizing or appropriating the benefits created by their investments, thereby causing firms to view prospective investments in new technologies as having expected rates of return below the firm’s minimum acceptable rate of return (hurdle rate). Although firms may recognize that there are spillover benefits to other markets or consumers, they are likely to ignore or heavily discount these benefits because they generally do not translate into increased profits for the investing firm. Moreover, research to support development of interoperability solutions, conformance testing, and other infratechnologies that become the basis of standards are all paradigmatic examples of cases where private returns to investment can be less than both social returns and private hurdle rates. As a result, those activities are frequently supported by government activities. [ 219 ]

Some uncertainty exists among U.S. ISPs and the software community concerning the likelihood that the private returns from IPv6 deployment and its subsequent market opportunities will justify the costs associated with the transition. [ 220 ] These concerns, however, are attributable less to appropriability issues and more to (1) uncertainties over users’ willingness to pay for IPv6 products and services, and (2) the negative effect of relatively high present value assigned to the up-front, and potentially substantial, transition costs.

5.1.2 Timing of Investment

In apparent contradiction to this assessment, most commenters see no need for government intervention and expect market forces to generate sufficient returns to drive efficient development and deployment of IPv6 over time. [ 221 ] A partial explanation may be that the transition technologies being developed and implemented by the IETF are viewed as ensuring that initially small negative network externalities will not hinder the adoption of IPv6. The IETF’s objective is for IPv6 systems, devices, and products to be able to interoperate with IPv4 networks and devices, thereby avoiding the potential disincentive to first movers attributable to negative economic incentives flowing from low network externalities. [ 222 ]

Other commenters assert that because the research needed to develop and deploy IPv6 may exhibit characteristics of a “public good,” a continuing need exists for government support. [ 223 ] Appropriability issues are most likely to occur as part of the development of generic infrastructure and applications technologies and infratechnologies needed to enable IPv6. On average, early actions or market interventions by government are likely to have the greatest impact on IPv6 deployment. One commenter notes that government activities that take place over the initial three years of IPv6 development and deployment may have significant long-term returns for both private (monetary) and public (economic growth) interests. [ 224 ]

In general, the closer R&D activities move toward commercialization, the less government should be involved. Market forces should be allowed to drive research for product and service development, where a greater likelihood exists that firms will be able to appropriate adequate returns and where innovators are more likely to face risk and reward conditions compatible with private-sector investment criteria. [ 225 ]

5.1.3 Concerns Related to the Chicken-or-Egg Dilemma

When complementary products or services are needed to realize the benefits from a new technology, the potential for a chicken-or-egg dilemma arises. One example of this phenomenon is the interrelationship between the adoption of high definition television (HDTV) sets and the availability of high-definition program content. In such cases, increased deployment of one of the component technologies generates externalities that increase the benefits to be derived from the adoption of the complementary technologies.

Similarly, for IPv6, the chicken-or-egg dilemma can be defined as the presence of disincentives for investment in supporting infrastructure until applications are deployed, contrasted with disincentives for investment in applications until supporting infrastructure is in place. If equipment manufacturers and software manufacturers are reluctant to make the first-mover investments until complementary IPv6 infratechnologies/standards are in place, an investment barrier could exist for some time.

Several commenters portrayed the chicken-or-egg issue as one in which demand is not currently high enough to push vendors and ISPs to deploy IPv6 products and services, while uncertainty exists on the part of potential buyers of those products and services regarding the nature, degree, and timeliness of IPv6 benefits. [ 226 ] Users are often initially risk averse with respect to potential innovations, however, thereby placing the onus on first movers to demonstrate the new technology’s potential. These first movers can be discouraged by a costly and incomplete infrastructure, including standards.

Commenters suggested that government could help resolve this chicken-or-egg dilemma by providing information on the current status of IPv6 infrastructure and conformance testing requirements. For example, infrastructure issues, such as the prevalence of NAT boxes and fear of interdependence between IPv6 applications and ISP routing services, are among the reasons why some networks are not testing and developing IPv6 applications. [ 227 ] Better information and access to transition tools could help.

Most commenters, however, indicated that the chicken-or-egg issue is not a serious problem, suggesting that markets are pushing IPv6 development and deployment in an appropriate time frame. They stated that transition mechanisms were designed specifically to circumvent the problem of having to “throw a switch,” and noted ongoing development activities resulting from market demand. [ 228 ]

A principal reason for this majority viewpoint is that IPv6 is not a totally new infrastructure. IPv6 and IPv4 are not exclusively different alternatives in that most benefits associated with IPv6 can also be realized by an enhanced IPv4 system (however, at potentially greater costs). For this reason, IPv6 will likely be deployed over time, and to differing degrees, by various stakeholder groups, as opposed to a mass and “instant” migration. Because IPv6 and IPv4 are designed to be interoperable during the transition period, moreover, this mitigates any potential chicken-or-egg dilemma.

The issue of demand by users, mentioned above, can be stated in terms of uncertainty over users’ willingness to pay for IPv6-enabled products. Consumers’ valuation of products and services, however, is typically not a market failure issue. For a problem to exist, barriers to market growth, in particular market aggregation, must be demonstrated. As noted above, large markets based on a new standard do not necessarily materialize instantly. Small market segments can appear that do not initially benefit from significant externalities. In fact, aggregation to larger markets typically occurs over time.

Nevertheless, segmentation, especially if accompanied by interoperability problems across segments, can inhibit the aggregation process. This issue must be monitored and addressed as warranted because global competition shortens life cycles and protracted barriers to penetration in domestic markets can (as discussed earlier) disadvantage domestic firms. The IETF transition strategy is designed to avoid such a situation by allowing initially small IPv6 markets to coexist (interoperate) with IPv4 applications, thereby avoiding an all-or-nothing transition. Nevertheless, coexistence does not guarantee market agglomeration for IPv6 applications.

In summary, the chicken-or-egg dilemma is probably not a serious concern with respect to the adoption of IPv6. The prevailing view seems to be that the drivers for IPv6 technologies will be consumer and enterprise applications that require IPv6 or that are impractical and more costly to implement via IPv4. Once these technologies materialize, ISPs should be able to rapidly enable hardware (which should already be IPv6 capable). Assuming that the initial markets are sufficiently large to enable at least modest network externalities and that adequate interoperability is provided, users will likely move quickly to adopt IPv6 software applications. [ 229 ]

5.1.4 Standards, Protocols, and Conformance Issues

The enabling of IPv6 technology cannot occur in the absence of standards and protocols that facilitate the coordination of the technologies along the supply chain and across different suppliers. Standards are a classic example of a public good because they represent a type of infrastructure where spillovers are not only socially desirable but necessary (by definition, a standard implies common, nonrivalrous use). In general, the Internet, by its very nature, is an open system, and the value of IP standards increases with the free flow of information. As a result, government has and will continue to have a role in how the Internet and related technologies evolve.

IPv6 development has been the subject of public and private research for many years, with the majority of findings residing in the public domain. However, many issues still must be addressed with respect to both infrastructure and applications. Because network externalities generated by nonproduct standards cannot be appropriated, private incentives to participate in the standards development process are typically well below socially optimal benefits and lead to suboptimal levels of participation. [ 230 ] Private returns alone are not likely to provide sufficient motivation to stimulate investments in these areas. [ 231 ] For this reason, the public sector has a stake in the IPv6 standards development process, program coordination, infratechnology development, and information dissemination. As noted above, government agencies are in a unique position to promote collaborative processes.

Specifically, government can participate with the private sector and other entities in implementing IPv6 through activities such as infratechnology development and conformance testing for the standards based on these infratechnologies. [ 232 ] For example, most respondents to the RFC indicated that government could continue and even expand its coordination and funding of research to develop solutions to interoperability problems. Protocols, conformance testing methods, and roadmap processes are critical for IPv6 systems developers and implementers. Moreover, respondents proposed that the U.S. government could support IPv6 research into interoperability with existing IPv4 systems [ 233 ] in addition to coordinating trials and tests of new IPv6-enabled devices—routers, hosts, PDAs, etc. Government could support both the harmonization of standards and interoperability testing activities, such as those currently being developed and performed by the University of New Hampshire, the TAHI project, and the European Telecommunications Standards Institute (ETSI). [ 234 ]

5.2 Potential Roles for Government Involvement in IPv6

The evidence gathered by the Task Force indicates a general consensus among various stakeholders that market forces should be allowed to drive the private sector transition from IPv4 to IPv6. No stakeholder indicated that significant market impediments exist for the adoption of IPv6; thus, all stakeholders believed that the federal government should refrain from actions that would significantly interfere with market forces. As MCI points out, “[a]lthough the deployment of IPv6 has occurred more slowly than was anticipated when the IETF began work on IPv6, there is no evidence of a market failure warranting government intervention. To a great extent, the current pace of IPv6 deployment reflects the normal weighing of benefits and costs that is associated with any technology deployment.” [ 235 ]

Many respondents referenced the GOSIP mandate and indicated that widespread concern and a lack of confidence remained within the computer networking community regarding government-led standardization activities. [ 236 ] One expert suggested that considering the negative impact of the GOSIP initiative, government should not consider a mandate for IPv6, but rather contribute to the development and deployment of IPv6 by facilitating testing and other collaborative efforts. [ 237 ] Commenting parties generally agreed that a government mandate for IPv6 deployment by industry is not appropriate at this time. [ 238 ]

However, most respondents also emphasized the public good nature of IPv6 and suggested that the public sector should foster development and deployment. This was frequently linked to concerns that the United States is lagging behind in developing and deploying IPv6 and that U.S. competitiveness and IT leadership will suffer without appropriate government activity.

In addition to national competitiveness, security issues were also cited as a motivating factor for government involvement in IPv6. Although there was no agreement on whether IPv6 would lead to security improvements, the public good nature of Internet security in general was acknowledged along with concerns regarding the maintenance of security during the transition to IPv6. [ 239 ] For example, commenters suggested that both government and the private sector need to work on trust relationships and key management (e.g., PKI development). [ 240 ]

One participant at the July 2004 public meeting coined the acronym “RUDE” to describe the sorts of government activities that could support the development and deployment of IPv6 in the United States:

• Research it independently or in collaboration with interested private-sector stakeholders;

• Use it in government communications networks;

• Defend the ability of U.S. firms to compete fully and fairly in global markets for IPv6 products, networks, and services; and

• Encourage IPv6 use by disseminating information inside and outside of government. [ 241 ]

5.2.1 Government Support for R&D

Respondents suggested the government should support certain types of R&D activities. Several government organizations that perform Internet-related testing and/or research were mentioned: NIST, the National Science Foundation (NSF); the Department of Energy (DOE); National Aeronautics and Space Administration (NASA), the Advanced Research Projects Agency/Defense Advanced Research Projects Agency (ARPA/DARPA), and the Department of Homeland Security (DHS). It was stated that organizations such as NIST and NTIA are ideally positioned to help foster and facilitate government collaboration with universities and industry. [ 242 ]

To ensure that IPv6-enabled services are deployed in a timely manner, the government could work to build the necessary base of skilled human resources in order to sustain the research effort and to encourage the acceleration of standards and specifications work. Suggestions for specific research focus areas include interoperability, security, and transition mechanisms. Additionally, the government might support the development of new applications and possibly initiate test beds similar to Moonv6, as appropriate to meet the needs of its agencies. Government funding for advanced test bed deployment could be made available and advertised appropriately. [ 243 ]

Some of the areas that commenters identified for further research include the following: [ 244 ]

• testing of IPv6’s interoperability with existing IPv4 systems;

• techniques to improve the performance and efficiency of IPv6 for key applications such as VoIP;

• mobile IPv6 routing;

• routing limitations in which the cost of a multihomed site is not completely borne by that site, but rather by the network as a whole;

• performance in dual IPv4/IPv6 environments;

• security in dual-stack environments;

• intrusion detection techniques for IPv6, including implications for changes in the use of tunneling and NATs;

• privacy implications of IPv6;

• PKI scalability and trust models; and

• secure Border Gateway Protocol (BGP) implications.

5.2.2 Government as a Consumer

Most commenters stated that government intervention to direct the markets for IPv6 products and services would be unwarranted and potentially harmful. Nevertheless, all respondents indicated that government has an important role to play as a major consumer of IPv6 products and services. From this perspective, federal agencies could play a significant role as early adopters of IPv6. [ 245 ] In fact, some commenters suggested that other federal government agencies should follow the DoD’s lead and consider deploying IPv6. [ 246 ] Most commenters, however, asserted that government agencies should adopt IPv6 only when such adoption meets agency needs. [ 247 ] They also recommended against requiring state and local governments to establish specific IPv6 deployment schedules. [ 248 ] The federal government, however, could encourage its own networks to formulate transition plans and begin implementing IPv6 as soon as practical.

5.2.3 Information Dissemination

The federal government has an important role in disseminating information and providing training support to promote and lower the cost of IPv6 deployment. The government can help to ensure that all stakeholders are aware of the benefits and costs of IPv6 and disseminate information to individual companies to promote the development of cost-effective transition strategies. [ 249 ] Government could engage in awareness campaigns and provide training resources to disseminate information on IPv6

A key component of any company’s transition strategy will be staff training and education. Training and education are likely to be one of the greatest cost components associated with adopting IPv6. Not only will existing staff need to be retrained, but many new graduates will also need additional specific training because universities are not producing sufficient numbers of IPv6-aware network engineers. [ 250 ] Cisco Systems suggests that until the IPv6 “educated base” is expanded, that is, until networking students learn about IPv6 technology, private-sector training costs will be very large. Other commenters agree and suggested that government involvement could offset some of this cost. [ 251 ]

Government could continue, and possibly expand, its collaborations with universities to provide centers of learning for IPv6, which could include seminars, workshops, and training classes to support local businesses. Classes focused on teaching the business community the technical specifics of IPv6 implementation (e.g., transition techniques and required hardware and software upgrades/replacements) and use (e.g., applications and tools) have the potential to lower the cost of and accelerate the deployment of IPv6.

Additionally, the government could increase its participation in groups such as the IETF to help develop “best current practices” to be used in these education programs or merely posted for use by government agencies and U.S. companies. [ 252 ] The government could also create and maintain a library of IPv6 information and resources that interested parties can access. [ 253 ] The NAv6TF further suggests that the government encourage the integration of IPv6 through the creation of a favorable, stable, and government-supported program to avoid the development of fragmented approaches. [ 254 ] In general, many commenters agreed that, by actively supporting training opportunities and promotional activities, government could help lower the cost of IPv6 deployment. [ 255 ]

Previous Section Table of Contents Next Section


[217] Network externalities arise from the fact that the value of a network to its users typically increases with the number of people that can access the network. Similarly, networking effects arise from the fact that the value of a network also increases with the number of individuals actually using the network. When a consumer decides whether to purchase and use a networked product or service (such as an IPv6-capable device), that person considers only the personal benefits of that purchase, and ignores the benefits conferred on all other users (e.g., those users who may now have a new opponent in a IPv6-based gaming service). The individual may choose not to purchase the networked product or service, even though that purchase may have increased overall economic welfare. In consequence, deployment of the service (and the equipment and technologies that make that service possible) will be less than it "should" be. See Michael Parkin, Economics 504-510 (Addison-Wesley 1990); Robert Willig, “The Theory of Network Access Pricing,” in Issues in Public Utility Regulation 109 and n.2 (H. M. Trebbing ed., 1979).

[218] The theoretical and empirical literature concludes that the presence of market failures will tend to cause private-sector firms to underinvest in R&D. For a survey of that literature, see Stephen Martin and John T. Scott., “The Nature of Innovation Market Failure and the Design of Public Support for Private Innovation,” 29 Res. Pol. 437 (Apr. 2000), available at See Gregory Tassey, “Underinvestment in Public Good Technologies,” 30 J. Tech. Transfer 90-94 (2005).

[219] See Tassey, supra note 218, at 105-108.

[220] See Internet2 Comments at 9; Motorola Comments at 9.

[221] See Lockheed Comments at 3; Microsoft Comments at 12-13; Motorola Comments at 8; Qwest Comments at 1.

[222] See Cisco Comments at 25-26.

[223] See NAv6TF Comments at 37-38; Sprint Comments at 14.

[224] See Hain Comments at 20.

[225] See Public Meeting Transcript, supra note 41, at 141-142 (remarks of Rick White, TechNet)

[226] See Hain Comments at 18; Internet2 Comments at 2; Lockheed Comments at 6; Motorola Comments at 2-3.

[227] Once large-scale transition begins, most software would be IPv6 enabled within 24 months through general market forces. See Internet2 Comments at 2.

[228] See Cisco Comments at 25; Microsoft Comments at 9; NAv6TF Comments at 38; Qwest Comments at 2-3.

[229] See Lockheed Comments at 3; NAv6TF Comments at 38.

[230] See Tassey, supra note 161.

[231] This conclusion is based on RTI’s analysis of the RFC comments, the relevant literature, and discussions with industry stakeholders.

[232] Government agencies have a proven history of working with private-sector organizations to provide conformance testing and validation certificates. For example, NIST recently led the selection and testing of the Advanced Encryption Standard (AES) that specifies a cryptographic algorithm for use by U.S. government organizations to protect sensitive (unclassified) information. It is anticipated that the AES will be used widely on a voluntary basis by organizations, institutions, and individuals outside of the U.S. government and outside of the United States. As part of the development process, algorithm testing was conducted under the Cryptographic Module Validation Program (CMVP), run jointly by NIST and the Communications Security Establishment (CSE) of the Government of Canada. Commercial, accredited laboratories also test cryptographic implementations for conformance to NIST's standards, and if the implementations conform, then NIST and CSE issue jointly signed validation certificates for those implementations. See National Institute of Standards and Technology, Report on the Development of the Advanced Encryption Standard (AES) (Oct. 2002), at

[233] See Motorola Comments at 2.

[234] See NAv6TF Comments at 24.

[235] MCI Comments at 6.

[236] In the 1990s, the government decided to initiate the GOSIP, or Government Open Systems Interconnection Profile, which was a mandate to force conformance with an Open Systems Interconnect (OSI) standard. In this instance, the U.S. Government mandated that all government agencies use GOSIP. According to RFC 1169, published by the Internet Architecture Board (IAB), GOSIP was “needed because OSI standards allow many potential options and choices, some of which are incompatible.” V. Cerf and K. Mills, “RFC 1169—Explaining the Role of GOSIP” (Aug. 1990), at Although more than 20 different agencies participated in developing the GOSIP specifications, few OSI applications ever became available; thus, government agencies generally continued to use and expand their use of the Internet Protocol Suite (IPS). In 1995, the Secretary of Commerce removed the mandate on OSI usage by government agencies. According to a bulletin released by NIST in May 1995, the Federal Internetworking Requirement Panel concluded that “federal government agencies should have flexibility to select networking protocol standards based on such factors as interoperability needs, existing infrastructure, costs, the availability of marketplace products, and status of a protocol suite as a standard.” National Institute of Standards and Technology, “Standards For Open Systems: More Flexibility For Federal Users” (1995), at

[237] RTI Telephone Conversation with John Streck, Centaur Labs (Sep. 14, 2004).

[238] See, e.g., BellSouth Comments at 9; Cisco Comments at 29; Microsoft Comments at 12-13.

[239] See Cisco Comments at 26-27; Microsoft Comments at 11.

[240] See, e.g., BellSouth Comments at 9.

[241] Public Meeting Transcript, supra note 41, at 135-137 (remarks of Rick White, TechNet).

[242] See Network Conceptions Comments at 23.

[243] See NAv6TF Comments at 43; Lockheed Comments at 2-3; Microsoft Comments at 12.

[244] See BellSouth Comments at 9; Cisco Comments at 28; Motorola Comments at 9; NAv6TF Comments at 44.

[245] See MCI Comments at 9.

[246] See, e.g., Lockheed Comments at 2; MCI Comments at 8; NAv6TF Comments at 42-43. See also OMB IPv6 Policy Memorandum, supra note 42.

[247] See, e.g., BellSouth Comments at 8; Dillon Comments at 3; Qwest Comments at 5-6.

[248] See, e.g., Lockheed Comments at 4.

[249] See Dillon Comments at 2.

[250] See Hain Comments at 13.

[251] See Cisco Comments at 29; Dillon Comments at 2; NAv6TF Comments at 45-46.

[252] See Cisco Comments at 28.

[253] See Hain Comments at 18.

[254] NAv6TF Comments at 45-46.

[255] See Cisco Comments at 28-29; Dillon Comments at 2; GSA Comments at 11; Internet2 Comments at 10; NAv6TF Comments at 45-46.

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