You are here: Home > Publications > RIPE Labs > Franz Schwarzinger > Untunneling IPv6

Untunneling IPv6

Franz Schwarzinger — Nov 2009
For more than five years now, the RIPE NCC has been measuring the number of native (no IPv4 transit) versus tunneled (IPv6 traffic whose path includes transit via IPv4 tunnels) IPv6 interconnections in the core of the Internet. These measurements have been conducted using the Test Traffic Measurement network. In this article, we look at the collected data to see whether and how much IPv6 interconnections have improved.
Test Traffic Measurement

The Test Traffic Measurement (TTM) service has been offered by the RIPE NCC since October 2000, as part of a broader effort to offer highly accurate measurements of Internet connectivity, Today TTM consists of more than 80 measurement nodes, spread across the entire globe. In 2008, the RIPE NCC announced TTM coverage on every continent except Antarctica.

The measurement nodes are located at Internet Service Providers (ISPs), private companies with affinity to the Internet community, research institutions, and the Regional Internet Registries (RIRs). This variety of locations means that the TTM network can provide a solid foundation for representative Internet measurements.


TTM continuously measures the following three basic aspects of Internet connectivity in a full-mesh configuration:

•    One-Way Delay (synchronised by GPS clocks)
•    Loss & Jitter
•    Traceroutes

Since 2003, TTM has supported measurements over IPv6, in addition to the existing IPv4 measurements. 

Tunnel Discovery

Over the years TTM data has been used as a basis for many research projects and scientific papers. In 2003, Lorenzo Colitti joined the RIPE NCC to work on an IPv6 tunnel discovery tool. His work was based on previous papers ( ), which he published together with the Roma Tre University in Italy.

At that time, IPv6 packets were often transmitted by encapsulating them in IPv4 packets and sending them over existing IPv4 links (so called tunnels). This was necessary to overcome the lack of native (or direct, end-to-end) IPv6 connectivity on the Internet.


Using the technique that Lorenzo developed, it is possible to detect the existence of IPv4 tunnels on a given route by analysing IPv6 traceroutes and the MTU (maximum transmission unit) size of the packets returned by the traceroute process. A detailed description of the process can be found on the website of the Roma Tre university:


The RIPE NCC offers a tool that displays this data as part of their TTM service:


Today’s Native IPv6 Internet


This data has now been collected by the RIPE NCC for more than five years, so we were wondering if the amount of native IPv6 connections on the Internet had increased during that time. We analysed the IPv6 tunnel discovery data, taking three data points every month since the beginning of 2004. We counted the occurrences of tunnels measured within our full-mesh of TTM nodes and compared them to the total number of IPv6 relations.




The graph above shows the exact data points as yellow dots. Since the data turned out to be quite noisy, we also plotted a linear approximation (the blue line), which shows that the number of IPv6 tunnels has decreased steadily over the last five years.


In interpreting this data, one should keep in mind that the TTM nodes are mainly attached to the core of the Internet (ISPs, research organisations, etc.). Due to the nature of the tunnel discovery tool, we are not only measuring the direct interconnection of the TTM nodes, but also any interconnections along the path followed from source to destination. This gives us a good estimation of how well the Internet at large is natively connected via IPv6.


It is important to note that these measurements do not give an indication of how many networks are actually using IPv6. The data at hand only shows the native versus tunneled ratio of interconnections that are already IPv6 enabled.


It is also important to note that the edge of the Internet is not covered by TTM and we cannot make any judgments on how well End Users are natively connected via IPv6.
The relatively high noise in 2004 and 2005 could be attributed to fewer people transiting IPv6 during that period. If a single IPv6 transit provider changed from tunneling to native the effect would have been bigger at that time than it is with the more diversified pool of IPv6 transit that we have today.


Another reason for the noise could be people still experimenting with IPv6, changing frequently between tunneled and native connectivity as they figure out what best suits their needs.
Overall the results are quite pleasing. It is good to see that operators on the Internet are making an effort to move away from tunneled IPv6 connections to native ones and that we see more stable IPv6 connectivity today.


We would like to ask our readers about their ideas about this plot: Do you have an explanation for the data having more noise in 2004 and 2005? Do you think this linear trend will continue? Will IPv6 ever be tunnel-free?


Anonymous says:
22 Dec, 2010 04:57 PM
AFAIK 6bone did involve a lot of tunneled connections - so maybe this spike and subsequent dip pre-2006 might be related ?
Anonymous says:
22 Dec, 2010 07:15 PM
Thanks for that suggestion Andrew, looking into it a bit and the timing of spike and dip roughly correlates with 6bone decommissioning (halt to new 6bone prefix allocations on 1 January 2004, operation ceased 6 June 2006). I couldn't find any timeline that has more accurate info on what was decommissioned when. Eyeballing the individual traceroutes between nodes at that time there are indeed some hops in 3ffe::/16. See for instance[…]h=06&day=01&hour=00 , click on the MTUs to see the traceroutes.

I also ran the code we used for this article over 2010 and again see a slow but steady decrease. The 3 last data points (1 Dec, 11 Dec and 21 Dec) now show 4.8%, 3.1% and 4.5% of paths that contain at least one tunneled connection. We're getting there :)
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.