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

 

Government’s Role
in IPv6
Development and
4 Deployment

 

As discussed in the Section 2, many of the original concerns motivating the development of IPv6, such as limited address space and security, may not be driving forces behind further 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 there is no potential role for government – particularly the federal government -- in influencing the realization of those benefits. The RFC comments and interviews conducted as part of this study suggest that government could take one or more of the following courses:

·         play a major role in coordinating the development of IPv6 standards, protocols, and conformance;

·         be an active participant in identifying and facilitating solution of technology and interoperability issues; and

·         stimulate adoption as a major consumer of IPv6 products and services when in the best interest of 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 major consumer of IPv6 products and services, but it should not mandate adoption by industry or government agencies in the United States. Private sector decisions to purchase IPv6 products and services should be market driven, without influence from federal government mandates.

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. Basic 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 infrastructure technologies (infratechnologies) and supporting services are commonly supported by government research and development (R&D) and technology transfer activities.[1]

Both the level of investment and the timing of investments will affect the potential benefits from IPv6. Sufficient levels of investment are needed to minimize interoperability problems and to realize the positive network externalities generated by IPv6.[2] Because network externalities are difficult for the private sector to appropriate, the public sector frequently supports investment in infratechnologies, such as conformance testing mechanisms and certification protocols.

The timing of investments will affect costs and benefits. 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. Government can affect market evolution through its role as a major consumer of IPv6 products and services. 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.

This section begins with a discussion of “market failure” issues that have the potential to prevent or delay the development and deployment of new technical developments such as IPv6. This discussion is followed by a summary of respondents’ suggested roles for government in supporting IPv6 and a discussion of how they relate to barriers to IPv6 development and deployment.

4.1 Market Failures and Underinvestment in IPv6

Risk and difficulties associated with appropriating returns, capturing economies of scope from investment in disruptive generic technologies, and acquiring the research capabilities to address complex, multidisciplinary research requirements can create potential barriers to innovation and technology adoption and, as a result, may lead to an underinvestment in or underutilization of a technology. 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.[3] Much of the technological market failure literature focuses on underinvestment in innovation or in the creation or production of R&D-based technology. However, these economic arguments are also applicable to the purchase and use of the technology that results from R&D.


Below we discuss several aspects of market failure related to IPv6 technology. We divide the source of market failures into two broad categories:

·         appropriability issues for which social benefits exceed private benefits; and

·         lack of coordination in developing and deploying IPv6 technology.

As apparent in the discussions below, these sources of market failure and their underlying characteristics are not mutually exclusive; rather the underlying economic arguments are related. Most of market failures are linked to the public goods nature of the Internet, which as a large and complex infrastructure is strongly affected by both the development of interoperability solutions and private sector adoption of standards and related infratechnologies.

4.1.1 Social Benefits Exceed Private Benefits

Appropriability issues are at the heart of most market failures and can lead to underinvestment in technology development and deployment from society’s perspective.[4] Underinvestment occurs because conditions exist that prevent firms from fully realizing or appropriating the benefits created by their investments, causing firms to view prospective investments as having expected rates of return below the firm’s minimum acceptable rate of return (hurdle rate).[5] Although firms may recognize that there are spillover benefits to other markets or consumers, they are likely to ignore or heavily discount these benefits. Infratechnology 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.[6]

Spillovers and Appropriability Issues

Many factors affect a firm’s ability to appropriate returns. Knowledge spillovers and ineffective patent protection are commonly cited as limits on a firm’s ability to recoup R&D expenditures. Firms may underinvest if the nature of the technology is such that it is difficult to assign intellectual property rights. Additionally, knowledge and ideas developed by a firm may spill over to other firms during the R&D phase or after the new technology is introduced into the market. For example, an ISP working on research to develop mobile IPv6 products might see low or nonexistent returns because of rapid imitation that limits the probability that the firm can appropriate sufficient returns to cover its R&D investment. Moreover, because the standards associated with mobile IPv6 products must be, by definition, commonly used by competitors and customers, appropriability is virtually non-existent for the infratechnologies supporting standardization.

