Half the Tor Network Now Speaks IPv6: What It Changes for Users
A few years ago, running a Tor relay over IPv6 was a niche experiment that most operators ignored. Today, roughly half of all relays announce an IPv6 ORPort, and a clear majority of the network's bandwidth sits behind addresses on both protocols. The shift is quiet, measurable, and it changes how reliably users reach the network at all.
From fringe option to network default
In late 2020, when the Tor Project published its first detailed accounting of IPv6 adoption, only about 36 percent of total consensus weight carried an IPv6 ORPort, and just over 1,500 of nearly 6,900 relays announced one at all (Tor Project blog). Those numbers came out of work funded through RIPE NCC's community projects and shipped in Tor 0.4.5, which for the first time let relays report IPv6 bandwidth statistics. Four years on, the picture looks very different. The relays-ipv6 graphs on Tor Metrics show a steady climb toward parity: around half of relays now advertise IPv6, and IPv6-capable relays account for well over half of advertised capacity. Big, stable operators moved early. The long tail followed.Dual-stack relays are the real story
Almost none of this is IPv6-only operation. The official guidance remains explicit: operators are encouraged to enable IPv6 alongside IPv4, but every relay still needs an IPv4 address (Tor Support portal). Dual-stack is the deployment model, not a transition away from the old protocol. For users, dual-stack matters at the edge of the network. A client with native IPv6 connectivity can connect directly to its guard relay over IPv6, skipping carrier-grade NAT boxes and any middleboxes that mangle long-lived TCP sessions. That translates into faster circuit builds and fewer dropped connections, particularly on mobile networks where IPv6-first provisioning has become standard. Reachability testing got smarter too. Proposal 311 introduced relay-to-relay IPv6 extends so relays can self-test their IPv6 ORPort through the network rather than guessing (Tor design proposals). Directory authorities now confirm IPv6 reachability before publishing it in the consensus, which keeps stale addresses out of client view.Tor has partial support for IPv6 and we encourage every relay operator to enable IPv6 functionality in their torrc configuration files when IPv6 connectivity is available.That line from the support documentation sums up the current stance: IPv6 is production-ready infrastructure, deployed opportunistically wherever the host allows.
The long tail of IPv4 exhaustion
Economics is doing much of the pushing. IANA's IPv4 pool ran dry back in 2011 and every regional registry has since exhausted free space, making fresh IPv4 blocks expensive and scarce (Internet Society). Relay hosting is feeling it directly: budget VPS providers increasingly charge separately for each IPv4 address, while IPv6 comes bundled by default. That pricing pressure lands hardest on small volunteer-run relays, exactly the diverse tail that gives Tor its resilience. An operator spinning up three modest middle relays may find IPv4 rental costs exceed the server itself. Dual-stack relays amortize one IPv4 address across more capacity, and IPv6 gives newcomers a cheap path in. The catch: Tor cannot yet run on an IPv6-only host, so the address market still taxes every operator regardless of preference. Removing that requirement remains a long-discussed goal without a shipping timeline.Why exit relays lag behind
Guards and middles adopted IPv6 fastest; exits trail because exiting adds policy complexity. An exit that permits IPv6 destinations needs separate IPv6 exit rules, and abuse handling across two protocol stacks doubles some operational headaches. Even so, hundreds of exits already allow IPv6 targets, tracked continuously on Tor Metrics. For onion services the calculus differs again. Services benefit whenever either leg of a connection, inbound or outbound rendezvous, can ride IPv6, since every additional reachable path widens the pool of usable guards and introduction points.What to watch next
The trajectory points toward IPv6 becoming the majority transport for client-to-guard connections, even while IPv4 stays mandatory at the relay layer. Users do not need to configure anything; Tor Browser negotiates automatically based on what the local network offers. If you operate infrastructure or follow the network closely, the signals worth tracking include:- The share of relays and consensus weight with confirmed IPv6 ORPorts on Tor Metrics
- IPv6 advertised bandwidth versus IPv4, a proxy for how much traffic rides each stack
- Any movement toward relaxing the IPv4 requirement, which would unlock IPv6-only hosts