Enable clients to talk to public bridges via IPv6
We need to extend Tor for clients to talk to public bridges via IPv6. We may also need to: add an IPv6 GeoIP databases for bridge statistics, extend BridgeDB to give out IPv6 addresses of bridges, update metrics-db to sanitize bridge descriptors with IPv6 addresses. The exact steps will be described in the roadmap that comes out of #4556 (moved).
This ticket is a deliverable for June 30, 2012 for sponsor G.
Activity
Here are some notes from Nick, Roger, Linus, and I discussing the topic yesterday:
-
The bridge authority can rather easily do reachability tests for IPv6 bridges, because these tests are done directly.
-
The bridge authority should include the Running flag if the bridge is reachable over the IPv4 OR address and port stated in the router line of its descriptor. This is for backwards compatibility reasons. A bridge which is reachable over IPv4 while announcing a misconfigured IPv6 address should still be given out to IPv4 clients.
-
The bridge authority should include all parts of or-address lines for which it can confirm reachability. If the bridge authority can confirm bridge reachability for only a subset of ports of a given or-address line, it should include only these ports in the "a" line of the bridge network status entry.
-
Replying to karsten:
- The bridge authority should include the Running flag if the bridge is reachable over the IPv4 OR address and port stated in the router line of its descriptor. This is for backwards compatibility reasons. A bridge which is reachable over IPv4 while announcing a misconfigured IPv6 address should still be given out to IPv4 clients.
This contradicts text in proposal 186
An authority shouldn't list a node as Running unless every or-address line it advertises looks like it will work.
IIRC, I've heard people (Nick?) talking about a Running6 flag. Is this the time for such a flag?
Replying to ln5:
Replying to karsten:
- The bridge authority should include the Running flag if the bridge is reachable over the IPv4 OR address and port stated in the router line of its descriptor. This is for backwards compatibility reasons. A bridge which is reachable over IPv4 while announcing a misconfigured IPv6 address should still be given out to IPv4 clients.
This contradicts text in proposal 186
An authority shouldn't list a node as Running unless every or-address line it advertises looks like it will work.
IIRC, I've heard people (Nick?) talking about a Running6 flag. Is this the time for such a flag?
Maaaybe. One thing we never figured out was how to deal with multiple addresses when there can be more than one ipv4 or ipv6 address. Having a "running6" flag doesn't make too much sense in the light of the possibility of a node having multiple IPv4 or IPv6 addresses.
One possibility is for the authorities to only include "a" lines for addresses that look to be running, and for the voting algorithm to include only those a lines listed by a majority of authorities. That way we wouldn't need one flag per address. Another possibility is to stick an (optional) Running flag on each a line.
Let's keep node_t->is_running as it is and add no more running flags. An existing address which is not "the primary address" (i.e. rs-> and ri-> ipv4h_addr) is assumed to be running. Naturally, we won't set addresses (i.e. rs-> or ri-> ipv6_addr) if they're not in the router descriptor (alternatively doesn't have the new optional Running flag on their "a" line).
Replying to ln5:
Let's keep node_t->is_running as it is and add no more running flags. An existing address which is not "the primary address" (i.e. rs-> and ri-> ipv4h_addr) is assumed to be running. Naturally, we won't set addresses (i.e. rs-> or ri-> ipv6_addr) if they're not in the router descriptor (alternatively doesn't have the new optional Running flag on their "a" line).
First, we shouldn't generally have to assume that non-primary addresses are running. Authorities (directory and bridge) can perform reachability tests. Maybe authorities not on IPv6 should assume IPv6 OR ports to be reachable when voting, to not punish IPv6 relays just because they're not capable of testing them -- false positives should be be better than false negatives. In the context of bridges have to care only about Tonga, which reportedly is on IPv6 as soon as we wish it to be.
Second, the "we won't set" part is confusing. The first part seems to be about authorities and clients looking at router descriptors. The second part is clearly about how to interpret a status document (consensus or vote).
Proposed solution* for authorities:
-
Perform reachability tests for IPv6 OR port if there is one (!tor_addr_is_null(routerinfo_t->ipv6_addr) and we're on IPv6 (haveIPv6Connectivity).
-
Include OR ports in the routerstatus_t of a relay if
!haveIPv6Connectivity || node_t->last_reachable6 >= now-REACHABLE_TIMEOUT
-
A non-primary OR port (i.e. IPv6) included in the routerstatus_t will be listed in an "a" line in status documents.
(*) this is constrained to the current situation with one to two OR ports (on mandatory IPv4 and one optional IPv6) but should extend nicely to full prop186 support.
-
-
Switching from using milestones to keywords for sponsor deliverables. See #6365 (moved) for details.
Trac:
Keywords: N/A deleted, SponsorG20120930 added
Milestone: Sponsor G: September 30, 2012 to N/A mentioned in issue #4564 (moved)
mentioned in issue #4565 (moved)
mentioned in issue #4617 (moved)
mentioned in issue #5146 (moved)
mentioned in issue #5486 (moved)
mentioned in issue #5535 (moved)
mentioned in issue #6375 (moved)
moved to tpo/core/tor#4563 (closed)
mentioned in issue tpo/core/tor#4564 (closed)
mentioned in issue tpo/core/tor#6375 (closed)