Macroscopic IPv6 Topology Measurements

To augment our IPv4 topology analysis project, CAIDA is collaborating with the Waikato Applied Network Dynamics (WAND) research group of the University of Waikato, New Zealand, to gather and analyze macroscopic IPv6 topology data.

Goals of the project

As of June 2003, CAIDA is starting to collect IPv6 topology data. Our goals include:

  • characterize the macroscopic topology of the IPv6 active address space
  • study performance of IPv6 connectivity
  • visualise propagation of IPv6 connectivity
  • make topology data available to the community for use in modeling, simulation, and analysis

Data collection

We will use two sources of data for IPv6 topology studies: active measurements of IPv6 path information and inter-domain BGP routing tables.

To capture global IPv6 layer-3 connectivity data, Matthew Luckie is leading the implementation of a new tool, scamper. scamper sends probe packets from source monitors to a specified list of IPv6 addresses and records forward IP paths and round trip times (RTTs) to intermediate nodes and to the final destination. This tool uses a methodology similar to CAIDA's existing IPv4 monitoring tool, skitter. However, skitter has a lot of supporting code to allow for continuous scanning and archiving of the data back at CAIDA. The current prototype version of scamper is just a one-shot execution of a destination list.

The RouteViews project began collecting IPv6 routing tables in May of 2003. This project gathers BGP IPv4 routing perspectives from more than 60 major ISPs worldwide, but only two peers contribute IPv6 information. As of 2003, the IPv6 combined table typically has nearly 612 globally routable prefixes, which originate from 324 different ASes.

Destination list

One of the challenging tasks of this project is to derive a destination list that will provide a reasonable coverage of IPv6 address space. Composing a representative list is much harder when such a vast address space is available. For example, even though only a fraction of the available address space under 2001::/16 and 3ffe::/16 has been allocated at /32 and /35 boundaries, the remaining 96 bits can be split up and delegated by the prefix holder in random ways.

We composed an initial list from a number of sources. The resulting IPv6 destination list contains 4235 addresses.

SourceMethodNumber of addresses
6bone.db file application and tunnel addresses 867
Google SOAP API search for IPv6 IPv6 WWW servers found in the first 1000 results 123
test scamper runs * intermediate nodes 480 DNS walk 144 DNS servers,
2445 named IPv6 addresses RIPE TTM monitors 11
generated addresses used 0::1 for uncovered prefixes since this was the most common address within a given prefix 165
* - conducted by Waikato Applied Network Dynamics (WAND) research group of the University of Waikato, New Zealand

Current state of IPv6 measurements

A global test of scamper using the destination list described above took place in June 2003. The tool was started simultaneously from four geographically diverse locations: CAIDA (San Diego, US), WIDE (Tokyo, JP), WAND (Waikato, NZ), and University of Oregon (Eugene, US) using the same list of 4235 destinations. A single scamper run (`poll') took between 1.5 and 3 hours depending on source location. We are analyzing the collected data and hope to post preliminary results by August 2003.

Future directions

Contingent on funding availability, we plan to add the following features to scamper:

  1. a new class to standardize reading/writing of skitter and scamper files;
  2. set up scamper to run continuously;
  3. upgrade skitter supporting libraries and analysis tools to work with scamper output.
When the above changes are successfully implemented, our goal is to set up the IPv6 topology monitoring scamper probing system similar to the existing skitter system for IPv4. From our current experience with the macroscopic topology measurements project, we anticipate that operational needs for such a system will include:
  1. establishing monitors around the world;
  2. providing hardware and software resources for continuous data collection, downloading, and archiving;
  3. developing mechanisms for compiling and updating IPv6 destination lists;
  4. sysadmin support.

Questions, feedback, offers of equipment or analysis support:

scamper development team:

Related IPv6 pages

  • IPv6 Information Page
  • IP Next Generation Overview
  • IPv6 Test Traffic Measurements at RIPE
  • IPv6 in Japan (WIDE v6 working group)
  • Published
    Last Modified