Opened 19 months ago

Last modified 4 months ago

#21311 needs_information defect

Exits should resolve IPv6 addresses, regardless of IPv6Exit

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ipv6, 031-deferred-20170425, 033-triage-20180320, 033-removed-20180320
Cc: Actual Points: 0.1
Parent ID: #17811 Points: 1
Reviewer: Sponsor:

Description (last modified by teor)

That way, clients find out if the hostname they're trying to reach is IPv6-only, and can try an IPv6 exit next time.

Was: launch_resolve() should always resolve AAAA records, regardless of IPv6Exit

Child Tickets

TicketStatusOwnerSummaryComponent
#21346closedneelClients with NoIPv4Traffic should only choose IPv6-supporting ExitsCore Tor/Tor

Change History (18)

comment:1 Changed 19 months ago by arma

Summary: launch_one_resolve should always resolve AAAA records, regardless of IPv6Exitlaunch_resolve() should always resolve AAAA records, regardless of IPv6Exit

comment:2 Changed 19 months ago by arma

Right. Specifically, it's this code:

    if (get_options()->IPv6Exit)

The underlying bug is that exit relays are returning REASON_RESOLVEFAILED for resolve attempts to addresses like ipv6.google.com, which causes clients to get no hints about which exits might be able to reach that address successfully. If the exit relay would do the AAAA resolve, then it could usefully respond with REASON_EXITPOLICY, and include the v6 address in the end cell, and then clients could try again on a circuit that has explicit v6 exit support.

comment:3 Changed 19 months ago by arma

I think we shouldn't worry about whether exits meant to allow v6 lookups -- if you're an exit relay and you're willing to do v4 resolves, then I think it's a legit assumption that you're willing to do v6 resolves too.

One question that makes me pause though: are there dns resolvers out there that quietly drop AAAA resolve requests, which would cause surprising timeouts on exits while they wait for both resolve responses?

comment:4 Changed 19 months ago by arma

Is the fix just to remove the two "if IPv6Exit" checks from launch_resolve()?

Then we always launch both, and even if the dns resolver is somehow totally broken wrt v6 answers, cached_resolve_add_answer() would just dutifully note the failure of the v6 resolve, and things would all work?

comment:5 Changed 19 months ago by arma

(I thought briefly about whether we should only launch the v6 resolve attempt if the stream that triggers our resolve would be interested in a v6 answer. But since this cached resolve answer is meant to be used for multiple streams, meaning potentially multiple clients, and we probably don't want to introduce a side channel about what sort of request showed up last time for this address, that seems like a poor idea.)

comment:6 in reply to:  4 Changed 19 months ago by arma

Replying to arma:

Is the fix just to remove the two "if IPv6Exit" checks from launch_resolve()?

In that case we'd want to remove the "if IPv6Exit" from set_exitconn_info_from_resolve() too, so we're willing to return the answers we've got.

And also do something about the

bcell.flags &= ~BEGIN_FLAG_IPV6_PREFERRED;

line in connection_exit_begin_conn().

comment:7 Changed 19 months ago by teor

Actual Points: 0.1
Milestone: Tor: unspecifiedTor: 0.3.1.x-final

See my branch bug21311-v2 on github.
It requires #21310 to work.

Last edited 19 months ago by teor (previous) (diff)

comment:8 Changed 19 months ago by teor

Description: modified (diff)
Summary: launch_resolve() should always resolve AAAA records, regardless of IPv6ExitExits should resolve IPv6 addresses, regardless of IPv6Exit

comment:9 Changed 19 months ago by teor

Status: newneeds_review

comment:10 Changed 19 months ago by arma

Patch looks good! But it needs #21310 to get resolved before it can be the right patch.

Have you tested it?

comment:11 Changed 19 months ago by arma

Note that we're changing behavior from before, where before we would only consider launching the v6 resolve if creating the v4 resolve succeeded. Now we're launching the v6 resolve even if something went wrong while setting up the v4 resolve.

This choice is fine with me, but whoever made the original choice (was that Nick?) should see it and consider it too.

comment:12 in reply to:  10 Changed 19 months ago by teor

Status: needs_reviewneeds_information

Replying to arma:

Patch looks good! But it needs #21310 to get resolved before it can be the right patch.

Have you tested it?

That was my plan over the weekend, but it didn't end up happening.
I think it needs a tor network with 1 IPv6 exit and 7 IPv4 exits to match the current proportions in the public network. We should get a 100% success rate for ipv6.google.com with this patch, and ~12.5% - ~37.5% without it. (Clients on the public network should have a success rate of 3 * 12.5%, but they actually have a success rate around ~10%. I wonder if there are a lot of non-functional IPv6 exits out there?)

Putting in needs_information until it's been tested.

comment:13 Changed 16 months ago by nickm

Keywords: 031-deferred-20170425 added
Milestone: Tor: 0.3.1.x-finalTor: 0.3.2.x-final

Triage: batch-defer unowned items of priority Medium or lower to 0.3.2.

comment:14 Changed 14 months ago by teor

Parent ID: #17811

comment:15 Changed 11 months ago by nickm

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

comment:16 Changed 5 months ago by nickm

Keywords: 033-triage-20180320 added

Marking all tickets reached by current round of 033 triage.

comment:17 Changed 5 months ago by nickm

Keywords: 033-removed-20180320 added

Mark all not-already-included tickets as pending review for removal from 0.3.3 milestone.

comment:18 Changed 4 months ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: unspecified
Note: See TracTickets for help on using tickets.