Figure 1. IANA allocates address blocks from the pool of available addresses to five Regional Internet Registries (RIRs) [3]: RIPE NCC, APNIC, AfriNIC, ARIN, and LACNIC, according to their needs as described by global policy [4]. RIRs later delegate them to local Internet registries or assign them directly to Internet service providers (ISPs), who use them to identify their own and customer equipment. The pool of available addresses will be exhausted in early 2011. The impending crisis has highlighted the need for measurement capabilities to better characterize the state of the Internet's addressing and routing system.

In 2005 ARIN sponsored CAIDA to analyze statistics on IPv4 and IPv6 address allocation [38], with a focus on evaluating demand drivers for address space [35,39]. Figure 2 shows the number of IPv4 prefixes allocated per organization over time, and reveals that allocations tend to go to organizations that already have allocations rather than to new entrants to the field. As of August 2005, old players constituted only between 2% and 11.2% of organizations with address space, but they held more than half of the address space. Figure 3 shows IANA's release of IPv6 space to the registries. The left plot shows a zoomed in subset of IPv6 address allocation until 2006, and indicates that the U.S. region (ARIN) has historically had significantly lower interest in IPv6 than Europe and Asia (RIPE and APNIC, correspondingly). This disparity is consistent with the U.S. holding the majority of the IPv4 space today. In October 2006 IANA implemented a radical policy shift trying to promote IPv6 deployment, giving so much IPv6 address space (a /12) to each RIR to temporarily remove IANA from the equation [37], reflected in the plot on the right of Figure 3. Assuming everyone gives out a /48 (the typical IPv6 prefix allocation size at the time), a /12 gives each RIR an address space to allocate 16 times the size of the entire IPv4 address space. Unsurprisingly, especially in the face of low IPv6 deployment, no RIR has come back to IANA with additional IPv6 addressing needs since then.

3.2  IP topology measurement

CAIDA has been measuring, analyzing, modeling, and visualizing global Internet topology for over a decade. Our newest active measurement infrastructure Archipelago (Ark) [40] currently has 51 monitors deployed in 29 countries (as of November 2010) and conducts ongoing coordinated large-scale traceroute-based topology measurements. Ark-based IPv4 topology measurements began in September 2007. In December 2008, we started measurements of IPv6 topology using six IPv6-capable monitors, now 16 of our monitors are IPv6-capable. We share our topology data with academic and government researchers and CAIDA members, by request [41,42].

A well-known application of our topology data is the AS-core map visualizing global Internet connectivity. Figure 4 exhibits IPv4 and IPv6 AS-core maps produced in August 2010. For the IPv4 map, CAIDA collected data from 45 Ark monitors located in 24 countries on 6 continents that probed paths toward 17 million destinations spread across 9.09M /24 networks covering 96% of the routable prefixes seen in the Route Views (BGP) routing tables [43] on 1 August 2010. For the IPv6 map, CAIDA collected data from 12 Ark monitors located in 6 countries on 3 continents. This subset of monitors probed paths toward 307K destinations spread across 3302 IPv6 prefixes, which represent 99.6% of the globally routed IPv6 prefixes seen in Route Views on 1 August 2010. To produce the final AS-core maps, we convert the IP-based view from each monitor into a topology of Autonomous Systems (ASes), which correspond to Internet Service Providers (ISPs) and other organizations participating in interdomain routing. We plot ASes and their links in polar coordinates with the radius a function of the observed outdegree of an AS, and the angular coordinate corresponding to the geographical location (longitude) of an AS [44].

The 2010 IPv6 AS-core map consists of 715 AS nodes and 1,672 links (inferred peering sessions) between ASes. For comparison, our previous 2008 IPv6 AS-core map [46] included 515 AS nodes and 1,175 AS-links. In neither 2009 nor 2010 are the top degree-ranked ASes the same across IPv4 and IPv6. The IPv4 core is centered primarily in the United States, while the IPv6 core includes Europe. We observed no high-degree "hub" IPv6 ASes in Asia, surprising given the reportedly large IPv6 deployment in Asia. This gap may reflect the geographic bias of our IPv6-capable monitor deployment: five in the US, four in Europe, and only one in Asia.

Though the IPv4 graph is far larger than the IPv6 graph, the two graphs share many structural properties. Although the maximum degree AS in the IPv4 graph is an order of magnitude larger than for the IPv6 graph, the graphs have similar average AS degrees (5.6 and 4.3, respectively) and average shortest AS path distances (3.5 and 3.3, respectively). The two AS graphs have exactly the same radius of 4 and diameter of 8. These similarities reflect the preference of network operators for short AS paths in both IPv4 and IPv6.

3.3  DNS data from "Day in the Life of the Internet" project

We collected and analyzed the largest simultaneous collection of full-payload packet traces from a core component of the global Internet infrastructure ever made available to academic researchers. This dataset consists of four large samples of global DNS traffic collected at participating DNS root servers during annual 'Day in the Life of the Internet' (DITL) experiments conducted in January 2006, January 2007, March 2008, and March 2009 [47]. Native IPv6 traffic is still negligible at root servers who measure it, although at four root servers (C, F, K, and M) we observed a progressive yearly increase since 2007 in AAAA queries, which map a hostname to an IPv6 address, using IPv4 for transport. In 2008 we attributed this increase to more clients using operating systems with native IPv6 capabilities such as Apple's MacOSX and Microsoft's Windows Vista [47], which can launch IPv6 queries (in IPv4 packets) even if IPv6 transport is not available. The increase in 2009 is larger, from around 8% on average to 15%. Some of this increase is due to the addition of IPv6 glue records to six of the root servers in February 2008 [48], and does not necessarily reflect use of IPv6 by applications.

