Distribute IPv6 bridges through bridges.torproject.org

added actualpoints::1 anti-censorship-roadmap-october component::circumvention/bridgedb owner::phw parent::24264 points::3 priority::high resolution::fixed reviewer::cohosh severity::normal sponsor::30-must status::closed type::defect labels

As of 19 December 2018, there are still no IPv6 bridges on bridges.torproject.org with PT none or obfs4.

Trac:
Parent: N/A to #28888 (moved)

We should check this ticket when Serge sets AuthDirHasIPv6Connectivity 1.

Trac:
Parent: #28888 (moved) to #24264 (moved)

Trac:
Username: darkspirit
Cc: N/A to jan@ikenmeyer.eu

INFO      L81:request.withIPversion()  HTTPS request for bridges with IPv6 addresses.
INFO     L146:request.withPluggableT() HTTPS request for transport type: 'obfs4'
DEBUG     L78:geo.getCountryCode()     Looked up country code: CH                                                                                                                                                  
INFO     L125:request.withoutBlockIn() HTTPS client's bridges also shouldn't be blocked in their GeoIP country code: CH
INFO     L244:bridgerequest.generate() Adding a filter to HTTPSBridgeRequest for ${exit_node_address} for IPv6 obfs4 bridges not blocked in ch...
INFO     L300:distributor.getBridges() Attempting to get bridges for ${exit_node_address}...
DEBUG    L159:distributor.getSubnet()  Client IP was within area: ${exit_node_ip_netblock}
DEBUG     L44:filters.bySubring()      Creating a filter for assigning bridges to subhashring 1-of-3...
DEBUG    L325:distributor.getBridges() Client request within time interval: 1545318000
DEBUG    L326:distributor.getBridges() Assigned client to subhashring 1/3 
DEBUG    L327:distributor.getBridges() Assigned client to subhashring position: ${hash}
DEBUG    L328:distributor.getBridges() Total bridges: 1000
DEBUG    L329:distributor.getBridges() Bridge filters: bySubring1of3 byTransportNotBlockedIn(obfs4,ch,6)
DEBUG    L333:distributor.getBridges() Cache hit frozenset([<function bySubring1of3 at 0x7f50c6784c80>, <function byTransportNotBlockedIn(obfs4,ch,6) at 0x7f50bb0817d0>])
DEBUG    L269:distribute.bridgesPerR() Returning 1 bridges from ring of len: 0
DEBUG    L276:Bridges.filterDistinct() Got 0 possible bridges to filter

Where BridgeDB thinks the source address of the request was in CH.

Serge has enabled IPv6 reachability testing (#24264 (moved)) and IPv6 bridge addresses appear in metrics (#28888 (moved)).

But bridges.torproject.org still does not give out IPv6 bridges.

Is the IPv6 GeoIP missing? Should we wait a few more days?

Ok. So we can assume the issue is on bridges. and not the bridge dir auth at this point.

I consistently see ~50 IPv6 connections to what I assume are IPv6 bridges on Serge at any moment.

Trac:
Status: new to assigned
Sponsor: N/A to Sponsor19
Owner: isis to N/A
Points: N/A to 3
Priority: Medium to High

Replying to gman999:

Ok. So we can assume the issue is on bridges. and not the bridge dir auth at this point.

I consistently see ~50 IPv6 connections to what I assume are IPv6 bridges on Serge at any moment.

Relays don't extend via IPv6, so any outbound IPv6 connections you see on an authority are reachability tests. (We'll need better reporting of IPv6 once we do IPv6 extends, I added #29113 (moved) so we remember to add them to the heartbeat.)

Any inbound IPv6 connections you see are from clients using your authority as an entry. (Which should be rare.)

Trac:
Keywords: N/A deleted, anti-censorship-roadmap-2019 added

Moving from Sponsor 19 to Sponsor 30.

Trac:
Sponsor: Sponsor19 to Sponsor30-must

Trac:
Keywords: anti-censorship-roadmap-2019 deleted, anti-censorship-roadmap added

Trac:
Keywords: anti-censorship-roadmap deleted, anti-censorship-roadmap-october added

Trac:
Owner: N/A to phw

Yes, this is a problem in BridgeDB. I fixed the distribution of vanilla IPv6 bridges in my fix/14065 branch.

Note that this patch doesn't fix the distribution of IPv6 PT bridges. The issue is that bridges currently cannot advertise both an IPv4 and an IPv6 address for pluggable transports (see #11211 (moved)), which is why a bridge's transport line always contains an IPv4 address.

In theory, we could work around this issue by assuming that a PT bridge that has an IPv6 OR address also has an IPv6 PT address. This assumption may not always hold and BridgeDB is currently unable to do active scans to confirm if this is the case for a given bridge.

Trac:
Status: assigned to needs_review
Reviewer: N/A to sysrqb

Trac:
Summary: Distribute IPv6 bridges though bridges.torproject.org to Distribute IPv6 bridges through bridges.torproject.org

Trac:
Reviewer: sysrqb to cohosh

Looks good to me!

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Trac:
Resolution: fixed to N/A
Status: closed to reopened

Distribute IPv6 bridges through bridges.torproject.org

Child items 0

Activity