An abbreviated version of the original proposal is shown below. For the full proposal for "NeTS-IPv6: Exploring the evolution of IPv6: topology, performance, and traffic", please see the NeTS-IPv6 proposal in PDF.
Contents1 Motivation: Internet address space exhaustion
2 Current status of IPv6 deployment
3 CAIDA's IPv6 research contributions
3.1 Address allocation
3.2 IP topology measurement
3.3 DNS data from "Day in the Life of the Internet" project
3.4 Survey of RIR members.
4 Proposed research
4.1 Task 1: A view of IPv6 topology: from the core to edge
4.1.1 IPv6 topology measurement
4.1.2 Extracting, annotating and validating IPv6 topology inferences
4.1.3 IPv6 edge measurement
4.2 Task 2: Correlation of deployment data with socioeconomic parameters
4.2.1 Address allocation patterns
4.2.2 Economic evolution
4.2.3 Demographics and organizational behavior
4.3 Task 3: Quantitative assessment of IPv6 performance
4.3.1 Converter characteristics
4.3.2 IPv6 performance myths and realities
1 Motivation: Internet address space exhaustionThe Internet operations, engineering and research communities are putting significant attention into a relatively new version (actually 15 years old) of the Internet Protocol - IP version 6 (IPv6)  - which was designed to solve several architectural limitations of the existing IPv4 protocol. The most indisputably essential characteristic of IPv6 is that it was designed to provide orders of magnitude more address space than the world's foreseeable IP connectivity needs (2128 or about 37 orders of magnitude more addresses than in IPv4). IPv6 has become especially pertinent in the last two years because the global Internet address allocation architecture (IANA and the Regional Internet Address Registry (RIR) system, depicted in Figure 1) relies on the presence of a pool of unencumbered IP addresses to allocate to sites operating Internet infrastructure, and this pool will be empty in less than six months .
Figure 1. IANA allocates address blocks from the pool of available addresses to five Regional Internet Registries (RIRs) : RIPE NCC, APNIC, AfriNIC, ARIN, and LACNIC, according to their needs as described by global policy . 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.
2 Current status of IPv6 deploymentIANA allocated the first IPv6 address in 1999. Today, estimates of IPv6 penetration span at least three orders of magnitude across different sources, which is arguably consistent with the wide range of interest (or lack of interest) in this new protocol. The U.S. federal government is again requiring IPv6 deployment within .gov networks [6,16]. Although most agencies have thus far only done the bare minimum in response to such regulations, it is still a sign that the U.S. is willing to regulate into existence a critical information technology [17,18]. Yet the economic crisis has further lowered the chance that any ISPs will voluntarily invest capital in creating and operating the parallel networks that will be required while the world transitions to IPv6. Many attempts have been made to evaluate the status of IPv6 adoption and penetration [19,20,21,22,23,24,25,26,27,28,29,30,31]. None have found significant activity, even though IPv6 has been implemented on all major network and host operating systems. Current levels of observable IPv6 activity are well below 1% [30,27,31], although up to 7% of global Autonomous Systems announce at least one IPv6 prefix . By some accounts, IPv6 development is progressing faster in Asian countries: Japan, South Korea, China . Notably, the 2008 Summer Olympics was the first major world event with a presence on the IPv6 Internet . Traffic data is the most accurate way to measure actual IPv6 usage, but also has the most difficult policy obstacles to access, and does not reveal preparatory activity. Arbor Networks  reported that observable IPv6 (6to4) traffic remained less than one twentieth of one percent ( < 0.05%) of traffic they observed at their sensors in October 2010, though they point out this is two orders of magnitude larger than in 2008, and is admittedly a lower bound on IPv6 traffic due to observation capability limitations. CAIDA measurements of an OC-192 commercial backbone link in April 2010 showed a similarly low IPv6 traffic level of 0.005% of packets . Given the difficulty of measuring IPv6 directly, Huston and Michaelson  studied a range of types of data collected over four years (January 2004 to April 2008) that might reflect IPv6 activity. They analyzed inter-domain routing announcement data, access logs from www.apnic.net, and data captured from queries of reverse DNS zones that map IPv4 and IPv6 addresses back to domain names. All of their metrics show some increase in IPv6 deployment activity starting in the second half of 2006, but they emphasize that their metrics are limited in scientific integrity; most only measure some interest in IPv6 rather than usable IPv6 support. Hurricane Electric maintains daily statistics  on IPv6 metrics such as domains registered with AAAA DNS records (which provide a mapping from hostnames to IPv6 addresses). Mark Prior  posts weekly results of testing IPv6 reachability to web, email, DNS, NTP, and jabber ports for Internet2 sites and partners. None of these sites show aggregated long term trends. Not only do we lack a comprehensive picture of IPv6 deployment, but we do not even have consensus on the definition of IPv6 usage, much less growth. Even more challenging to policymakers, researchers, and operators are the tremendous counter-incentives to sharing data to establish empirically grounded consensus, including the time and money it takes to obtain measurements. Internet2 is an eye-opening example - it operates the U.S. national research and education backbone, which supports IPv6, but their routers cannot yet gather IPv6 flow statistics, so we cannot even study IPv6 usage on our own national research backbone , an objective we hope to help Internet2 achieve as part of our proposed work.
3 CAIDA's IPv6 research contributionsWe review four analyses we have undertaken to improve our understanding of IPv6 deployment based on independent data sources: address allocation, active topology probing, DNS traffic to root servers, and a web survey of address holders. Our three proposed research tasks in Section 4 build on the insights gained from this prior work and relevant experience.
3.1 Address allocation
Figure 2. ARIN's IPv4 address allocation patterns for three decades, in terms of how many allocations a receiving organization has (numbers in legend) . The figure reveals that expansion of existing networks, rather than emergence of new networks, drives demand for IPv4 space, and that the IPv4 address space will soon be depleted in this manner.
Figure 3: IANA allocation of IPv6 address prefixes to the five regional Internet registries (RIRs) over time. The left plot shows a subset of the right hand plot - address allocation until 2006. In September 2006 IANA implemented a new policy to give sufficient IPv6 address to each RIR to support their needs for at least 18 months . No RIR has come back to IANA with additional IPv6 addressing needs since then.
3.2 IP topology measurementCAIDA has been measuring, analyzing, modeling, and visualizing global Internet topology for over a decade. Our newest active measurement infrastructure Archipelago (Ark)  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  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 .
Figure 4: CAIDA 2010 IPv4 and IPv6 AS-core maps. The OECD used an earlier (2008) version in .
3.3 DNS data from "Day in the Life of the Internet" projectWe 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 . 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 , 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 , 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  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  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 researchWe 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 edgeTo 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 measurementPerforming 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  to enable our current (CRI-funded) infrastructure  (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  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  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 , 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  and RIPE-RIS  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 inferencesWe 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 , common source address [60,68], and rate limiting , but these are the weaker of the available IPv4 techniques. Because of the importance of alias resolution to topology analysis , 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 . The new techniques we develop will allow us to richly analyze the structural properties of IPv4 and IPv6 AS topologies. Our topology analysis software  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  should allow us to track the evolution of the IPv6 AS core and AS rankings  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 . 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 . 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.2 Task 2: Correlation of deployment data with socioeconomic parametersShedding 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 patternsWe 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."  We will analyze publicly available routing data  to verify this hypothesis, determine which type of organizations are interested enough to get IPv6 allocations but lagging in deployment , 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 evolutionConnectivity 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 . 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 . 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 behaviorWe 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 , 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 . 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 . To correlate IPv6 deployment against organizational structure, we will use historical data from Mark Prior's weekly IPv6 deployment survey , 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 performanceAdoption 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 characteristicsConverters 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 , 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 , and reverse engineering web-based measurements  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 , 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 realitiesThere 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 ; however, RIPE NCC has shown the prevalence of tunnelled paths in Europe has diminished over time , 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  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 . 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 . Previous data suggests that this is also much less of a concern in IPv6 . 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.
- S. Deering and R. Hinden, "RFC 2460. Internet Protocol, Version 6 (IPv6) Specification," 1998. http://www.ietf.org/rfc/rfc2460.txt.
- G. Huston, "IPv4 Address Report," 2009. http://www.potaroo.net/tools/ipv4/index.html.
- ICANN, "IANA - Internet Assigned Numbers Authority." http://www.iana.org/numbers/.
- ICANN, "Global Addressing Policies," 2009. http://www.icann.org/en/general/global-addressing-policies.html.
- Google, "Google ipv6 implementors conference," 2010. https://sites.google.com/site/ipv6implementors/2010/agenda.
- 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/.
- Wikipedia, "IPv6 transition mechanisms," November 2010. http://en.wikipedia.org/wiki/IPv6_transition_mechanisms.
- 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.
- 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.
- 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.
- "ARIN Number Resource Policy Manual," 2008. https://www.arin.net/policy/nrpm.html.
- 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.
- Stephan Lagerholm, "The IPv4 Depletion Site." http://www.ipv4depletion.com/.
- 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.
- "Sensors and sensibilities: a special report on smart systems," The Economist, November 2010.
- Tom Wheeler, "Launching the TAC Blog Series," Nov. 2010. http://reboot.fcc.gov/blog?categoryId=979363.
- R. Broesma, "DREN IPv6 implementation update," July 2008. http://www.internet2.edu/presentations/jt2008jul/20080722-broersma.pdf.
- 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.
- 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.
- 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.
- G. Huston and G. Michaelson, "Measuring IPv6 Deployment," 2008. http://www.nro.net/news/cisp-ipv6.pdf.
- 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.
- M. Leber, "Global IPv6 Deployment Progress Report," 2006. http://bgp.he.net/ipv6-progress-report.cgi.
- T. Kuehne, "Examining Actual State of IPv6 Deployment," 2008. http://www.circleid.com/posts/81166_actual_state_ipv6_deployment/.
- M. Prior, "IPv6 survey," 2009. http://www.mrp.net/IPv6_Survey.html.
- M. Abrahamsson, "some real life data," 2008. http://article.gmane.org/gmane.ietf.v6ops/9116.
- E. Aben, "IPv4/IPv6 measurements for: RIPE NCC," November 2010. http://albatross.ripe.net/v6-clientresolver.
- E. Aben, "Interesting Graph - Networks with IPv6 over Time," November 2010. http://labs.ripe.net/Members/emileaben/interesting-graph-networks-with-ipv6-over-time.
- E. Aben, "Measuring IPv6 at Web Clients and Caching Resolvers," Mar. 2010. https://labs.ripe.net/Members/emileaben/.
- Craig Labovitz, "IPv6 Momentum?." http://asert.arbornetworks.com/2010/10/ipv6-momentum/.
- Roch Guerin, "IPv6 Adoption Monitor." http://mnlab-ipv6.seas.upenn.edu/monitor/.
- Ma Yan, "Construction of CNGI-CERNET IPv6 CPN," 2009. http://www.apan.net/meetings/kaohsiung2009/presentations/ipv6/cernet.pdf.
- "Olympic Games 2008," 2008. http://ipv6.beijing2008.cn/en.
- 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.xml.
- B. Huffaker, Y. Hyun, and kc claffy, "IPv4 Address Space Concentration," 2008. https://www.caida.org/research/id-consumption/ipv4/concentration.xml.
- J. S. Sauver, "IPv6 and The Security of Your Network and Systems," 2009. presented at April 2009 I2 member meeting, http://www.uoregon.edu/~joe/i2mm-spring2009/.
- 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.
- 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.
- Y. Hyun, "IPv6 Address Space Concentration," 2008. https://www.caida.org/research/id-consumption/ipv6/.
- Y. Hyun and CAIDA, "Archipelago Measurement Infrastructure," 2009. https://www.caida.org/projects/ark/.
- CAIDA, "The IPv4 Routed /24 Topology Dataset," 2009. https://www.caida.org/data/active/ipv4_routed_24_topology_dataset.xml.
- CAIDA, "The IPv6 Topology Dataset," 2009. https://www.caida.org/data/active/ipv6_allpref_topology_dataset.xml.
- D. Meyer, "University of Oregon Route Views Project." http://www.routeviews.org/.
- CAIDA, "Visualizing IPv4 and IPv6 Internet Topology at a Macroscopic Scale," 2010. https://www.caida.org/research/topology/as_core_network/.
- 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.
- CAIDA, "Visualizing IPv6 AS-level Internet Topology 2008," 2008. https://www.caida.org/research/topology/as_core_network/ipv6.xml.
- S. Castro, D. Wessels, M. Fomenkov, and k claffy, "A Day at the Root of the Internet," ACM SIGCOMM Computer Communications Review, Oct. 2008.
- IANA, "IPv6 Addresses for the Root Servers," 2008. http://www.iana.org/reports/2008/root-aaaa-announcement.html.
- kc claffy and Bradley Huffaker and Young Hyun, "ARIN and CAIDA IPv6 Survey Summary - April 2008," Apr. 2008. https://www.caida.org/publications/presentations/2008/arin_survey/.
- kc claffy and CAIDA, "ARIN and CAIDA IPv6 Survey Summary - October 2008," October 2008. https://www.caida.org/publications/presentations/2008/arin_survey_summary/.
- 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.
- 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.
- T. Chown, "RFC5157. IPv6 Implications for Network Scanning," March 2008. http://tools.ietf.org/html/rfc5157.
- 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.
- B. Donnet, P. Raoult, T. Friedman, and M. Crovella, "Efficient algorithms for large-scale topology discovery," in Proceedings of the 2005 ACM SIGMETRICS, 2005.
- RIPE, "Routing Information Service (RIS)," 2008. http://www.ripe.net/ris/.
- Ken Keys, "Internet-Scale IP Alias Resolution Techniques," ACM SIGCOMM Computer Communication Review (CCR), vol. 40, January 2010. https://www.caida.org/publications/papers/2010/alias_resolution/.
- Young Hyun and Ken Keys, "Internet-Scale Alias Resolution with MIDAR," in Active Internet Measurement Systems workshop, February 2010. https://www.caida.org/publications/presentations/2010/alias_resolution_midar/.
- J.-J. Pansiot and D. Grad, "On routes and multicast trees in the Internet," in ACM SIGCOMM, 1998.
- R. Govindan and H. Tangmunarunkit, "Heuristics for Internet map discovery," in INFOCOM, March 2000.
- N. Spring, R. Mahajan, and D. Wetherall, "Measuring ISP topologies with Rocketfuel," in ACM SIGCOMM, 2002.
- N. Spring, M. Dontcheva, M. Rodrig, and D. Wetherall, "How to resolve IP aliases," tech. rep., May 2004.
- M. H. Gunes and K. Sarac, "Analytical IP alias resolution," in IEEE International Conference on Communications (ICC 2006), June 2006.
- M. H. Gunes and K. Sarac, "Resolving IP aliases in building traceroute-based internet maps," tech. rep., December 2006.
- R. Sherwood, A. Bender, and N. Spring, "Discarte: A disjunctive Internet cartographer," in ACM SIGCOMM, 2008.
- A. Bender, R. Sherwood, and N. Spring, "Fixing Ally's growing pains with velocity modelling," in IMC, 2008.
- 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.
- R. J. Poulin, "Mapping Autonomous System's Router Level Topology in IPv6," Master's thesis, Naval Postgraduate School, June 2007.
- M. H. Gunes and K. Sarac, "Importance of IP alias resolution in sampling internet topologies," in IEEE Global Internet 2007 (GI 2007), May 2007.
- 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.
- Young Hyun, "topostats: topology statistics analysis tool," 2010. https://www.caida.org/tools/utilities/topostats.
- CAIDA, "Ranking of Internet Service Providers by Observed Topology," 2005. https://asrank.caida.org/.
- Amogh Dhamdhere and Constantine Dovrolis, "Ten Years in the Evolution of the Internet Ecosystem," Proceedings of the ACM Internet Measurement Conference, Oct. 2008.
- 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.
- 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.
- G. Huston, "IPv6 Allocation Reports." http://bgp.potaroo.net/v6/v6rpt.html.
- 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.
- Pierre Vyncky-Dehousse, "IPv6 Deployment Aggregated Status." http://www.vyncke.org/ipv6status/.
- Maarten Botterman, "IPv6 deployment." http://www.ipv6monitoring.eu/.
- I. Maxmind, "IPv6 GeoLite Country database," 2010. http://geolite.maxmind.com/download/geoip/database/GeoIPv6.dat.gz.
- The go6 Institute, "Pushing the IPv6 internet protocol deployment in Slovenia." http://go6.si/docs/go6_description_eng.pdf.
- 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.
- J. Farrell and G. Saloner, "Converters, Compatibility, and the Control of Interfaces," The Journal of Industrial Economics, vol. 40(1), Mar 1992.
- 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.
- D. Joseph, N. Shetty, J. Chuang, and I. Stoica, "Modeling the Adoption of new Network Architectures," in Proceedings of CoNEXT, 2007.
- 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.
- A. Hovav, R. Patnayakuni, and D. Schuff, "A Model of Internet Standards Adoption: The Case of Ipv6," Information Systems Journal, vol. 14, 2004.
- R. Guerin and K. Hosanagar, "Fostering IPv6 migration through network quality differentials," SIGCOMM Comput. Commun. Rev, vol. 40, June 2010.
- 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.
- Franz Schwarzinger, "Untunneling IPv6," Nov. 2009. http://labs.ripe.net/content/untunneling-ipv6.
- "List of prefixes for IPv6 tunnels providied by SiXXS." http://www.sixxs.net/pops/prefixes/?txtonly.
- E. Aben, "How bad is it, really," Nov. 2010. https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really.
- 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://www.caida.org/publications/papers/2004/dualstack/.
- M. Luckie and CAIDA, "scamper," 2008. https://www.caida.org/tools/measurement/scamper/.
- A. Medina, M. Allman, and S. Floyd, "Measuring interactions between transport protocols and middleboxes," in IMC '04, Oct. 2004.
- Matthew Luckie and Ben Stasiewicz, "Measuring Path MTU Discovery Behaviour," Proceedings of the ACM SIGCOMM conference on Internet Measurement, November 2010.
- 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:1 IANA allocates more than one /8 per month . 2http://en.wikipedia.org/wiki/Internet_of_Things
File translated from TEX by TTH, version 3.72.
On 10 Jun 2011, 14:50.