3.4  Survey of RIR members.

In collaboration with ARIN, we conducted two surveys via the RIR membership email lists, inviting subscribers to fill out a web survey. Our first survey in March 2008 was constrained to the ARIN region only - 347 respondents participated. In the second survey conducted in September 2008 we had 1060 survey participants from all five RIRs spanning all geographic regions [49,50]. In early 2009 the European Union decided to re-use our survey [51] to begin to establish some history on IPv6 deployment activity in the European Union; they now do the survey in all five RIR regions and present results at RIPE meetings [52]

Over 70% of survey respondents said their primary motivation for investing resources in IPv6 was "to be ahead of the game." Respondents self-classified as from educational or government organizations were almost twice as likely to have begun their transition toward IPv6 than commercial organizations. Yet, when asked about present hurdles hindering IPv6 deployment, respondents vented their frustration. Obstacles mentioned included registry policies and procedures, lack of quality support for routers, middleboxes and applications, a general lack of IPv6 expertise, and a reluctance to invest resources in the absence of an immediate profitable return - consistent with the fact that less profit-focused or budget-constrained organizations were more likely to report some kind of IPv6 activity. However, and acknowledging the self-selection bias of the survey, nearly half of respondents answered that they do plan to make the transition to IPv6, while about a third said they were going to "wait and see". No one reported carrying significant IPv6 traffic. Perhaps most disturbing and yet least surprising, survey respondents collectively expected to need more IPv4 addresses in the next two years than remain in the unallocated pool.

Two important implications of the scant data available are: (1) architectural transitions, even those deemed not radical but critical, are slow; (2) the U.S. is behind other regions of the world, and has not thus far invested in shedding quantitative light on this problem, despite making attempts to lightly nudge the market toward IPv6 adoption. Given the imminent potential instability post-IPv4-runout, we cannot wait any longer to invest in functionality to assess and inform communications and technology policy with regard to our ability to execute even modest architectural innovations. Our proposed project represents significant progress in this direction.

4  Proposed research

We propose three research tasks that will shed light on the evolution of IPv6 deployment: a rich view of IPv6 topology from the core to edge, using a variety of data sources; an analysis of factors influencing the rate of IPv6 deployment, including socioeconomic and political parameters; and a quantitative assessment of technologies used to support the transition to IPv6.

4.1  Task 1: A view of IPv6 topology: from the core to edge

To provide a sufficiently rich view of IPv6 topology to advance our understanding of its evolution, we will use a variety of independent measurements and data sources. We will execute continuous active probing of all allocated IPv6 address prefixes from at least 15 IPv6-connected vantage points around the globe for the duration of the project, using new techniques outlined in 4.1.1. We will use interdomain routing (BGP) data from the largest global repositories to extract and cross-validate an interdomain AS topology of IPv6 peering structure and dynamics and compare it to what we know about the IPv4 topology. We will also design new tools to undertake opportunistic measurements at the edge to provide additional detail on what types of infrastructure are IPv6-capable. These data sets will also serve as input to our second task when we correlate these observations with other factors influencing IPv6 deployment.

4.1.1  IPv6 topology measurement

Performing rigorous IPv6 topology measurement involves more than simply modifying CAIDA's existing infrastructure and tools to support a new protocol. The fundamental impediment to incrementally revising these approaches is the size of the address space imposed by IPv6. Whereas it was feasible, albeit a multi-day process, to perform a complete mapping of the entire IPv4 space, exhaustively measuring the IPv6 topology is not. Attempting to reuse existing techniques would increase the probing cycle time beyond the point at which temporal dynamics occur. We propose to develop new topology discovery techniques that integrate awareness of IPv6 address allocation considerations [53] to enable our current (CRI-funded) infrastructure [40] (described in Section 3.2) to provide information on structural characteristics and evolution of the IPv6 topology.

Our recent research in high-frequency IPv4 topology measurement [54] will prove especially useful when applied to IPv6 mapping. We developed three primitives, Interface Set Cover (ISC), Subnet Centric Probing (SCP), and Vantage Point Spreading (VPS), that leverage external knowledge (e.g., common subnetting structures) and data from prior cycle(s) to guide the selection of probed destinations and the assignment of destinations to vantage points. Such adaptive and intelligent probing is crucial to the efficiency needed for IPv6-scale topology measurement. Consider that each IPv6 autonomous system advertises fewer prefixes compared to IPv4, since the large IPv6 allocation size permits aggregation, but each prefix is much larger and sparsely populated. Current approaches that use a fixed subnetting boundary, e.g. probing each advertised prefix, or each /24 in IPv4, or each /48 in IPv6, are either too granular, resulting in wasted probing, or too coarse, resulting in missing information. By recursively probing destinations selected to be as distinct as possible in their most significant bits, and then examining an edit distance measure of the resulting paths, SCP is specifically designed to mitigate the granularity problem and maximally expose the internal structure of networks. Complementary to SCP is VPS which ensures maximal spreading of vantage points in order to discover path diversity leading to the destination AS.

