Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 823
    • Issues 823
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 30
    • Merge requests 30
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #19608
Closed
Open
Created Jul 06, 2016 by teor@teor

IPv6-only clients can't fetch microdescriptors on 0.2.8.5-rc

There's a lovely catch-22 when IPv6-only clients try to fetch microdescriptors:

  • some fallback directories are on IPv6, and deliver the microdescriptor consensus
  • but the microdescriptor consensus doesn't contain any IPv6 addresses
  • but it's a consensus, so IPv6-only clients try to use it to find an IPv6 relay, and fail

A solution is to teach IPv6-only clients to get (at least some of) their descriptors from the fallback directories, at least until they have some IPv6 microdescriptors. Perhaps this should happen automatically when the entire consensus fails, but for some reason it doesn't.

I have no idea how we didn't catch this during testing - perhaps there were always cached descriptors? Perhaps we broke falling back to the fallbacks for descriptors?

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