Opened 9 years ago

Closed 6 years ago

#2541 closed task (implemented)

Prepare metrics for IPv6

Reported by: karsten Owned by: karsten
Priority: Medium Milestone:
Component: Metrics/Analysis Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Rumours came up that IPv4 addresses are out and we should prepare for IPv6. Here's an initial (and probably incomplete) list of metrics parts that currently rely on Tor being IPv4-only:

  • Tor, geoip database: Directory mirrors count directory requests and resolve the connecting IP addresses to country codes. We use Maxmind's IPv4-based geoip database for this task. Part of the IPv6 integration involves comparing Maxmind's IPv6 database to other databases.
  • metrics-db, bridge descriptor sanitizer: We remove all sensitive information from bridge descriptors before publishing them. As part of this process we replace IP addresses with a cryptographic hash value based on the original IP address. We'll have to think about whether we can simply extend this algorithm, or if that reveals too much about our bridges.
  • metrics-web, relay search: Our relay search supports lookups by IPv4 address which needs to be extended. It's unclear how well IPv6 is supported by PostgreSQL and by our database schema in particular.
  • ExoneraTor: We have a web page, a Java application, and a Python script that allow looking up whether an IP address was registered as relay in the Tor network at a given time.
  • VisiTor: We have a Java application and a Python script to parse web server logs to find out what fraction of requests came from Tor users.
  • Exit lists: We need a new exit list format with IPv6 support for VisiTor and maybe in the future for ExoneraTor, too.

Child Tickets

Change History (2)

comment:1 Changed 8 years ago by karsten

Component: MetricsAnalysis

This is not exactly an Analysis ticket, but I'm splitting the Metrics component into Analysis, Metrics Data Processor, and Metrics Website. Analysis is what fits most. Once there's more progress on this ticket it will split up into one ticket per affected product anyway.

comment:2 Changed 6 years ago by karsten

Resolution: implemented
Status: newclosed

The tasks listed in this ticket are either already done or are irrelevant by now. In more detail:

  • Tor, geoip database: Directory mirrors count directory requests and resolve the connecting IP addresses to country codes. We use Maxmind's IPv4-based geoip database for this task. Part of the IPv6 integration involves comparing Maxmind's IPv6 database to other databases.

tor ships with an IPv6 GeoIP database since 0.2.4.6-alpha, released November 13, 2012.

  • metrics-db, bridge descriptor sanitizer: We remove all sensitive information from bridge descriptors before publishing them. As part of this process we replace IP addresses with a cryptographic hash value based on the original IP address. We'll have to think about whether we can simply extend this algorithm, or if that reveals too much about our bridges.

metrics-db sanitizes IPv6 bridge addresses since January 16, 2012.

  • metrics-web, relay search: Our relay search supports lookups by IPv4 address which needs to be extended. It's unclear how well IPv6 is supported by PostgreSQL and by our database schema in particular.

The current relay-search implementation is too tightly coupled to metrics-web's tordir database to make this change. We have a GSoC student working on a new relay-search implementation which should support IPv6 relay addresses. But there's nothing we can (realistically) do about IPv6 support for the current relay-search code.

  • ExoneraTor: We have a web page, a Java application, and a Python script that allow looking up whether an IP address was registered as relay in the Tor network at a given time.

The web version of ExoneraTor supports looking up relays by IPv6 address since December 11, 2012. The Java and Python version didn't see an update since November 2010 and should be considered unmaintained by now.

  • VisiTor: We have a Java application and a Python script to parse web server logs to find out what fraction of requests came from Tor users.

VisiTor didn't see an update since January 2011 and should be considered unmaintained by now.

  • Exit lists: We need a new exit list format with IPv6 support for VisiTor and maybe in the future for ExoneraTor, too.

This is out of scope for metrics. Once TorDNSEL or TorBEL produces lists with IPv6 addresses, we should open a new ticket to use IPv6 addresses in various metrics tools.

Closing as implemented, which applies to the majority of tasks.

Note: See TracTickets for help on using tickets.