Exploring the evolution of IPv6: topology, performance, and traffic - Proposal

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.

Sponsored by:
National Science Foundation (NSF)

Principal Investigator: kc claffy

Funding source:  CNS-1111449 Period of performance: May 1, 2012 - April 30, 2016.

1  Motivation: Internet address space exhaustion

The 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) [1] - 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 [2].

Figure 1
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.

Exogenous pressure, namely IPv4 address scarcity, has driven widespread adoption of IPv6 into modern operating systems and network equipment. Major network operators and content providers are deploying IPv6 on both a trial and production basis [5]. Governments are mandating IPv6 [6] and while IPv6 penetration remains small compared to IPv4, it is growing exponentially.

Unfortunately, the ecosystem of software is huge, and many applications and devices still do not support IPv6. Transition technologies such as 6to4 and Teredo [7] are now common, both in consumer end-systems and access gateways, and allows IPv4-only hosts to talk to IPv6 hosts. Conversely NAT64/DNS64 [8,9] will allow IPv6-only hosts to talk to the IPv4 Internet. But while these technologies facilitate IPv6 adoption even by non-technical users, they also introduce extra elements in the network, adding to complexity, and decreasing performance and reliability.

As a stop-gap measure, the RIRs have approved policies that permit IPv4 address holders to transfer allocations to others as if they were property [10]. Although the original allocation architecture [11] denied such property rights as an impediment to aggregation - a property crucial to the scalability of the routing system - this dramatic policy shift is rooted in the now overriding argument that IP addresses as property will release otherwise tied-up space. IP address markets are more politically palatable than reclamation [12], especially to holders of IPv4 space, which includes most people involved in address policy development. But the IP address market scenario will require resolution of who maintains the authoritative database(s) for address ownership, what compels address holders to keep those records current, and what identifying data should be available about address owners. Like reclamation, allowing an IPv4 address market will only buy us time, not solve the fundamental address shortage problem.1 Even advocates of the market solution recognize [14] that it is technologically as well as economically and socially inferior to a solution that provides publicly recognized IP addresses to anyone who needs them, which IPv4 will never do. Therefore, acknowledging IPv6 is not an ideal solution, ICANN and the RIRs still strongly recommend investing in IPv6 immediately, including staff training, management tools, and application support. In November 2010 the Economist reported [15]: Ïf the IT industry keeps dragging its feet on moving to IPv6, the growth of the Internet of things2 will be stymied."

As it pertains to network researchers, architects, and policy makers, there are two possible outcomes from this transition. IPv6 may be widely adopted and embraced, causing many existing methods to measure and monitor the Internet to be ineffective. In this transition scenario, the Internet is even less understood, and data even more scarce, than the existing, poorly instrumented IPv4-based network. A second possibility is that IPv6 languishes, transition mechanisms fail, or performance suffers. Either scenario demands new research toward rigorous large-scale IPv6 measurement to inform technical, business, and policy decisions.

We propose an unprecedented empirical exploration of the most challenging deployment of architectural innovation yet to the current TCP/IP protocol suite, designed explicitly to respond to one of its fundamental limitations rooted in its origins as a U.S. government-sponsored research testbed. Our project fits many of the goals of the NeTS solicitation, most notably in our development of scalable, non-intrusive mechanisms, tools, and methodologies for new and historically significant network measurement and characterization of the most heterogeneous man-made network in history; and using these tools to enable a scientific case study that will inform the discipline of network architecture innovation. The resulting objective, unbiased, scientific knowledge of IPv6 deployment trends in the US and worldwide will not only allow informed policymaking with respect to the IPv6 transition, but also provide a compelling case study on how to effect core architectural innovations to the Internet ecosystem.

2  Current status of IPv6 deployment

IANA 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 [28]. By some accounts, IPv6 development is progressing faster in Asian countries: Japan, South Korea, China [32]. Notably, the 2008 Summer Olympics was the first major world event with a presence on the IPv6 Internet [33].

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 [30] 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 [34].

Given the difficulty of measuring IPv6 directly, Huston and Michaelson [21] 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 [23] on IPv6 metrics such as domains registered with AAAA DNS records (which provide a mapping from hostnames to IPv6 addresses). Mark Prior [25] 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 [36], an objective we hope to help Internet2 achieve as part of our proposed work.

3  CAIDA's IPv6 research contributions

We 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
Figure 2. ARIN's IPv4 address allocation patterns for three decades, in terms of how many allocations a receiving organization has (numbers in legend) [35]. 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
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 [37]. No RIR has come back to IANA with additional IPv6 addressing needs since then.

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

Figure 4
Figure 4: CAIDA 2010 IPv4 and IPv6 AS-core maps. The OECD used an earlier (2008) version in [45].

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.


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. https://www.fcc.gov/news-events/blog/2010/11/12/launching-tac-blog-series.

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.

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

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.

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/archive/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/catalog/datasets/ipv4_routed_24_topology_dataset/.

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

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/projects/as-core/.

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/projects/as-core/2008/ipv6.

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://catalog.caida.org/presentation/2008_arin_survey.

kc claffy and CAIDA, "ARIN and CAIDA IPv6 Survey Summary - October 2008," October 2008. https://catalog.caida.org/presentation/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. https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/routing-information-service-ris.

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.

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.

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/catalog/software/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://catalog.caida.org/paper/2004_dualstack.

M. Luckie and CAIDA, "scamper," 2008. https://www.caida.org/catalog/software/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.


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

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

File translated from TEX by T T H, version 3.72.
On 10 Jun 2011, 14:50.
Last Modified