Equally important to IPv6 topology measurement efficiency is ISC. ISC generalizes prior work on adaptive probing such as DoubleTree [55] into the well-known minimum set cover problem. ISC is also multi-cycle, running across probing cycles to minimize probing while detecting load balancing and reacting to topological changes. Our initial research has shown that ISC can reduce probing load by nearly 80%, thereby permitting higher-frequency probing which can reveal previously unknown dynamic and temporal properties of IPv6 routes.

These primitives, detailed in [54], will allow us to design and implement innovations to existing measurement architecture to support large-scale IPv6 measurement while also maximizing topological fidelity. Where probing techniques disagree, we will pursue ground truth by talking to ISPs to validate which one is more accurate. We will also automate the updating of our probing target list, which we currently do manually, to enable more progressive, dynamic measurement.

BGP data for IPv6 is a much simpler prospect - we will use the publicly available IPv6 BGP data from the RouteViews [43] and RIPE-RIS [56] repositories, which represent the largest collections of publicly available interdomain routing data from hundreds of ASes around the world. These data sets will enable us to extract and cross-validate AS-level topology information gathered from our active probing measurements.

4.1.2  Extracting, annotating and validating IPv6 topology inferences

We have spent several years developing and testing techniques for deriving an Internet router-level and AS-level graphs from IPv4 traceroute data, including the daunting challenge of router alias resolution. The IPv4 alias resolution techniques we have refined and successfully validated over the last year [57,58], as well as prior and recently developed techniques [59,60,61,62,63,64,65,66,67], largely depend on aspects of IPv4 that do not exist in IPv6, such as record route, IP ID, small subnets, and the IP timestamp option. It might be possible to apply some existing techniques to IPv6, such as graph-based analysis [62], common source address [60,68], and rate limiting [61], but these are the weaker of the available IPv4 techniques. Because of the importance of alias resolution to topology analysis [69], new measurement and inference techniques must be developed for IPv6 to fill this methodological gap. We will also upgrade several of our analysis tools to support annotated topology modeling and statistical analysis: DNS reverse lookups in our hostname database (HostDB); automated creation of AS link files from IP topology data; and inference of AS relationships [70].

The new techniques we develop will allow us to richly analyze the structural properties of IPv4 and IPv6 AS topologies. Our topology analysis software [71] already allows us to compare graph-theoretic metrics such as degree distribution, clustering, betweenness, across inferred IPv4 and IPv6 topologies. Similarly our tools for analyzing and visualizing the core AS topology [44] should allow us to track the evolution of the IPv6 AS core and AS rankings [72] as IPv6 deployment grows.

In previous work, we classified ASes according to their business function (enterprise customers, transit providers and content providers) based on their observed IPv4 AS connectivity, and studied trends in the evolution of the IPv4 AS topology over the last decade [73]. Specifically, we observed linear growth in both ASes and links since 2002, with new network growth predominantly at the edges and densification (new link growth) mostly at the core. Further, we found significant differences in how the connectivity of different AS types evolves over time - enterprise customers have been the most stable, while transit providers and content providers have been peering aggressively in recent times. But we know little about such trends in the IPv6 AS topology. It is not even clear whether the IPv6 ecosystem has the same type of players in similar roles. For example, our AS core maps thus far show that the ASes in the IPv4 core are not at the core of the IPv6 AS topology [44]. Nor do we observe large content providers peering aggressively in the IPv6 AS topology. We hypothesize that IPv4 peering looks different due to the more commercial nature of money flows, while IPv6 peering topology is still weighted by experimental, educational, and less commercial exchange points. We propose to analyze periodic snapshots of the IPv6 AS topology to understand how the structure of the IPv6 topology evolves over time, including the type of players and their IPv6 interactions at the AS/organization level.

4.1.3  IPv6 edge measurement

A completely different but equally important aspect of IPv6 deployment is the rate of adoption at the edge of the network, including support by access ISPs and end hosts. Illuminating properties of the edge is challenging as it is increasingly opaque to active measurement. We propose two complementary approaches that utilize opportunistic measurement [74], i.e. piggy-backing measurement experiments on normal application traffic, in order to better characterize the IPv6 edge.