The presence of appropriability issues does not mean that a market failure will occur, however. For that to happen, the gap between social and private returns must be large enough to suppress private-sector investment. Individual firms are rarely able to capture all the social returns generated by their investments. In addition to spillovers to non-investing firms, well-functioning markets result in some benefits being captured by consumers as “consumer surplus.” Otherwise, consumers would have no incentive to switch to the new technology. Both factors reduce profits for innovating firms. The existence of consumer benefits is part of the normal distribution of social returns and is only considered a market failure if those “market spillovers” are large enough to deter significantly private-sector investment well below socially optimal levels.

The RFC comments demonstrate that there is uncertainty among U.S. ISPs and the software community about whether the private returns from IPv6 deployment and its subsequent market opportunities will justify the costs associated with the transition.[7] However, these concerns 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 corporate discount rates applied to the up-front, and potentially substantial, transition costs.

In apparent contradiction to the foregoing 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.[8] The transition technologies being developed and implemented by the IETF were intended to ensure that initially small negative network externalities would 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 network externalities.[9]

Because of the public goods nature of the research needed to develop and deploy IPv6, some commenters see a continuing need for government support.[10] Appropriability issues are most likely to occur as part of the development of infratechnologies and generic technologies needed to enable IPv6. As a general rule, 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 3 years of IPv6 development and deployment may have significant long-term returns for both private (monetary) and public interest.[11]

Because of the public goods nature of networks, positive externalities generating excess social surplus are created with the establishment of networks. The telephone system is a frequently-cited example of how all participants benefit as a network grows. The central issues are when applications will materialize, and how long it will take to generate a critical mass to yield the network externalities needed for IPv6 to take off. There is no fundamental reason to believe that this will not happen as part of natural market forces. However, as will be investigated in the second phase of this study, it is possible that society could benefit from accelerating the natural market-based adoption process.

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 there is a greater likelihood 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.

Monopoly Power

To the extent that any hardware or software vendor has monopoly power, then that vendor has the potential to exploit its market dominance to increase its private returns at the expense of social welfare. Related to IPv6, this could happen along two dimensions. Along one dimension, the monopolist could create or slow the resolution of the chicken-or-egg dilemma (discussed below) because of its critical position in the supply chain. For example, a monopolist may have a financial incentive to exploit its current technology (i.e., IPv4) for as long as possible. Along a second dimension, the monopolist could attempt to slow the development of standards and protocols because it would be in a position to dictate technical characteristics (i.e., to set and enforce its proprietary protocols).

However, commenters generally denied that monopoly power for IP products or services exists now or will develop in the future. IPv6 is a standard that is available to anyone, and there are enough IPv6-capable products available today to avert a monopoly.[12] Support for IPv6 is widespread in most hardware platforms deployed in service providers’ networks today, and the standards are available and continue to evolve in the public domain.[13] Devices that are IPv6-capable are also being developed to be IPv4-capable as well. Additionally, IPv4 and IPv6 are substitutes; therefore, any company implementing IPv6 would need to compete with both the huge installed base of IPv4 products, new IPv4 products, and other IPv6 products.[14] One respondent pointed out that transition technologies were specifically designed to break the dependence of IPv6 applications and ISP routing services on one another.[15] Therefore, existence of a monopoly seems unlikely.

4.1.2 Lack of Coordination

Coordination failures arise from asymmetries in incentives or information between market participants, either among competitors or along the supply chain. For example, firms acting in their self-interest may invest in standards or technologies that are not optimal for the industry as a whole, or competing implementation procedures developed independently may not interoperate. It has been shown that coordination activities can lower the cost of development and increase the quality of new technologies.[16]

Government’s participation in the market as a major consumer and its mission to promote long-run national objectives positions it well to serve vital coordination roles. As an independent third-party, government can promote a collaborative process that facilitates all parties having the opportunity to be represented. Government can also help coordinate mutually beneficial outcomes, both vertically and horizontally, without concerns about collusion or anticompetitive practices.

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. A well-known example of this phenomenon is the linkage between the adoption of high definition television (HDTV) sets and the availability of high definition 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, a chicken-or-egg dilemma could materialize.

Several commenters said that there is a chicken-or-egg problem associated with IPv6. In their view, 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.[17] Commenters holding this view also suggested that government could act as a source of information to help resolve this chicken-or-egg dilemma. 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.[18]

However, most commenters indicated that no chicken-or-egg problem exists, noting that markets are pushing IPv6 development and deployment in an appropriate time frame. They stated that transition mechanisms were designed specifically to circumvent this problem from a technical perspective and noted ongoing development activities resulting from market demand.[19]

