Skip to content
Snippets Groups Projects
New look: Off

Tor Browser fails to bootstrap on IPv6-only access networks

    • Closed (moved) Issue created by Trac @tracbot

    My internet connection is IPv6-only, although DNS64+NAT64 is available.

    When I try to use Tor Browser, it fails to open correctly. It also prints log messages like this:

    [NOTICE] Opened Socks listener on 127.0.0.1:9150 
[WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 3; recommendation warn; host x at 1.2.3.4:9001) 
[WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 4; recommendation warn; host x at 2.3.4.5:443) 
[NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150

    Note that most (non-Tor) things work perfectly fine on my connection, as long as the application is capable of resolving AAAA records and/or connecting over AF_INET6.

    I acknowledge that Tor tends not to be DNS-based (hence DNS64 doesn't help in this case). But I would expect Tor to have a list of IPv6 directory servers to try to connect to in lieu of IPv4.

    Until Tor tries to connect to IPv6 directory servers, Tor Browser will be completely unusable for people on IPv6-only internet connections.

    Version: Tor Browser 8.0.6 on mac OS 10.14.3.

    Trac:
    Username: jeremyvisser

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Trac
      Trac @tracbot ·
      Author

      Trac:
      Child Ticket(s): #32905 (moved)

    • Trac added GeorgKoppen201905 TorBrowserTeam201905 component::applications/tor browser owner::tbb-team priority::medium reporter::jeremyvisser severity::normal status::reopened type::defect labels

      added GeorgKoppen201905 TorBrowserTeam201905 component::applications/tor browser owner::tbb-team priority::medium reporter::jeremyvisser severity::normal status::reopened type::defect labels

    • T
      teor @teor ·

      Hi, thanks for logging this ticket.

      Tor does have a set of hard-coded IPv6 directory servers, but they're not on by default. You can try setting "ClientPreferIPv6ORPort 1" in your torrc.

      There are a few ways for us to fix this issue permanently:

      • tor can learn to auto-detect IPv6-only local addresses, and set "ClientPreferIPv6ORPort 1". This is a quick fix. But if we get the detection wrong, users won't be able to connect.

      • tor can learn to connect over IPv4 and IPv6, and use whichever one works. We have an experimental "ClientAutoIPv6ORPort" option in our alpha versions. But we're not sure if it will trigger other bugs. (For example, the guard code stops using guards when there are too many failures.) It needs more testing.

      • Tor Browser can learn to auto-detect IPv6-only networks, and set the appropriate options. Or it can add a Tor Launcher option that says "I am on an IPv6-only network". OnionBrowser uses this strategy.

      This issue also affects Tor Browser for Android, because some mobile companies have IPv6-only networks (for example, parts of T-mobile's network).

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to teor:

      Hi, thanks for logging this ticket.

      Tor does have a set of hard-coded IPv6 directory servers, but they're not on by default. You can try setting "ClientPreferIPv6ORPort 1" in your torrc.

      There are a few ways for us to fix this issue permanently:

      • tor can learn to auto-detect IPv6-only local addresses, and set "ClientPreferIPv6ORPort 1". This is a quick fix. But if we get the detection wrong, users won't be able to connect.

      • tor can learn to connect over IPv4 and IPv6, and use whichever one works. We have an experimental "ClientAutoIPv6ORPort" option in our alpha versions. But we're not sure if it will trigger other bugs. (For example, the guard code stops using guards when there are too many failures.) It needs more testing.

      • Tor Browser can learn to auto-detect IPv6-only networks, and set the appropriate options. Or it can add a Tor Launcher option that says "I am on an IPv6-only network". OnionBrowser uses this strategy.

      I'd like to avoid that workaround if possible and get this fixed in tor land. teor: what would be a good tor ticket for the tbb-needs keyword?

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to teor:

      • tor can learn to connect over IPv4 and IPv6, and use whichever one works. We have an experimental "ClientAutoIPv6ORPort" option in our alpha versions. But we're not sure if it will trigger other bugs. (For example, the guard code stops using guards when there are too many failures.) It needs more testing.

      I am fine setting that in the alpha series if you think that would be helpful to shake out bugs on tor's side. What's the tor ticket implementing that option?

    • T
      teor @teor ·

      Replying to gk:

      Replying to teor:

      Tor does have a set of hard-coded IPv6 directory servers, but they're not on by default.

      There are a few ways for us to fix this issue permanently:

      • Tor Browser can learn to auto-detect IPv6-only networks, and set the appropriate options. Or it can add a Tor Launcher option that says "I am on an IPv6-only network". OnionBrowser uses this strategy.

      I'd like to avoid that workaround if possible and get this fixed in tor land. teor: what would be a good tor ticket for the tbb-needs keyword?

      #17835 (moved), with a note saying that you need Tor to work on IPv4, IPv6, and dual-stack networks without extra configuration. (We won't do all the child tickets - they are ideas that we can try if we need to.) You could say that you're trialling ClientAutoIPv6ORPort.

      Replying to gk:

      Replying to teor:

      • tor can learn to connect over IPv4 and IPv6, and use whichever one works. We have an experimental "ClientAutoIPv6ORPort" option in our alpha versions. But we're not sure if it will trigger other bugs. (For example, the guard code stops using guards when there are too many failures.) It needs more testing.

      I am fine setting that in the alpha series if you think that would be helpful to shake out bugs on tor's side. What's the tor ticket implementing that option?

      #27490 (moved) in 0.4.0.1-alpha and later.

    • T
      teor @teor ·

      Oh, and before you deploy in Tor Browser, you'll need #27647 (moved), so that IPv6 guards don't end up with half of the (dual-stack) Tor client traffic. And you'll need more IPv6 bridges in Tor Browser, otherwise the load might take down your single IPv6 bridge. (Also, you'll want multiple IPv6 bridges for redundancy on IPv6-only clients.)

      Are there enough Tor Browser alpha users to shift a significant fraction of Tor network traffic? Or are there enough Tor Browser alpha users to bring down your IPv6 bridge?

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to teor:

      Oh, and before you deploy in Tor Browser, you'll need #27647 (moved), so that IPv6 guards don't end up with half of the (dual-stack) Tor client traffic. And you'll need more IPv6 bridges in Tor Browser, otherwise the load might take down your single IPv6 bridge. (Also, you'll want multiple IPv6 bridges for redundancy on IPv6-only clients.)

      Are there enough Tor Browser alpha users to shift a significant fraction of Tor network traffic? Or are there enough Tor Browser alpha users to bring down your IPv6 bridge?

      Yes, having a second IPv6 bridge for redundancy would be neat. However, I am not overly worried that the fraction of alpha users using bridges would bring the one down we have.

    • T
      teor @teor ·

      Just to be clear: I think you should start testing "ClientAutoIPv6ORPort 1" in Tor Browser alpha as soon as you can.

      When we get feedback from Tor Browser alpha users on IPv6-only networks, we can decide when we need to do #27647 (moved).

    • T
      teor @teor ·

      (I saw your comment on the pad today. Please ask questions on tickets: I sometimes miss pad and IRC comments.)

    • Georg Koppen
      Georg Koppen @gk ·

      Trac:
      Keywords: N/A deleted, TorBrowserTeam201903 added

    • Georg Koppen
      Georg Koppen @gk ·

      Moving tickets to April.

      Trac:
      Keywords: TorBrowserTeam201903 deleted, TorBrowserTeam201904 added

    • Georg Koppen
      Georg Koppen @gk ·

      Let's test this in 9.0a1. bug_29641 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_29641&id=f75cf0bd2e1c4cef96a31e266da4a0385e5f2016) has the patch for review.

      Trac:
      Keywords: TorBrowserTeam201904 deleted, GeorgKoppen201905, TorBrowserTeam201905R added
      Status: new to needs_review

    • Mark Smith
      Mark Smith @mcs ·

      r=mcs Looks good. Do we need a patch for Android?

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to mcs:

      r=mcs Looks good. Do we need a patch for Android?

      Yes. Let me add one shortly and get sisbell to ack it.

    • Georg Koppen
      Georg Koppen @gk ·

      Actually, skip that for now. We are still on 0.3.5.8 on Android and that option is only available in the 0.4.x series. I'll file a new ticket for it.

    • Georg Koppen
      Georg Koppen @gk ·

      #30508 (moved) is the one for mobile. Meanwhile I moved forward and merged the patch to tor-browser-build's master with commit dd098db690092cba90a315853d624b5bf1cd97fe.

      Trac:
      Resolution: N/A to fixed
      Status: needs_review to closed

    • Georg Koppen
      Georg Koppen @gk ·

      This got backed out in commit 5e8a92b225e3f67a4df6ce9e47e62eee59ed90fb. See: #30639 (moved) for further work that is needed.

      Trac:
      Keywords: TorBrowserTeam201905R deleted, TorBrowserTeam201905 added
      Status: closed to reopened
      Resolution: fixed to N/A

    • T
      teor @teor ·

      Tor Browser will work in IPv6 networks, when Tor implements proposal 306: https://gitweb.torproject.org/torspec.git/tree/proposals/306-ipv6-happy-eyeballs.txt

      We don't currently have any schedule or funding for that proposal. We need more IPv6 relays before we can deploy proposal 306 across a large number of Tor clients, because the proposal has load-balancing impacts.

    • Georg Koppen mentioned in issue #30508 (moved)

      mentioned in issue #30508 (moved)

    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    Please register or sign in to reply