Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#4563 closed project (implemented)

Enable clients to talk to public bridges via IPv6

Reported by: karsten Owned by: ln5
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: SponsorG20120930 ipv6 tor-client
Cc: nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

This ticket is a deliverable for June 30, 2012 for sponsor G.

Child Tickets

TicketStatusOwnerSummaryComponent
#4297closedaagbsnTeach bridgedb how to handle descriptors with IPv6 addressesObfuscation/BridgeDB
#5146closedln5Bridges include or-address [::]:$port in their server descriptorCore Tor/Tor
#5486closedln5Add IPv6 support to bridge authoritiesCore Tor/Tor
#5533closedln5Bridge reachability over IPv6Core Tor/Tor
#5534closedln5Make bridge authorities add "a" lines to router status entriesCore Tor/Tor

Change History (14)

comment:1 Changed 7 years ago by karsten

Owner: karsten deleted
Status: newassigned

We don't have a person to lead this deliverable yet.

comment:2 Changed 7 years ago by karsten

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.

comment:3 Changed 7 years ago by karsten

Cc: ln5 removed
Milestone: Sponsor G: June 30, 2012Sponsor G: March 31, 2012
Owner: set to ln5

Moving this ticket from the June to the March milestone and making Linus the ticket owner after talking to him.

comment:4 in reply to:  2 ; Changed 7 years ago by 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?

comment:5 in reply to:  4 Changed 7 years ago by nickm

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.

comment:6 Changed 7 years ago by 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).

comment:7 Changed 7 years ago by karsten

Milestone: Sponsor G: March 31, 2012Sponsor G: June 30, 2012

Re-assigning to June milestone as it was originally planned.

comment:8 in reply to:  6 Changed 7 years ago by ln5

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:

  1. 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).
  1. Include OR ports in the routerstatus_t of a relay if
!haveIPv6Connectivity
node_t->last_reachable6 >= now-REACHABLE_TIMEOUT
  1. 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.

comment:9 Changed 7 years ago by karsten

Milestone: Sponsor G: June 30, 2012Sponsor G: September 30, 2012

Moving to the September milestone, because did not finish everything by end of June.

comment:10 Changed 7 years ago by karsten

Keywords: SponsorG20120930 added
Milestone: Sponsor G: September 30, 2012

Switching from using milestones to keywords for sponsor deliverables. See #6365 for details.

comment:11 Changed 7 years ago by ln5

Keywords: ipv6 added

comment:12 Changed 7 years ago by nickm

Resolution: implemented
Status: assignedclosed

All subtickets are completed. This feature is implemented.

comment:13 Changed 6 years ago by nickm

Keywords: tor-client added

comment:14 Changed 6 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.