Based on a review of the RFC responses and interviews with stakeholders, it is unlikely that IPv6-related chicken-or-egg issues will affect the development and deployment of IPv6. In general, 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 migration. Because IPv6 and IPv4 are designed to be interoperable during the transition period, moreover, this mitigates any potential chicken-or-egg dilemma.

The chicken-or-egg issue can also be stated in terms of uncertainty over users’ willingness to pay for IPv6-enabled products. Consumer’s 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 pointed out in Section 3, 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.

Segmentation, especially if accompanied by interoperability problems across segments can inhibit the aggregation process. The ITEF 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 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 make the required investments to adopt IPv6 software applications.[20]

Standards, Protocols, and Conformance

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 (a standard by definition 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, there has been, and will continue to be, an important role for government 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. Private returns alone are not likely to provide sufficient motivation to stimulate investments in these areas.[21] 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.[22] For this reason, the public sector has a stake in the IPv6 standards development process, program coordination, technology development, and information dissemination. As noted above, government agencies are in a unique position to promote collaborative processes.

Government could also participate in implementing IPv6 through activities such as conformance testing.[23] 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. Test trials and roadmap processes are critical for IPv6 systems developers and implementers. For example, respondents proposed that the U.S. government could support IPv6 research into interoperability with existing IPv4 systems[24] 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).[25]

4.2 Potential Roles for Government Involvement in IPv6

The general consensus is that market forces should be allowed to drive the 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, “Although 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.”[26]

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.[27] 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.[28] All stakeholders agreed that a mandate for IPv6 is not appropriate at this time.

However, in partial contrast, 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 goods nature of Internet security in general was acknowledged along with concerns regarding the maintenance of security during the transition to IPv6.[29] For example, commenters suggested that both government and the private sector need to work on trust relationships and key management (e.g., PKI development).

Based on responses to the RFC and interviews by RTI with industry stakeholders, potentially helpful government activities that may support the development and deployment of IPv6 fall into three areas:

·         government support for R&D;

·         government as a consumer; and

·         information dissemination.

4.2.1 Government Support for R&D

All respondents suggested the government should support certain types of R&D activities. Several groups that currently perform (or did so in the past) Internet-related testing and/or research were mentioned: NIST, the National Science Foundation (NSF), the Department of Energy (DOE), NASA, and Advanced Research Projects Agency/Defense Advanced Research Projects Agency (ARPA/DARPA). It was stated that organizations such as NIST and NTIA are ideally positioned to help foster and facilitate universities and government collaboration with industry.[30]

To ensure that IPv6-enabled services are deployed in a timely manner, the government could work to ensure that the necessary base of skilled human resources is available, that the research effort is sustained, and that standards and specifications work is accelerated. Suggestions for specific research focus areas include interoperability, security, multihoming, and transition mechanisms, among others. Additionally, the government might support the development of new applications and possibly initiate test beds similar to Moonv6, as appropriate to the needs of its agencies. Government funding for advanced test bed deployment could be made available and advertised appropriately. However, commenters mentioned that such funding should not be used to pick technological winners or losers.[31]

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

·         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.

4.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. However, 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 adaptors of IPv6.[33]

One commenter suggested that the lack of interest in IPv6 from government agencies—other than DoD—is acting as an impediment to the development and deployment of IPv6.[34] Several commenters suggested that all government agencies should adopt the same schedule as the DoD, or something very similar, beginning as soon as possible. However, most commenters suggested government agencies adopt IPv6 only when such adoption meets agency needs. They also recommended against requiring state and local governments to establish specific IPv6 deployment schedules.

On the other hand, the federal government could encourage its own networks to formulate transition plans and begin implementing IPv6 as soon as practical. Where appropriate, intragovernment guidelines could be drafted to require suppliers of IP products and services to provide IPv6-compatible versions by a certain date. GSA could potentially take on the role of government-wide planning for transition to IPv6 by formulating procurement guidelines for all agencies and providing support in the development of their transition strategies and IPv6 implementation goals.[35]

4.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.[36]

