Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #15518

Tor considers routers in the same IPv6 /16 to be "in the same subnet"

When EnforceDistinctSubnets is enabled, tor uses:

/** Return true iff router1 and router2 have similar enough network addresses                                                                                                                                       
 * that we should treat them as being in the same family */
static INLINE int
addrs_in_same_network_family(const tor_addr_t *a1,
                             const tor_addr_t *a2)
{
  return 0 == tor_addr_compare_masked(a1, a2, 16, CMP_SEMANTIC);
}

to determine if an address is in the same family. For an example IPv6 address, 2001:1234::0:1, its /16 representation is 2001::/16, meaning that 2001:ffff:: would be in the same family. A \16 for IPv6 is huge, particularly considering that only one-eighth of all IPv6 space is currently allocated for use on the internet (2000::/3). For the path selection code, using /16 essentially means that no two IPv6 routers in the same country (or possibly even continent) will be in the same path, and might possibly provide extremely increased chance of selection to routers in weird/rare IPv6 subnets.

For a related ticket, see #15517 (moved) governing how BridgeDB's version of EnforceDistinctSubnets will work for IPv6. (In that ticket, I proposed using IPv6 /32s, since that is the minimum ARIN IPv6 subnet allocation for a LIR.

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