Our (collaborator RIPE NCC's) initial work in estimating IPv6 deployment used dual-stack enabled web servers with embedded testing javascript [29]. Measurement of IPv4 and IPv6 connections from a single entity, i.e., a web browser on a dual-stack machine, enables a baseline comparison of IPv4 and IPv6, including the prevalence of tunneled transition mechanisms, latency disparity between IPv4 and IPv6 paths, preference for IPv6 when the same resource is available via IPv4, etc. Such statistics can be computed by crafting experiments so that particular resources on a web page are available via IPv4 only, IPv6 only, and IPv4 and IPv6. By carefully removing the effects of caching, for instance by creating per-hit unique hostnames for objects, we can leverage natural hits to web sites we instrument during the normal course of interaction with geographically and provider dispersed clients. An interesting aspect of this measurement approach is its bias towards the self-selected audience of the instrumented web servers. This is both a disadvantage, since it creates a bias, and an advantage since it allows for targeted measurements of diverse client populations. To maximize the use of these measurements, we propose to coordinate execution of these measurements running from web sites in multiple RIR regions and spanning four different sectors: research backbone, university, industry, commercial enterprise, and government.

To further minimize potential sources of bias, and obtain a much larger and representative set of measurements, we will additionally embark on a second source of traffic data and a second methodology for measuring IPv6 adoption. Specifically, we will utilize the large population of infected edge hosts, so-called botnet zombies, to our advantage as a natural source of widely dispersed clients without strong selection bias. In the same way that our opportunistic web server measurements direct clients to request IPv4 and IPv6 resources, we will engineer an experiment with DNS and email servers to capitalize on the large amounts of botnet traffic.

The first component of the experiment is to attract incoming email by advertising newly created email addresses, on previously unused and unoccupied domains. Honeypot research has shown that harvesting spam and attracting incoming traffic in this manner is quite easy [75]. Second, the DNS of the domains we control will contain specially crafted mail exchanger (MX) records that return per-request dynamically generated names that map to short time-to-live IPv6 addresses (AAAA records). All queries and responses to the DNS server will be recorded. Using a front end multiplexer, each address will virtually map to an instrumented mail server under our control. In this fashion, we can leverage attempts by botnets and scam hosting infrastructure to establish an IPv6 connection with resources under our control, and correlate their IPv6 DNS requests with subsequent mail delivery. Because we engineer the responses and thus subsequent transactions to be unique, we can disambiguate requests and mitigate any caching effects that would hamper our measurements. The pervasive and indiscriminate deployment of botnets provide a natural source of representative traffic.

Several subtleties in our proposed approach bear further investigation. First, like the rest of the Internet, most malware is unlikely to support IPv6. But we can determine whether a host is dual-stack by observing DNS queries. Similarly, DNS resolvers do not universally adhere to specified time-to-live constraints, so we take care in designing our experiment and analyzing the results. But by mitigating these obstacles over the course of our research, we will obtain a picture of IPv6 adoption that is orders of magnitude larger than any currently available, while further providing new insights into the use of IPv6 as a mechanism for abusive traffic.

4.2  Task 2: Correlation of deployment data with socioeconomic parameters

Shedding quantitative light on the IPv6 transition requires more than measurement and analysis of observable technical phenomenon, but also understanding many interdisciplinary influences on the most complex system humans have ever created. We propose to correlate the best available IPv6 topology data with other socioeconomic factors influencing IPv6 deployment: address allocation, economic evolution as inferred from topology dynamics, and demographic factors such as geography, organizational structure, and political/regulatory conditions.

4.2.1  Address allocation patterns

We will build tools to automate tracking of IPv6 address usage characteristics, from the time they are allocated by an RIR, through announcement and reachability, until we can reach IPv6-enabled applications on them. While RIR data indicate that IPv6 prefixes are being allocated at near exponential rates, implying a strong growth, their longitudinal BGP analysis reveals that nearly half of these allocated prefixes are never announced, and the remainder take nearly 6 months to appear in the global routing system. In other words, "many people are acting as IPv6 speculators but not deployers." [22] We will analyze publicly available routing data [76] to verify this hypothesis, determine which type of organizations are interested enough to get IPv6 allocations but lagging in deployment [22], and whether such lag correlates with other observable characteristics, e.g., peering degree, organization type. Analysis of this data will also reveal other insights about how IPv4 and IPv6 routing announcement patterns differ. As complete IPv4 exhaustion approaches, we will offer rigorous empirical analysis to inform reclamation possibilities. Our proposed historical BGP analysis will illuminate which IPv4 allocations have been assigned but not used on the public Internet in years.

4.2.2  Economic evolution

Connectivity dynamics of individual ASes also have economic implications. A customer that switches transit providers affects the revenues of the old and new providers. Previous work has revealed that certain types of ASes (particularly content providers) change their preferred providers frequently, often at timescales of 3-9 months [73]. We also found "attractors" and "repellers" in the IPv4 AS topology, i.e., providers that periodically lose and gain customers. Frequent change in the set of preferred providers of an AS is an indicator of the level of competition in the transit market. By studying the changes in connectivity of ASes in different geographical regions, we found that the IPv4 AS ecosystem is currently larger and more dynamic in Europe than in North America. These differences have economic and thus policy implications, since consumer prices for Internet access tend to be a function of healthy competition, which requires some regulation to prevent natural consolidating forces on the topology [77].

We propose to study how the economic evolution of the IPv6 ecosystem, as inferred from topology dynamics, differs from the IPv4 ecosystem. How frequently do customers change their providers in IPv6? How does the competition in the IPv6 transit market compare to that seen in IPv4, and how does this vary by geographical region? Can we see geographical differences in IPv6 topology dynamics, similar to what we observed for IPv4?

4.2.3  Demographics and organizational behavior

We will correlate our deployment data against demographic factors such as geography [78,79], organizational structure (commercial, government, educational) and political/regulatory conditions.

Although most geolocation tools do not yet support IPv6, the freely available MaxMind supports some country resolution of IPv6 addresses [80], which we will use to compare geographic penetration of our IPv6 topology, cross-validating with whois and delegation data from the RIRs. We will test and validate some of our heuristics for IPv4 geolocation to IPv6. For example, we can map the geographic location of an IPv6 block to that of an IPv4 block announced by the same AS if all prefixes originating from that AS map to the same location. We can also use IPv4 geolocation information for IPv6 addresses that share the same (IPv4) hostname. We will validate as well as investigate new heuristics for geolocation by talking with network operators, who will face the same need for operations and management. We will also analyze geographic characteristics of IPv6 traffic to root servers. Several root operators now support regular measurements of traffic to their root servers, which they share with researchers to support operations research and analysis [47]. We will write software to extract IPv4 and IPv6 statistics and compare geographic characteristics of IPv6-capable clients querying root servers, and correlate this data with known policy incentives or cooperative efforts between government and industry to promote IPv6 adoption, e.g., the go6.si initiative in Slovenia [81].

To correlate IPv6 deployment against organizational structure, we will use historical data from Mark Prior's weekly IPv6 deployment survey [25], which quantifies how well major organizations are embracing IPv6. For organizations providing IPv6 transit we will identify the type of customers served, e.g., dial-up, DSL, cable, enterprise, to see where IPv6 uptake is happening faster.

4.3  Task 3: Quantitative assessment of IPv6 performance

Adoption of new technologies and products has been studied extensively in the economics literature [82,83], with recent application to modeling the IPv4 to IPv6 transition [84,85,86,87,88]. A common feature in this body of research is the lack of real-world data to parameterize or validate such models, including data about global IPv6 adoption, user utility from adopting IPv6, and deployment and efficiency of converters which allow IPv4 and IPv6 to exist concurrently. We will improve the state of quantitative modeling of the IPv6 transition by gathering rigorous empirical data on the extent and effectiveness of converter technologies, the prevailing concerns over IPv6 performance and path inflation, and actual IPv6 traffic workloads on a major U.S. backbone.

4.3.1  Converter characteristics

Converters are especially interesting; in the context of the v4 to v6 transition, converters take the form of automatic tunneling protocols, like 6to4 and Teredo, or configured tunneling through tunnel brokers. Converters are used in cases where end-points can not be in both networks at the same time, as is the case with dual-stacked end-points. The aforementioned models show that converters are critical in determining the outcome of the technology transition. The models predict that depending on the efficiency and performance characteristics of such converters, we may reach drastically different outcomes. While more efficient converters generally accelerate the adoption of new network architectures, if converters become too efficient this may slow adoption [85], by removing the incentive to natively adopt the new protocol. We propose to measure the deployment and performance of converter mechanisms, building on several techniques to detect tunnels in the middle of the path [89,90], as well as client tunnels. Some client tunnels such as 6to4 and Teredo use special IPv6 address ranges (2002::/16 and 2001::/32, respectively), simplifying detection of tunnels as well as traffic carried by them. Brokered tunnels can be estimated from various sources including publish lists [91], and reverse engineering web-based measurements [27] such as those described in section 4.1.1. We can use this data to detect performance issues and connection failures of tunneled connections, which preliminary measurements do suggest are significant [92], and which the modeling research above suggest may also in fact be slowing conversion. Expanding the scope of these measurements will not only help parameterize and validate models of IPv6 adoption, but also illuminate a more general understanding of network architectural innovations, and how they succeed or fail.

4.3.2  IPv6 performance myths and realities

There is concern that IPv6 networks are unreliable or do not perform as well as corresponding IPv4 networks, reducing motivation of ISPs and end-users to deploy IPv6 in their networks. We will examine if this is true in two dimensions: first, by using topology information to identify IPv6 paths that differ significantly from their corresponding IPv4 paths [93,94], and second by searching the network for middleboxes that impede IPv6 performance [95,96,97].

To accomplish the first dimension, we will extend tools CAIDA collaborated on with WIDE and WAND [93,94] to compare and track performance to dual-stacked servers (with both IPv4 and IPv6 support), identify and diagnose IPv6 problems, and examine or refute prevailing concerns over the performance of IPv6 network infrastructure. We will identify dual-stacked hosts using DNS queries to find hosts with both an A and AAAA records, as well as extracting AAAA records from passively measured DNS server responses. We will search for IPv6 paths whose end-to-end delay is significantly inflated compared to the IPv4 path between the same hosts, and examine the corresponding AS-level paths to identify possible alternate routes that would likely yield better performance. In 2004, we found cases in which intermediate tunnels introduce detours and consequently larger delays [93]; however, RIPE NCC has shown the prevalence of tunnelled paths in Europe has diminished over time [90], suggesting the problem has diminished. We will collect and analyze macroscopic dual-stack topology data to determine the extent of IPv4 vs. IPv6 path inflation and identify more optimal routes where possible.

To accomplish the second dimension, we will use active measurements to examine the performance of TCP [95] and identify middleboxes that impede TCP. Our collaborator Matthew Luckie has recently begun research in this area. Because Path MTU Discovery is a critical part of IPv6, it is imperative that ICMP traffic is not discarded, because the Packet Too Big (PTB) message is part of ICMP; he found that PTB filtering is much less prevalent than in IPv4 [96]. Likewise, ECN deployment in IPv4 has stalled because of fears that TCP connections cannot be negotiated if ECN capability is signaled, because misconfigured firewalls interpret ECN signaling as port-scanning [95]. Previous data suggests that this is also much less of a concern in IPv6 [97]. We will pursue additional tests into the TCP-level behavior of IPv6; we expect that we will find that there is less middlebox impediment in IPv6 than in IPv4; confirming our hypothesis and if true disseminating such knowledge will help reduce resistance from both application developers and ISPs to enabling and using IPv6.

References

[1]

S. Deering and R. Hinden, "RFC 2460. Internet Protocol, Version 6 (IPv6) Specification," 1998. http://www.ietf.org/rfc/rfc2460.txt.

[2]

G. Huston, "IPv4 Address Report," 2009. http://www.potaroo.net/tools/ipv4/index.html.

[3]

ICANN, "IANA - Internet Assigned Numbers Authority." http://www.iana.org/numbers/.

[4]

ICANN, "Global Addressing Policies," 2009. http://www.icann.org/en/general/global-addressing-policies.html.

[5]

Google, "Google ipv6 implementors conference," 2010. https://sites.google.com/site/ipv6implementors/2010/agenda.

[6]

R. Mohan, "Will U.S. Government Directives Spur IPv6 Adoption?," September 2010. http://www.circleid.com/posts/20100929_will_us_government_directives_spur_ipv6_adoption/.

[7]

Wikipedia, "IPv6 transition mechanisms," November 2010. http://en.wikipedia.org/wiki/IPv6_transition_mechanisms.

[8]

M. Bagnulo and P. Matthews and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers," July 2010. http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12.

[9]

M. Bagnulo and A. Sullivan and P. Matthews and I. van Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers," October 2010. http://tools.ietf.org/html/draft-ietf-behave-dns64-11.

[10]

B. Edelman, Running Out of Numbers: The Impending Scarcity of IP Addresses and What To Do About It. HBS, June 2008. http://www.hbs.edu/research/pdf/09-091.pdf.

[11]

"ARIN Number Resource Policy Manual," 2008. https://www.arin.net/policy/nrpm.html.

[12]

K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg and J. Postel, "RFC 2050. Internet Registry IP Allocation Guidelines," 1996. http://www.ietf.org/rfc/rfc2050.txt.

[13]

Stephan Lagerholm, "The IPv4 Depletion Site." http://www.ipv4depletion.com/.

[14]

O. Maennel, R. Bush, L. Cittadini, and S. M. Bellovin, "A Better Approach than Carrier-Grade-NAT," Tech. Rep. CUCS-041-08, Columbia University, 2008.

[15]

"Sensors and sensibilities: a special report on smart systems," The Economist, November 2010.

[16]

Tom Wheeler, "Launching the TAC Blog Series," Nov. 2010. https://www.fcc.gov/news-events/blog/2010/11/12/launching-tac-blog-series.

[17]

R. Broesma, "DREN IPv6 implementation update," July 2008. http://www.internet2.edu/presentations/jt2008jul/20080722-broersma.pdf.

[18]

J. Baird, "The DoD HPC Modernization Program Helps Make The Transition To IPv6," 2008. http://www.hpcmo.hpc.mil/Htdocs/SUCCESS/pdf/SuccessStory_IPv6_J.pdf.

[19]

H. Ringberg, C. Labovitz, D. McPherson and S. Iekel-Johnson, "A One Year Study of Internet IPv6 Traffic," 2008. http://www.nanog.org/meetings/nanog44/presentations/Tuesday/Ringberg_measurement_N44.pdf.

[20]

L. Colitti, "Global IPv6 Statistics - Measuring the current state of IPv6 for ordinary users," 2008. http://www.ripe.net/ripe/meetings/ripe-57/presentations/Colitti-Global_IPv6_statistics_-_Measuring_the_current_state_of_IPv6_for_ordinary_users_.7gzD.pdf.

[21]

G. Huston and G. Michaelson, "Measuring IPv6 Deployment," 2008. http://www.nro.net/news/cisp-ipv6.pdf.

[22]

E. Karpilovsky, A. Gerber, D. Pei, J. Rexford, and A. Shaikh, "Quantifying the Extent of IPv6 Deployment," in PAM 2009, (Seoul, Korea), Apr 2009. http://www.cs.princeton.edu/~jrex/papers/ipv6-pam09.pdf.

[23]

M. Leber, "Global IPv6 Deployment Progress Report," 2006. http://bgp.he.net/ipv6-progress-report.cgi.

[24]

T. Kuehne, "Examining Actual State of IPv6 Deployment," 2008. http://www.circleid.com/posts/81166_actual_state_ipv6_deployment/.

[25]

M. Prior, "IPv6 survey," 2009. http://www.mrp.net/IPv6_Survey.html.

[26]

M. Abrahamsson, "some real life data," 2008. http://article.gmane.org/gmane.ietf.v6ops/9116.

[27]

E. Aben, "IPv4/IPv6 measurements for: RIPE NCC," November 2010. http://albatross.ripe.net/v6-clientresolver.

[28]

E. Aben, "Interesting Graph - Networks with IPv6 over Time," November 2010. http://labs.ripe.net/Members/emileaben/interesting-graph-networks-with-ipv6-over-time.

[29]

E. Aben, "Measuring IPv6 at Web Clients and Caching Resolvers," Mar. 2010. https://labs.ripe.net/Members/emileaben/.

[30]

Craig Labovitz, "IPv6 Momentum?." http://asert.arbornetworks.com/2010/10/ipv6-momentum/.

[31]

Roch Guerin, "IPv6 Adoption Monitor." http://mnlab-ipv6.seas.upenn.edu/monitor/.

[32]

Ma Yan, "Construction of CNGI-CERNET IPv6 CPN," 2009. http://www.apan.net/meetings/kaohsiung2009/presentations/ipv6/cernet.pdf.

[33]

"Olympic Games 2008," 2008. http://ipv6.beijing2008.cn/en.

[34]

E. Aben, M. Dusi, and kc claffy, "Packet size distribution comparison between Internet links in 1998 and 2008," 2008. https://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.

[35]

B. Huffaker, Y. Hyun, and kc claffy, "IPv4 Address Space Concentration," 2008. https://www.caida.org/archive/id-consumption/ipv4/concentration.

[36]

J. S. Sauver, "IPv6 and The Security of Your Network and Systems," 2009. presented at April 2009 I2 member meeting, https://www.stsauver.com/joe/i2mm-spring2009/i2mm-spring2009.pdf.

[37]

J. Sweeting, "Policy 2004-8: Allocation of ipv6 address space by the internet assigned numbers authority (iana) policy to regional internet registries," 2006. https://www.arin.net/policy/proposals/2004\_8.html.

[38]

kc claffy, "Apocalypse then: IPv4 address space depletion," Oct. 2005. https://www.arin.net/participate/meetings/reports/ARIN_XVI/PDF/wednesday/claffy_ipv4_roundtable.pdf.

[39]

Y. Hyun, "IPv6 Address Space Concentration," 2008. https://www.caida.org/archive/id-consumption/ipv6/.

[40]

Y. Hyun and CAIDA, "Archipelago Measurement Infrastructure," 2009. https://www.caida.org/projects/ark/.

[41]

CAIDA, "The IPv4 Routed /24 Topology Dataset," 2009. https://www.caida.org/catalog/datasets/ipv4_routed_24_topology_dataset/.

[42]

CAIDA, "The IPv6 Topology Dataset," 2009. https://www.caida.org/catalog/datasets/ipv6_allpref_topology_dataset/.

[43]

D. Meyer, "University of Oregon Route Views Project." http://www.routeviews.org/.

[44]

CAIDA, "Visualizing IPv4 and IPv6 Internet Topology at a Macroscopic Scale," 2010. https://www.caida.org/projects/as-core/.

[45]

OECD, "Internet Address Space: Economic Considerations in the Management of IPv4 and in Deployment of IPv6," 2008. http://www.oecd.org/dataoecd/7/1/40605942.pdf.

[46]

CAIDA, "Visualizing IPv6 AS-level Internet Topology 2008," 2008. https://www.caida.org/projects/as-core/2008/ipv6.

[47]

S. Castro, D. Wessels, M. Fomenkov, and k claffy, "A Day at the Root of the Internet," ACM SIGCOMM Computer Communications Review, Oct. 2008.

[48]

IANA, "IPv6 Addresses for the Root Servers," 2008. http://www.iana.org/reports/2008/root-aaaa-announcement.html.

[49]

kc claffy and Bradley Huffaker and Young Hyun, "ARIN and CAIDA IPv6 Survey Summary - April 2008," Apr. 2008. https://catalog.caida.org/presentation/2008_arin_survey.

[50]

kc claffy and CAIDA, "ARIN and CAIDA IPv6 Survey Summary - October 2008," October 2008. https://catalog.caida.org/presentation/2008_arin_survey_summary.

[51]

M. Botterman, "EU IPv6 survey proposed to May 2009 RIPE meeting," 2009. http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/proposed-eu-v6-survey.pdf.

[52]

Maarten Botterman, "2010 IPv6 survey results, presented at RIPE 61." http://ripe61.ripe.net/presentations/117-2010_IPv6_Survey_Results_RIPE_NCC_Rome_v2.pdf.

[53]

T. Chown, "RFC5157. IPv6 Implications for Network Scanning," March 2008. http://tools.ietf.org/html/rfc5157.

[54]

R. Beverly and A. Berger and Geoffrey G. Xie, "Primitives for Active Internet Topology Mapping: Toward High-Frequency Characterization," Proceedings of the ACM SIGCOMM conference on Internet Measurement, November 2010.

[55]

B. Donnet, P. Raoult, T. Friedman, and M. Crovella, "Efficient algorithms for large-scale topology discovery," in Proceedings of the 2005 ACM SIGMETRICS, 2005.

[56]

RIPE, "Routing Information Service (RIS)," 2008. https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/routing-information-service-ris.

[57]

Ken Keys, "Internet-Scale IP Alias Resolution Techniques," ACM SIGCOMM Computer Communication Review (CCR), vol. 40, January 2010. https://catalog.caida.org/paper/2010_alias_resolution.

[58]

Young Hyun and Ken Keys, "Internet-Scale Alias Resolution with MIDAR," in Active Internet Measurement Systems workshop, February 2010. https://catalog.caida.org/presentation/2010_alias_resolution_midar.

[59]

J.-J. Pansiot and D. Grad, "On routes and multicast trees in the Internet," in ACM SIGCOMM, 1998.

[60]

R. Govindan and H. Tangmunarunkit, "Heuristics for Internet map discovery," in INFOCOM, March 2000.

[61]

N. Spring, R. Mahajan, and D. Wetherall, "Measuring ISP topologies with Rocketfuel," in ACM SIGCOMM, 2002.

[62]

N. Spring, M. Dontcheva, M. Rodrig, and D. Wetherall, "How to resolve IP aliases," tech. rep., May 2004.

[63]

M. H. Gunes and K. Sarac, "Analytical IP alias resolution," in IEEE International Conference on Communications (ICC 2006), June 2006.

[64]

M. H. Gunes and K. Sarac, "Resolving IP aliases in building traceroute-based internet maps," tech. rep., December 2006.

[65]

R. Sherwood, A. Bender, and N. Spring, "Discarte: A disjunctive Internet cartographer," in ACM SIGCOMM, 2008.

[66]

A. Bender, R. Sherwood, and N. Spring, "Fixing Ally's growing pains with velocity modelling," in IMC, 2008.

[67]

J. Sherry and E. Katz-Bassett and M. Pimenova and H. Madhyastha and A. Krishnamurthy and T. Anderson, "Resolving IP Aliases with Prespecified Timestamps," Proceedings of the ACM SIGCOMM conference on Internet Measurement, November 2010.

[68]

R. J. Poulin, "Mapping Autonomous System's Router Level Topology in IPv6," Master's thesis, Naval Postgraduate School, June 2007.

[69]

M. H. Gunes and K. Sarac, "Importance of IP alias resolution in sampling internet topologies," in IEEE Global Internet 2007 (GI 2007), May 2007.

[70]

X. Dimitropoulos, D. Krioukov, M. Fomenkov, B. Huffaker, Y. Hyun, kc claffy, and G. Riley, "AS Relationships: Inference and Validation," ACM SIGCOMM Computer Communication Review (CCR), vol. 37, no. 1, 2007.

[71]

Young Hyun, "topostats: topology statistics analysis tool," 2010. https://www.caida.org/catalog/software/topostats.

[72]

CAIDA, "Ranking of Internet Service Providers by Observed Topology," 2005. https://asrank.caida.org/.

[73]

Amogh Dhamdhere and Constantine Dovrolis, "Ten Years in the Evolution of the Internet Ecosystem," Proceedings of the ACM Internet Measurement Conference, Oct. 2008.

[74]

M. Casado, T. Garfinkel, W. Cui, V. Paxson, and S. Savage, "Opportunistic measurement: Extracting insight from spurious traffic," in Proceedings of the ACM HotNets Workshop, Nov. 2005.

[75]

C. A. Shue, J. T. Lubia, M. Gupta, A. S. Yuksel, and C. H. Kong, "Spamology: A study of spam origins," in Sixth Conference on Email and Anti-Spam CEAS, July 2009.

[76]

G. Huston, "IPv6 Allocation Reports." http://bgp.potaroo.net/v6/v6rpt.html.

[77]

S. Shakkottai, M. Fomenkov, D. Krioukov, R. Koga, and kc claffy, "Economic evolution of the Internet AS-level ecosystem," European Physical Journal B, vol. 74, Mar. 2010. arXiv:cs.NI/0608058.

[78]

Pierre Vyncky-Dehousse, "IPv6 Deployment Aggregated Status." http://www.vyncke.org/ipv6status/.

[79]

Maarten Botterman, "IPv6 deployment." http://www.ipv6monitoring.eu/.

[80]

I. Maxmind, "IPv6 GeoLite Country database," 2010. http://geolite.maxmind.com/download/geoip/database/GeoIPv6.dat.gz.

[81]

The go6 Institute, "Pushing the IPv6 internet protocol deployment in Slovenia." http://go6.si/docs/go6_description_eng.pdf.

[82]

J. P. Choi., "The Provision of (Two-way) Converters in the Transition Process to a New Incompatible Technology," Journal of Industrial Economics, vol. 45(2), 1997.

[83]

J. Farrell and G. Saloner, "Converters, Compatibility, and the Control of Interfaces," The Journal of Industrial Economics, vol. 40(1), Mar 1992.

[84]

S. Sen, Y. Jin, R. Guerin, and K. Hosanagar, "Modeling the dynamics of network technology adoption and the role of converters," IEEE/ACM Transactions on Networking, 2011.

[85]

D. Joseph, N. Shetty, J. Chuang, and I. Stoica, "Modeling the Adoption of new Network Architectures," in Proceedings of CoNEXT, 2007.

[86]

Y. Jin, S. Sen, R. Guerin, K. Hosanagar, and Z.-L. Zhang, "Dynamics of Competition Between Incumbent and Emerging Network Technologies," in Proceedings of NetEcon, 2008.

[87]

A. Hovav, R. Patnayakuni, and D. Schuff, "A Model of Internet Standards Adoption: The Case of Ipv6," Information Systems Journal, vol. 14, 2004.

[88]

R. Guerin and K. Hosanagar, "Fostering IPv6 migration through network quality differentials," SIGCOMM Comput. Commun. Rev, vol. 40, June 2010.

[89]

C. Systems, "Detecting IPv6 Tunnels in an Enterprise Network," 2010. http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_paper_c11-629391.html.

[90]

Franz Schwarzinger, "Untunneling IPv6," Nov. 2009. http://labs.ripe.net/content/untunneling-ipv6.

[91]

"List of prefixes for IPv6 tunnels providied by SiXXS." http://www.sixxs.net/pops/prefixes/?txtonly.

[92]

E. Aben, "How bad is it, really," Nov. 2010. https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really.

[93]

K. Cho, M. Luckie, and B. Huffaker, "Identifying IPv6 Network Problems in the Dual-Stack World," SIGCOMM 2004 NetTS (Network Troubleshooting) workshop, September 2004. https://catalog.caida.org/paper/2004_dualstack.

[94]

M. Luckie and CAIDA, "scamper," 2008. https://www.caida.org/catalog/software/scamper/.

[95]

A. Medina, M. Allman, and S. Floyd, "Measuring interactions between transport protocols and middleboxes," in IMC '04, Oct. 2004.

[96]

Matthew Luckie and Ben Stasiewicz, "Measuring Path MTU Discovery Behaviour," Proceedings of the ACM SIGCOMM conference on Internet Measurement, November 2010.

[97]

S. Eichler and M. Luckie, "ECN uptake evaluation (ipv6-techsig mailing list)," October 2009. http://listserver.internetnz.net.nz/pipermail/ipv6-techsig/2009-October/000742.html.

---

Footnotes:

¹ IANA allocates more than one /8 per month [13].

² http://en.wikipedia.org/wiki/Internet_of_Things

---

File translated from T_{EX by T T H, version 3.72.
On 10 Jun 2011, 14:50.}