Government could engage in awareness campaigns and provide training resources to disseminate information on IPv6. In addition to attending and presenting at networking conferences that large corporations attend, small business users could be targeted through organizations such as the Small Business Association (SBA) or NIST’s Manufacturing Extension Partnership (MEP) program. Many small businesses could potentially realize benefits through IPv6 adoption.[37]

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.[38] Cisco Systems suggests that until the IPv6 “educated base” is expanded, meaning that networking students learn about IPv6 technology, training costs will be very large. Other commenters agree and suggested that government involvement could offset some of this cost.[39]

Government could continue, and possibly expand, its collaborations with universities to provide centers of learning for IPv6. This 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.[40] The government could also create and maintain an information library of IPv6 information and resources that interested parties can access.[41] The NAv6TF goes further, suggesting 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.[42]

In general, many commenters agreed that, by actively supporting and funding training opportunities and promotional activities, government could help lower the cost of IPv6 deployment.[43]

 


 



[1]“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 Tassey, note 179 supra, at 71. See also Tassey, note 173 supra.

[2]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 (1990); Robert Willig, “The Theory of Network Access Pricing” in Issues in Public Utility Regulation 109 and n.2 (H. Trebbing ed. 1979).

[3]The theoretical and empirical literature concludes that the private sector will underinvest in R&D because of market failures. For a recent survey of that literature, see S. Martin and J. Scott., “The Nature of Innovation Market Failure and the Design of Public Support for Private Innovation,” 29 Res. Pol: 437 (2000); S. Martin and J. Scott, “Financing and Leveraging Public/Private Partnerships” (1998) (final report prepared for OECD working group on technology and innovation policy).

[4]Appropriability refers to a firm's ability to collect rents from their
investments in research and development (R&D).  For example, patents are
granted so that inventors can appropriate monopoly returns over a period of
time from their research. Imitation and information spillovers frequently
limit a firm’s ability to appropriate return from investments and can create
disincentives for conducting R&D.

[5]Much of the literature investigating market failures has presented the theories in the context of R&D investment. However, these insights are equally applicable for investments in the adoption and integration of new technologies such as IPv6.

[6]See Tassey, note 173 supra.

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

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

[9]See Cisco Comments at 25-26.

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

[11]See Hain Comments at 20.

[12]See Cisco Comments at 25; Hain Comments at 19; NAv6TF Comments at 39.

[13]See Qwest Comments at 4.

[14]See Cisco Comments at 25.

[15]See id. at 24-25.

[16]Van Huyck, Battalio, and Beil showed that in the absence of communication, strategic uncertainty can lead to coordination failures resulting in suboptimal market equilibrium. J. Van Huyck, R. Battalio, and R. Bell, “Strategic Uncertainty, Equilibrium Selection Principles, and Coordination Failure in Average Option Games,” 106 Q. J. of Econ. 885 (1991); J. Van Huyck, R. Battalio, and R. Bell, “Tacit Coordination Games, Strategic Uncertainty, and Coordination Failure,” 80 Am. Econ. Rev. 234 (1990).

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

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

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

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

[21]This reflects RTI’s judgment based on the RFC comments, the relevant literature, and interviews with industry stakeholders

[22]See Tassey, note 173 supra.

[23]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 Encryption Standard (AES) (Oct. 2002), http://csrc.nist.gov/CryptoToolkit/aes/round2/r2report.pdf.

[24]See Motorola Comments at 2.

[25]See NAv6TF Comments at 24.

[26]MCI Comments at 6.

[27]In the 1990s, the government decided to initiate the GOSIP, or Government Open Systems Interconnection Profile, mandate to force the conformance of 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 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” (1990), www.faqs.org/rfcs/rfc1169.html. Although more than 20 different agencies participated in developing the GOSIP specifications, a 1992 survey of buying plans at several large government agencies revealed that only 20 percent had begun to implement the GOSIP standards, and only Hewlett-Packard Co. and Novell, Inc., had GOSIP-certified products available (InformationWeek, 1992). 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), http://www.itl.nist.gov/lab/bulletns/archives/b595.txt.

[28]Interview with John Streck, Centaur Labs (October 2003).

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

[30]See Network Conceptions Comments at 23.

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

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

[33]See MCI Comments at 9.

[34]See Cisco Comments at 26.

[35]GSA Comments at 11.

[36]See Dillon Comments at 2.

[37]See Network Conceptions Comments at 2.

[38]See Hain Comments at 13.

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

[40]See Cisco Comments at 28.

[41]See Hain Comments at 18.

[42]NAv6TF Comments at 45-46.

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