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 320
    • Issues 320
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 37
    • Merge requests 37
  • 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
  • #24868
Closed
Open
Created Jan 11, 2018 by teor@teor

Check a consensus parameter before activating onion service IPv6 features

We've implemented legacy/trac#23577 (moved), but it looks like none of the other onion service IPv6 code will be ready for 0.3.3.

(We want to do the relay IPv6 code first.)

If we merge this in 0.3.3, then services will be able to distinguish 0.3.2 and 0.3.3 (and later) clients, when the rend point is dual-stack.

Do we want to add a torrc option / consensus parameter for v3 onion service IPv6? Or are we happy with this information leak?

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