Tor Relay Operator Meetup at FOSDEM 2026
Hello Tor Relay Operators, We will not only have a booth at FOSDEM this year, but we will also have a Relay Operator Meetup. The event will take place as a BOF on the Sunday (2026-02-01) at 13:00 to 14:00 in room H.3244. I'll do a little intro when we arrive, but I'll make sure we have enough time for a long Q&A session. Remember, this is an excellent opportunity to show up, ask questions, perhaps answer some questions, and say hi to some of your fellow Tor operators. For more information, please check out: https://fosdem.org/2026/schedule/event/DRMMAB-tor_relay_operator_meetup/ See you there! Cheers, Alex -- Alexander Hansen Færøy
Hello Tor Relay Operators! Hope those of you who participated in the FOSDEM Tor Relay Operator meetup made it home safely from the event. As always, I try to write down notes from the meetings, but since I write them after the meeting, I have almost certainly forgotten a lot. Please add context that you think is missing in this email. It's been a while since we did Tor Relay Operators meetups during FOSDEM. We ended up being between 30 and 40 people in the tiny, windowless room at the event, which was more than I anticipated. I will make sure we do a similar meetup at FOSDEM in 2027! The meeting started with a short presentation from me about where we are with the network work. The big topics here were Post-Quantum Cryptography, the transition to Happy Families, the move to MaybeNot on Arti for better padding-state machines, Proposal 344 + Tor's threat model, and Arti Relays. The slides were primarily based on the slides from the 39c3 Relay Operator meetup, and they are available from https://ahf.me/talks/2026/02/01/tor-relay-operators-meetup/ Afterwards, Jules Dejaeghere from Université de Namur gave a short presentation on their research project, which they also wrote about on this email list. They are actively looking for volunteers from the Tor relay operator meetup to conduct interviews on operational practices for running relays in the network. I understood from Florentin on IRC that they had a lot of sign-ups after the meeting, which is fantastic. Thanks to everybody who signed up to help this research group. The Tor Project relies heavily on the research community, so the more ways we can help them the better <3 Afterwards, we had around 30 min. of Q&A. The big topics here were: - Should Tor's path selection algorithm take into account AS-path information to avoid circuits transiting through similar networks in the circuit path? I mentioned some of the earlier papers on this work. One of them was "Guard Placement Attacks on Location-Based Path Selection Algorithms in Tor," and the other was "CLAPS: Client-Location-Aware Path Selection in Tor." For more information about the two, please check out https://www.freehaven.net/anonbib/ - When do we get IPv6-only relays? Probably after we have moved to Arti Relays, but to get to the point where we have IPv6-only middle nodes, we need all guards and exit nodes to have IPv6. This work can begin now. As part of this, we also briefly discussed how, with the transition to Arti Relay, we expect to see a smaller Tor network (in terms of the number of relays), but hopefully a more performant network. - We talked about some problems with the deployment of Post-Quantum Cryptography, where we depend heavily on our dependencies being available in the distributions that Tor relay operators run. For the upcoming Arti Relay test network, we will likely experiment more aggressively with containerized deployments, allowing us to control more of the stack (e.g., libssl, libcrypto) on the release side of Tor. - This led to a broader conversation about stateless relays and remote attestation. I lost a bit of track of this, but within The Tor Project, many of us are very excited about the work that different relay operator groups are doing in this space. Both stateless relays and work on remote attestation, as well as getting the various cryptographic keys used in the Tor network into transparency logs. We think this work could significantly support our Network Health efforts. I suggested that a nice demo here would be an Onion Service that allows remote attestation of the service by potentially publishing some of the metadata needed in the Onion Service descriptor. This entire conversation eventually became the big topic on the hallway track after the meeting, too. We also plan on making it possible in C Tor to make the Onion key easier to handle in the stateless relay situation. Thanks to everybody who participated! Please let me know if there is anything we can do better in these meetings. Feel free to reach out if you have any questions that need more elaboration. I do not know when the next Tor Relay Operator meetup will be, but I know I will be hosting one in the summer at BornHack 2026. I hope someone who is going to EMF in the UK (unfortunately at the same time as BornHack this year) can host a Relay Operator meetup there too! Cheers, Alex -- Alexander Hansen Færøy
On 05.02.2026 14:57 Alexander Hansen Færøy via tor-relays wrote:
- When do we get IPv6-only relays? Probably after we have moved to Arti Relays, but to get to the point where we have IPv6-only middle nodes, we need all guards and exit nodes to have IPv6. This work can begin now. As part of this, we also briefly discussed how, with the transition to Arti Relay, we expect to see a smaller Tor network (in terms of the number of relays), but hopefully a more performant network.
There are some other parts that could be done: ClientPreferIPv6ORPort 1 could be enabled by default, maybe together with a fallback to IPv4 if the connection is not possible. That would massively increase IPv6 traffic. Guards (only Guard position) reachable by IPv6 only should be possible. Certain home user plans don't include a public routable IPv4 address, but IPv6. IPv4-only middle relays can be reached by CGNAT by those machines. That would enable many users to run such relays that currently cannot. Exits with an IPv6 only exit policy are currently not possible. Is there a special reason for that? The client already need to check the policies of the exit relays to determine if the exit is suitable for the connection. Are those things part of the plan?
On 05/02/2026 19.39, Marco Moock via tor-relays wrote:
There are some other parts that could be done:
ClientPreferIPv6ORPort 1 could be enabled by default, maybe together with a fallback to IPv4 if the connection is not possible. That would massively increase IPv6 traffic.
Guards (only Guard position) reachable by IPv6 only should be possible. Certain home user plans don't include a public routable IPv4 address, but IPv6. IPv4-only middle relays can be reached by CGNAT by those machines. That would enable many users to run such relays that currently cannot.
Exits with an IPv6 only exit policy are currently not possible. Is there a special reason for that? The client already need to check the policies of the exit relays to determine if the exit is suitable for the connection.
Are those things part of the plan?
I think they are in the potential solution space, yeah. At the recent Tor Community Gathering, I did a small project with scanning the network for latency differences between IPv4 and IPv6 to figure out how something like Happy Families would look in a Tor context. Browsers went with a slight delay for IPv4 when trying to "upgrade" to v6 (which has no delay). We may want to use that too, but in practice, we may as well just try to connect on both IPv4 and IPv6 at the same time and use the one that establishes a connection first. This goes for both client -> guard connections, but also for relay to relay connections. I will need a bit more time to look at the data, so realistically, this will be after the next Tor Community Gathering, which takes place at the beginning of March. I suspect the initial output will be a Torspec proposal, and then some experimentation in Arti and/or C Tor. Cheers, Alex -- Alexander Hansen Færøy
Am 05.02.2026 um 19:54:08 Uhr schrieb Alexander Hansen Færøy via tor-relays:
We may want to use that too, but in practice, we may as well just try to connect on both IPv4 and IPv6 at the same time and use the one that establishes a connection first. This goes for both client -> guard connections, but also for relay to relay connections.
I think that is a nasty solution. Preferring IPv6 and falling back to IPv4 is much better, as opening 2 connections just consumes more resources for no reason. -- Gruß Marco Send unsolicited bulk mail to 1770317648muell@cartoonies.org
participants (2)
-
Alexander Hansen Færøy -
Marco Moock