wiki:org/meetings/2016WinterDevMeeting/Notes/IPv6

BACK TO 2016 WINTER DEV MEETING NOTES PAGE

The state of V6
Tor clients have been able to connect to bridges since 2.4.1a
clients have been able to connect to relays for a while, but few/none have been doing it
there's been little motivation, and config only works after you've bootstrapped over ipv4 first.
Exits can talk to ipv6-only servers.
Directory authorities are on ipv6 [partly - dirport is not, orport is. not all.]
in 2.8a, want to let a standard client be able to bootstrap on an ipv6 only network.
This meant:
    Adding ipv6 addresses of directory authorities to code
    Teach clients how to bootstrap over ipv6 [download concensus]
    Teach clients how to choose between ipv4- vs ipv6- support servers
    Teach clients which address of a server to use once they've chosen a server

The Future
We should make this work automatically for clients that are on v6 networks, rather than having a flag that must be set explicitly.
Some amount of probing the routing table can potentially done by opening sockets.
A guess can be made by looking at interfaces and addresses.

This probing might look like:
    * do i have a global address of a specific type?
    * do i have a local address of a specific type and nothing of the other one?

This should be the same algorithm that guards use.

Another component is to start with the thing we think is most likely.
Then try the other one if there's any possibility it works
and keep track of what's worked previously, and have that guess decay over time / when network changes.

Should we Auto-v6 people? Probably not this release.
For bootstrap, we need to choose that when we do a release. After that bootstrap point,
we can cause the concensus to flip a flag for the concensus after bootstrap.

What threshold of relays / guards to we need on v6 before we flip those flags.
Suggested that at least 30%-50% of guards as threshold. Guard people / researchers would have a better sense.
Tor should not be the only ipv6 app running on users computers, ideally

Current ipv6 stats:
    4/9 directory authorities
    20-30% of fallback directory mirrors
    under 100/1000 exit-flagged relays

To Do
encourage more relays / guards to be on v6.
ideally we shouldn't use ipv6 addresses that include the mac in the address. nickm has an unmerged patch that tries to do that.
some directories / fallbacks have directory ports that advertise v6, and others that don't. we're not sure if there's an explicit flag that has been used or if there's a platform difference causing this. Clients / Bridges should be able to contact the dir port directory directly. there isn't an explicit ipv6 dirport anywhere in the data structure. right now we're using the ipv4 dir port as an ipv6 dir port.
It's suggested that it's probably better for clients to not use the dir port directly.

We should have a session where we go through the manual / options list and make sure that the different options (like 'fetch dir info extra early' in this case) are still relevant.

There's a goal that the high-bandwidth and high-trust components of directories can be more seperable. it's something that groundwork will be worked on in 2016.

Thinking about promoting ipv6 on exits.
lots of work needed for auto-v6 for exits.
probably need a release to of messaging to tell people that it's coming down the pipe.

Relays don't connect to each other over v6 right now. is there a reason that's true.
you only want 1 connection between each pair of relays. we don't accept ipv6-only relays. many operators can get cheap/free ipv6 bandwidth at this point, so there's an incentive to get some ipv6 relay-relay traffic.

there's an issue where only Hurricane Electric  is providing free default transit on ipv6, which might mean they get to see a scary amount of inter-relay ipv6 traffic if opportunistic inter-relay ipv6 traffic occurs.

relay self-testing is not working over ipv6.
directory authorities testing does, though.

right now we have 2 orports, and 1 running flag, which is a binary-and of the two.
you can have 16 of these. should we have 16 running flags?
it seems like there's not a ton of demand for more than 1 address per protocol.

Things that aren't properly ipv6 aware

  • sibyl protection
  • same-sub net test (we consider same ipv6 /16, which is too big).
  • self-testing
  • the or-port listen address isn't being test
  • if you reconfigure w/ v6 and HUP your tor, it won't close/re-open [needs full identification]
Last modified 18 months ago Last modified on Mar 18, 2016, 11:48:51 PM