[This blog entry is guest written by Robert Beverly at the Naval Postgraduate School.]

In many respects, the deployment, adoption, use, and performance of IPv6 has received more recent attention than IPv4. Certainly the longitudinal measurement of IPv6, from its infancy to the exhaustion of ICANN v4 space to native 1% penetration (as observed by Google), is more complete than IPv4. Indeed, there are many vested parties in (either the success or failure) of IPv6, and numerous IPv6 measurement efforts afoot.

Researchers from Akamai, CAIDA, ICSI, NPS, and MIT met in early January, 2013 to firstly share and make sense of current measurement initiatives, while secondly plotting a path forward for the community in measuring IPv6. A specific objective of the meeting was to understand which aspects of IPv6 measurement are “done” (in the sense that there exists a sound methodology, even if measurement should continue), and which IPv6 questions/measurements remain open research problems. The meeting agenda and presentation slides are archived online.

To this end, it’s important to note that one of the central observations of claffy’s CCR editorial from July 2011 is that the eventual fate of IPv6 remains undecided. Similarly, whether there will be a “forcing function” that leads to non-trivial IPv6 deployment is still unclear.

Thomas Blood of NPS’s central IT organization spoke to this point with respect to DoD IPv6 compliance mandates where all internal DoD networks should be IPv6 compliant by 2014. The deadline for universal DoD v6 compliance has passed a remarkable four times already, with only 1% of organizations meeting the mandate as of June 2012. Despite pressure to adopt IPv6 within the US government, funding and security issues trump most efforts to deploy IPv6. Without any demand from users, there is little incentive to deploy IPv6 — especially given IT personnel effort in supporting and securing v6. There is not only a large amount of legacy equipment that cannot support IPv6, but also a wide range of products on the market today that do not properly support IPv6. Indeed, DREN has performed extensive vendor IPv6 testing, with mixed results, for example, discovering essential devices that do not support IPv6 ACLs, or those that do so with unacceptably low performance.

It is important for existing measurement efforts and methodologies to continue to collect data during this potential evolution — to understand the adoption of IPv6, or to better understand why IPv6 fails if its adoption languishes. Several components of the “data we need” have largely been addressed in the last year. For instance, while methodologies to assess IPv6 adoption are now well-understood, continued data collection is important. On the client-side, recent work from Zander et al. at IMC 2012 showed a clever way to leverage Google’s vast visibility of the edge to obtain a large and diverse sample of client IPv6 capability by embedding measurements into flash advertisements. Google and Akamai both publish IPv6 adoption data based on observing client behavior. Google now publishes non-whitelisted AAAA DNS records for its domains, and supports IPv6 end-to-end. On the server-side, significant insight can be gleaned from the DNS. For example, ICSI, in collaboration with the University of Michigan, is analyzing zone and query data from some of the TLD authorities to understand the penetration of infrastructure IPv6. While Claffy’s 2011 editorial noted that estimates of IPv6 penetration vary by orders of magnitude, these measurements are slowly converging to a more reliable estimate.

Performance comparisons between IPv4 and IPv6 have also received significant attention, including CAIDA’s IMC 2012 paper and Akamai’s measurements. Several independent sources have shown that, when paths are congruent at the AS-level, performance is largely the same — i.e. there is no data-plane performance penalty today to using IPv6. It will be important to continue performance measurements as more applications implement happy eyeballs.

Workshop participants also identified areas where additional research is needed: a) measuring the extent of carrier grade NAT in the Internet; b) understanding IPv6 topology; c) characterizing IPv6 security issues; d) incorporating economic models.

Given IPv4 address exhaustion and economic incentives against adopting IPv6, providers may choose to deploy carrier grade NAT rather than (or in addition to) investing in IPv6. Little data exists today to understand the extent and use of carrier grade NAT. Arthur Berger and Nick Weaver exchanged several ideas for finding carrier grade NATs during the meeting and Nick hopes to place new functionality into Netalyzer to more broadly study their deployment.

With respect to economics, Steven Bauer presented a thought-provoking assessment of the (lack of) time-series IPv6 data in residential broadband performance studies (e.g., Samknows, Bismark, etc). In particular, when evaluating speed measurements and overall user experience, how should one weight IPv4 versus IPv6? Further, recent work that has evaluated the graph-theoretic centrality of AS interconnection in an effort to quantify market power (e.g. with respect to recent de-peering arguments, etc), have not examined IPv6 peering — suggesting avenues of exploration that may be valuable in understanding IPv6.

Topology is a second area where slow but steady progress is being made — yet much more remains to be done. Researchers from NPS and CAIDA are collaborating on efforts to perform IPv6 alias resolution to reduce interface-level topologies (i.e. as collected by traceroute) to the more useful router-level topologies. Their most recent work will appear at PAM 2013; they are continuing the collaboration with a focus on scaling to Internet-size topologies, i.e., large-scale IPv6 alias resolution. Further, researchers from NPS, Akamai, and ICSI are collaborating on efforts to infer “sibling” relationships between IPv4 and IPv6 addresses, with the eventual goal of enabling comparative topology mapping, sound performance comparisons, and informing reputation and geolocation engines.

Lastly, there was consensus among participants that security is one of IPv6’s Achilles’ heels. At the meeting, Chris Eagle, one of the organizers for previous Defcon CTF exercises, spoke about their recent use of IPv6 in the challenge, which pretty much stumped all the security experts participating in the contest. IPv6 as deployed today is largely unsecured with respect to known vulnerabilities in IPv4, while introducing a raft of new attack vectors. As a result, NPS is undertaking an effort to better support IPv6 in the spoofer project, as well as continuing to use IPv6 attack traffic for opportunistic measurement insight.

Much exciting work is in progress!

This entry was posted on Tuesday, January 22nd, 2013 at 5:55 pm and is filed under Commentaries, Economics, Future, IPv6, Measurement, Topology, Updates. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.