Opened 8 years ago

Closed 7 years ago

#5055 closed enhancement (fixed)

Extend bridge statistics to learn about IPv4 vs. IPv6 usage

Reported by: karsten Owned by: ln5
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: ipv6 tor-bridge
Cc: nils@…, ln5 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


One of the main purposes for making bridges accept IPv6 connections was to circumvent some firewalls. But we don't have any statistics to see how well that works. IPv6 bridges always support IPv4, too, so we can't say from the current bridge statistics if connections came from one or the other address version.

In #5053 I briefly wondered if we should add a new country code "?6" to count unresolved IPv6 addresses. But that doesn't make sense, because as soon as we have an IPv6 GeoIP database, we wouldn't know if users coming from "de" actually connected to the bridge via IPv4 or IPv6.

How about we add a new line "bridge-ip-versions v4=NN,v6=NN" to count unique IP addresses for the two IP address versions?

In theory, we could add similar lines to the other statistics, but it mostly matters for bridge usage. I would want to do this for bridge statistics only, at least for the moment. And by "for the moment" I mean for 0.2.4.x.

Child Tickets

Change History (16)

comment:1 Changed 8 years ago by nils

Cc: nils@… added
Status: newneeds_review

I have a proposed change to track ipv4 versus ipv6 connections on my github (username "shkoo") tor.git repository, branch "bug5055".

This includes a merge from my proposed IPv6 GeoIP database addition for bug 5053 (since there are some conflicts); if we don't end up including that, use commit d46bbd04af8eae6857481b3c8b89bebc8490e325 instead of the end of the branch.

comment:2 Changed 8 years ago by ln5

I've been running shkoo's bug5055 branch for a couple of days now on
the bridge which is announced at bridges.tpo. It seems to be working
fine. I see things like

bridge-ips ??=32,cn=16,jp=8,us=8
bridge-ip-versions v4=1,v6=42

comment:3 Changed 8 years ago by karsten

Ah, we'll probably want to round numbers in bridge-ip-versions to the next multiple of 8, too. See round_uint32_to_next_multiple_of in geoip.c for that. Other than that, results look plausible. (I haven't looked at the patch yet.)

comment:4 Changed 8 years ago by karsten

Status: needs_reviewneeds_revision

I finally got around to review your bug5055 branch. Thanks for this code!

I made two changes: first, I rounded up observations to the next multiple of 8; second, I took out the *-ip-versions lines for everything except bridges. See commit 9f207de in branch nils-bug5053-bug5055 in my public repo.

Remaining things are writing a changes/ file, preparing a dir-spec.txt patch, and fixing whitespace issues. Want to look into that, or shall I?

comment:5 Changed 8 years ago by ln5

As a quick update on the great value of this patch, this is what I see today:

bridge-ips cn=64,??=48,tw=32,ca=16,jp=8,us=8
bridge-ip-versions v4=1,v6=150

We're clearly doing something right here.

(I suspect that the IPv4 connection is the self-testing.)

comment:6 Changed 8 years ago by ln5

Cc: ln5 added

comment:7 Changed 7 years ago by ln5

Karsten, wanna finish this or should I?

Tor was tagged the other day, with 'bridge-ip-versions'
in stats/bridge-stats.

We need to get info on 'bridge-ip-versions' into dir-spec.txt.

What about the changes file? Should we mention this even if it's a bit late?

comment:8 in reply to:  7 Changed 7 years ago by karsten

Replying to ln5:

Karsten, wanna finish this or should I?

I'm afraid I cannot work on this anytime soon. If you can handle it, please do. Thanks!

comment:9 Changed 7 years ago by ln5

Owner: set to ln5
Status: needs_revisionassigned

comment:10 Changed 7 years ago by ln5

Keywords: ipv6 added

comment:11 Changed 7 years ago by nickm

Keywords: tor-bridge added

comment:12 Changed 7 years ago by nickm

Component: Tor BridgeTor

comment:13 Changed 7 years ago by ln5

Status: assignedneeds_review

Finally, please review branches bug5053-bug5055 in my public tor repo
and bug5053-bug5055 in my public torspec repo.

The code has been tested in a private test network and on a public
bridge relay. I think it's ready for merging into master after
somebody's taken a look at the potential alignment issue in

Please note that the tor branch hasn't been rebased onto master as of
today, but rather onto master from just before the big
remove-reserverd-keywords change. My perl skills failed me, sorry.

Also, this branch contains a changes file for #5053 too.

comment:14 Changed 7 years ago by nickm

Status: needs_reviewneeds_revision

Pasted a quick review on the ticket for #5053.

comment:15 in reply to:  14 Changed 7 years ago by ln5

Status: needs_revisionneeds_review

Replying to nickm:

Pasted a quick review on the ticket for #5053.


Issues fixed, commented on #5053.

Let me know if you find more.

comment:16 Changed 7 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merged the bug5053-5055 branch. Thanks!

Note: See TracTickets for help on using tickets.