A Look Into the Tor Network Work on Supporting IPv6

This work was funded by the RIPE NCC Community Projects Fund 2019.

At the Tor project, one of our goals for 2020 was to improve the Tor network's IPv6 support. Improving IPv6 support is key to helping users under censorship, particularly in the Middle East and Central Asia. Many censorship devices are IPv4-only, and adding IPv6 support to the Tor network immediately provides circumvention for users impacted by this kind of censorship. In the censorship arms race, this will have a significant impact for censored users. Improving Tor’s IPv6 support will help users living in regions where there are many IPv6-only or IPv6-by-default networks. There is already significant adoption of IPv6 in some parts of the RIPE NCC service region with high Tor usage. According to a 2018 Internet Society report, British Sky Broadcasting has IPv6 deployment in excess of 86%, Deutsche Telekom (56%) in Germany, and XS4ALL (71%) in the Netherlands all have very significant IPv6 deployment and high Tor usage.

Implementing IPv6 ORPort reachability checks

The first achievement of this project was the implementation of IPv6 ORPort reachability checks on relays. To do this, we wrote proposal 311 which extends our reachability checks to include IPv6, and also makes our existing self-check logic rational and well-specified. By implementing this code, we got self-testing working so that relays can tell whether they are reachable on IPv6 and alert their operators if they are not. This work has simplified our reachability logic, and will in turn enable future improvements and simplifications to that code.

As a follow-up to this work, we took a second look at a number of older issues in our reachability-testing code to make sure that they wouldn't affect IPv6, and to fix them if feasible.

We also made relays figure out their own IPv6 address. That means that now relays (and bridges) can determine their own IPv6 addresses. Initial exploration in proposal 312 explained how to do this. In practice, we extended this work to provide a better user experience for relay operators, and to interact with our reachability tests above. This work has simplified and unified the way Tor handles address discovery, and will in turn enable future improvements to that code as relay operators gain more experience with this feature.

Improving 'Chutney'

At Tor, we use a tool called 'Chutney' to configure and create Tor test networks as well as monitor and run tests in the network. With this project, we did major work on Chutney to update how it handles self-testing and relays. Previously, we had to tell relays to assume they were reachable on chutney networks - but this makes it impossible to test our reachability-testing code. Now Chutney can handle waiting for relays to find out that they are reachable, and our tests can detect malfunctioning reachability tests. To implement this, we had to refactor Chutney's launch logic to configure networks in stages, and wait for each stage to bootstrap before launching the next.

Making measurements

Finally, we focused on measuring the number of Tor relays that support IPv6 reachability checks. We wrote a Python script that uses Stem to parse a consensus and extract numbers and consensus weights of relays that support IPv6 reachability checks. By the end of July 2020, 1,527 of 6,758 relays had an IPv6 ORPort, of which 109 supported at least partial IPv6 reachability checks and 81 supported full IPv6 reachability checks.

We also measured the number of connections, and consumed bandwidth, using IPv4 and IPv6. At the end of July 2020, only a small fraction of IPv6-enabled relays ran a recent-enough Tor version to report IPv6 bandwidth statistics, and none of them reported IPv6 connection statistics yet. We wrote a small Java program based on the Tor Metrics Library that extracts IPv6 bandwidth statistics, and we visualised these statistics as fractions of reported bytes for which the IP version is known (with fractions being of the order of 1.0% to 1.5%). We will have to wait a few more weeks or even longer for relays to report IPv6 connection statistics before being able to visualise those.

Figure 1: IPv6 bandwidth statistics over time

As a result of this work, all IPv6-first or IPv6-only users in the RIPE NCC service region will have a more reliable experience on the Tor network. As more and more networks go IPv6-only or IPv6-first, more users will benefit (see this report for more details). This project can have an instantaneous benefit for censored users: some censorship equipment only supports IPv4, so having IPv6 support on the Tor network immediately creates broader access to censorship circumvention. Over time, this project has the potential to impact the one million plus daily Tor users in the RIPE NCC service region.

In the next couple of months, we will encourage more relay operators to configure their servers to have IPv6 enabled. Once we have a bigger portion of the Tor network able to use IPv6, then we can start thinking about the next phase of this project. Some of the next steps could be:

• Stop requiring a publicly routable IPv4 address for relays and bridges.

• Make IPv6 capable clients start connecting over IPv4 and IPv6.

• Make clients download directory information over IPv4 and IPv6.