dirauth reachability tests, checking if relays are reachable
relays self-test -- is it worth publishing the relay descriptor at all? Plus quick feedback to the relay operator about whether the relay is working.
Each dirauth then does reachability test too
the dns thing ahf mentioned
client sends "cnn.com" to exit relay and exit resolves it and connects
If we instead reached a DoH or DoT server, it would mean extra latency for client connections
dnsto64 and Nat64
avoiding roundtrips, smarter dns resolving? Client-side alternatives,
whonix is a wrapper around control port and dnsport
onionmask, the engine for the vpn application, using arti
the oniux tool for testing
we could measure time for extending and more
bridges reachable only over v6 and clients that need a v6 bridge
rdsys (used to be called bridgedb) is giving out v6 bridgeline
Do ipv6 obfs4 bridges work in Tor Browser today?
we used to try to look like FF wrt to TLS traffic
since 2011, browsers are doing "happy eyeballs"
first start v6 connection, wait some 30 ms and fire off a v4 connection
apple did something similar, but what are they doing now?
tor can not use the dns method
we could experiment with this today, goal being to collect data for an upcoming proposal
can do most of this in f.ex. python; parsing descriptors (stem), ...
we can get (good) patches into ctor
fallback dirs should all be dual stack?
python 2.7 has some ipv6 detection mechanisms and tor has one too, but today the method used doesn't make much sense (bc the answer on a modern OS is always yes there is ipv6)
relay-to-relay
if two relays both have both protocols, which protocol are they picking and what should they pick? Open research area about whether to send traffic through one path or the other or split it
"canonical connections"
decades of experience (outside tor) shows that dual stack is very complex -- can we avoid doing that?
goal for now: pick the low hanging fruit
client -> guard and client -> bridge
inter-relay connections
what's missing on the metrics port, for an exit operator doing ipv6?
nlnog ring and ripe atlas could help with testing of reachability
ooni is the right place for this kind of testing
failing reachability tests (from dirauths) over v6 mark the relay down
high impact issue
document and name "all the things"
can protocol used on one leg be visible on other legs (hops between relays)?
we hope not
is there good documentation for dual stack on the "simple internet"? that we can take inspriation from
tyk and kramse might be able to find out, from RIPE and/or IETF
Experiment -- what's the current situation on the ground¶
TODO: collect experiments to be done ~now / upcoming 48h, for both tor and browsers and other (like OS'es)
TODO: Experiment using Linux namespaces with different setups with C Tor instances: * Try out different torrc options related to IPv6 * Try out IPv6-only, and IPv6-only-that-becomes-IPv4-only * Figure out if any of the IPv6 torrc options makes Tor over IPv6 bootstrap nicely.
TODO: Does Tor's self-reachability test work with C Tor for IPv6?
TODO: Experiment with and think about DNS-over-TLS-over-Tor:
How should we handle circuits?
How should we warmup circuits?
Measure latency for this vs. connect-to-hostname over Tor
TODO: Fix issue where a Tor relay gets marked as unavailable if IPv6 isn't reachable