Opened 7 years ago

Closed 4 years ago

#6027 closed project (duplicate)

Directory authorities on IPv6

Reported by: ln5 Owned by:
Priority: Medium Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ipv6, tor-auth, SponsorF20130315, 026-triaged-1, 026-deferrable, nickm-patch, 027-triaged-1-out, pre028-patch
Cc: nickm Actual Points:
Parent ID: #15228 Points: medium
Reviewer: Sponsor:

Description

Directory authorities don't know enough about IPv6. There are a lot
of issues here, two of which are mentioned in #4847:

  • init_keys()
  • dirserv_generate_networkstatus_vote_obj()

Child Tickets

Attachments (1)

screen-exchange (12.9 KB) - added by ln5 6 years ago.
info level logs from client on a system without an ipv4 address

Download all attachments as: .zip

Change History (42)

comment:1 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-final

comment:2 Changed 7 years ago by ln5

Summary: Directory authorities on IPv6Enhancement: Directory authorities on IPv6

Changing summary to reflect that this is not a bug per se.
(This should have been an "enhancement" rather than a "defect".)

comment:3 Changed 7 years ago by ln5

Summary: Enhancement: Directory authorities on IPv6Directory authorities on IPv6
Type: defectenhancement

But... but... there _is_ a way to change _type_ of a ticket. Duh!

comment:4 Changed 7 years ago by nickm

Keywords: tor-auth added

comment:5 Changed 7 years ago by nickm

Component: Tor Directory AuthorityTor

comment:6 Changed 7 years ago by karsten

Keywords: SponsorZ added
Type: enhancementproject

Grabbing this ticket for sponsor Z.

comment:7 in reply to:  description Changed 7 years ago by ln5

Replying to ln5:

Directory authorities don't know enough about IPv6. There are a lot
of issues here, two of which are mentioned in #4847:

  • init_keys()
  • dirserv_generate_networkstatus_vote_obj()
  • These data structures need to take multiple OR ports into account: trusted_dir_server_t, authority_cert_t and networkstatus_voter_info_t.
  • tools/tor-gencert.c needs fixing

comment:8 Changed 7 years ago by nickm

If we take my current favored approach to #572 , which involves implementing proposal 206, then we don't need to do this for authorities per se, though the code would be reusable.

comment:9 Changed 7 years ago by arma

Keywords: SponsorF20130315 added; SponsorZ removed

comment:10 Changed 6 years ago by nickm

Status: newneeds_review

I've thrown up a sketch implementation in branch "bug6027" in my public repository. I believe that's sufficient to allow users to configure IPv6 addr:orports for DirAuthority and FallbackDir lines, which can let users without IPv6 bootstrap.

I haven't been able to test this; it could use testing and review.

This hasn't made the deadline for 0.2.4 features; I think it's deferrable to 0.2.5.

comment:11 Changed 6 years ago by karsten

FWIW, from the sponsor F POV, I think it's fine to defer this to 0.2.5.

On the year 3 page you write that we need somebody to fill in the IPv6 addresses and that this is a coordination project. Can you elaborate on that? What should that person do, and how often?

comment:12 in reply to:  11 ; Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

Replying to karsten:

FWIW, from the sponsor F POV, I think it's fine to defer this to 0.2.5.

On the year 3 page you write that we need somebody to fill in the IPv6 addresses and that this is a coordination project. Can you elaborate on that? What should that person do, and how often?

Make sure that there are directory authorities with long-term fixed IPv6 addresses. List those IPv6 addresses in config.c, or tell me those addresses so that I can do so.

Alternatively, make sure that there are *some* directories with long-term fixed IPv6 addresses. Start figuring out how we want to ship that list. Maintain that list.

comment:13 in reply to:  12 Changed 6 years ago by karsten

Replying to nickm:

Make sure that there are directory authorities with long-term fixed IPv6 addresses. List those IPv6 addresses in config.c, or tell me those addresses so that I can do so.

I just asked authority operators. I'll collect addresses and let you know.

Alternatively, make sure that there are *some* directories with long-term fixed IPv6 addresses. Start figuring out how we want to ship that list. Maintain that list.

Okay. We could ask relay operators on tor-relays@, or I could write a simple script to parse apparently long-term fixed IPv6 addresses from consensuses. The latter is probably less work. But I guess this doesn't matter until we ship the first 0.2.5.x-alpha bundle. We can still run the script on archived consensuses then.

comment:14 Changed 6 years ago by nickm

So far we have:

tor.noreply.org has IPv6 address 2001:858:2:2:aabb:0:563b:1526
maatuska runs on 2001:67c:289c::9.

comment:15 Changed 6 years ago by nickm

Add:

Urras now has the following addresses:
[2607:ff58::d053:df22] a.k.a. [2607:ff58::208.83.223.34]
208.83.223.34

Or if you just want to remember one address:
[2607:ff58::208.83.223.34]

208.83.223.34 has an ORPort on 80
208.83.223.34 has an DirPort on 443
[2607:ff58::208.83.223.34] has an ORPort on 80

comment:16 Changed 6 years ago by karsten

I'm trying to test your bug6027 branch, with no luck so far. Here's what I did:

  • Set up an EC2 instance with outbound IPv6 connectivity and a firewall rule to drop all new outgoing IPv4 connections. curl -6 https://www.torproject.org/ works fine, and curl https://www.torproject.org/ doesn't do anything.
  • Added three directory authority IPv6 addresses to src/or/config.c:
diff --git a/src/or/config.c b/src/or/config.c
index 6ae96ad..448472c 100644
--- a/src/or/config.c
+++ b/src/or/config.c
@@ -782,6 +782,7 @@ add_default_trusted_dir_authorities(dirinfo_type_t type)
       "v3ident=D586D18309DED4CD6D57C18FDB97EFA96D330566 "
       "128.31.0.39:9131 9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31",
     "tor26 v1 orport=443 v3ident=14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 "
+      "ipv6=[2001:858:2:2:aabb:0:563b:1526]:443 "
       "86.59.21.38:80 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D",
     "dizum orport=443 v3ident=E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 "
       "194.109.206.212:80 7EA6 EAD6 FD83 083C 538F 4403 8BBF A077 587D D755",
@@ -797,9 +798,11 @@ add_default_trusted_dir_authorities(dirinfo_type_t type)
       "v3ident=585769C78764D58426B8B52B6651A5A71137189A "
       "193.23.244.244:80 7BE6 83E6 5D48 1413 21C5 ED92 F075 C553 64AC 7123",
     "urras orport=80 no-v2 v3ident=80550987E1D626E3EBA5E5E75A458DE0626D088C "
+      "ipv6=[2607:ff58::d053:df22]:80 "
       "208.83.223.34:443 0AD3 FA88 4D18 F89E EA2D 89C0 1937 9E0E 7FD9 4417",
     "maatuska orport=80 no-v2 "
       "v3ident=49015F787433103580E3B66A1707A00E60F2D15B "
+      "ipv6=[2001:67c:289c::9]:80 "
       "171.25.193.9:443 BD6A 8292 55CB 08E6 6FBE 7D37 4836 3586 E46B 3810",
     "Faravahar orport=443 no-v2 "
       "v3ident=EFCBE720AB3A82B99F9E953CD5BF50F7EEFC7B97 "
  • Added fallback dirs from #8374 to torrc. Also added ClientUseIPv6 and ClientPreferIPv6ORPort options that looked relevant here:
DataDirectory /home/ubuntu/client/data/
Log info file /home/ubuntu/client/data/info.log
Log info stdout
ClientUseIPv6 1
ClientPreferIPv6ORPort 1
FallbackDir 77.247.181.162:80 orport=443 id=253DFF1838A2B7782BE7735F74E50090D46CA1BC weight=72700 ipv6=[2a00:1768:1001:21:1:0:32a3:201a]:443
FallbackDir 171.25.193.20:80 orport=443 id=DD8BD7307017407FCC36F8D04A688F74A0774C02 weight=50600 ipv6=[2001:67c:289c::20]:443
FallbackDir 128.6.224.107:9030 orport=9001 id=D67B28212377617448A2AC192E11372AD951FD13 weight=18000 ipv6=[2620:0:d60:401::2]:9001
FallbackDir 82.94.251.204:80 orport=443 id=9B02AA745B22B3FAB37C84B5E695623DD107A74D weight=15100 ipv6=[2001:888:2133:0:82:94:251:204]:443
FallbackDir 188.40.51.232:80 orport=443 id=CAF7986ECF1FBF903E68155531F8930C9ECC3A0D weight=13900 ipv6=[2a01:4f8:100:24e1:ffff::1]:443
FallbackDir 193.11.164.242:9030 orport=9001 id=980D326017CEF4CBBF4089FBABE767DC83D059AF weight=13800 ipv6=[2001:6b0:7:125::242]:9001
FallbackDir 171.25.193.21:80 orport=443 id=A10C4F666D27364036B562823E5830BC448E046A weight=13300 ipv6=[2001:67c:289c::21]:443
FallbackDir 149.20.52.51:9030 orport=5251 id=09C0E63BD41FE86A31CB3FB27C4D54F7D49A1F7C weight=12500 ipv6=[2001:4f8:3:2e::51]:5251
FallbackDir 91.121.245.171:80 orport=443 id=85670C66276B84F956FC9F2407DAFF9774104522 weight=2550 ipv6=[2001:41d0:2:90a8::3]:443
FallbackDir 78.47.134.6:3480 orport=3451 id=26220AEA188B8D0E47BB541E1A616EB3AD70295F weight=2360 ipv6=[2a01:4f8:d13:1602::2012]:3451

However, when starting the tor client it always attempts to download the consensus from a fallback directory (this part works), but using its IPv4 address:

May 14 19:17:38.000 [notice] Bootstrapped 5%: Connecting to directory server.
May 14 19:17:38.000 [info] connection_ap_make_link(): ... application connection created and linked.
May 14 19:17:38.000 [info] directory_send_command(): Downloading consensus from 171.25.193.20:443 using /tor/status-vote/current/consensus-microdesc/14C131+27B6B5+49015F+585769+805509+D586D1+E8A9C4+ED03BB+EFCBE7.z
May 14 19:17:38.000 [info] or_state_save(): Saved state to "/home/ubuntu/client/data//state"
May 14 19:17:38.000 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
May 14 19:17:38.000 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
May 14 19:19:38.000 [info] connection_ap_expire_beginning(): Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit)

How would I tell my tor client that I don't have any outgoing IPv4 connectivity and that it should instead use only IPv6 addresses?

comment:17 Changed 6 years ago by karsten

nickm, ln5, any ideas?

Changed 6 years ago by ln5

Attachment: screen-exchange added

info level logs from client on a system without an ipv4 address

comment:18 Changed 6 years ago by ln5

Replying to karsten:

How would I tell my tor client that I don't have any outgoing IPv4 connectivity and that it should instead use only IPv6 addresses?

I am not aware of any way of doing that.

For reference, I did the same as you on a host without IPv4 connectivity. Attaching info log from that run.

comment:19 Changed 6 years ago by karsten

Okay, looks similar to my log; your connection attempts fail immediately with "Network is unreachable", whereas mine time out after two minutes. Thanks for testing!

In the expected outcome of this deliverable, we said: "The expected output of this deliverable is a Tor branch that includes a set of initial directory caches with IPv6 addresses for use by clients which cannot talk to IPv4 relays, and code so that these clients correctly restrict their direct connections to nodes with IPv6 addresses once they find out they cannot bootstrap via IPv4."

So, we either need some way to tell tor that it only has outgoing IPv6 connectivity and no IPv4 connectivity, or for tor to find out itself.

comment:20 Changed 6 years ago by karsten

Cc: nickm added

nickm, any ideas?

comment:21 Changed 6 years ago by ln5

FWIW, we've identified the need for a "fall back to alternative or
port" mechanism in #6772.

comment:22 Changed 6 years ago by nickm

Can ReachableAddresses be used to tell Tor that only IPv6 addresses are reachable?

comment:23 in reply to:  22 ; Changed 6 years ago by ln5

Replying to nickm:

Can ReachableAddresses be used to tell Tor that only IPv6 addresses are reachable?

Interesting idea. I can't make it work right away:

  • 'reject *:*,accept6 *:*' results in "directory_pick_generic_dirserver(): No router found for consensus network-status fetch; falling back to dirserver list."
  • 'accept6 *:*,reject *:*' makes the client try IPv4 addresses

Haven't looked into any details yet but from a quick glance it seems like router_pick_directory_server_impl() needs some IPv6 knowledge.

comment:24 in reply to:  23 ; Changed 6 years ago by arma

Replying to ln5:

  • 'accept6 *:*,reject *:*' makes the client try IPv4 addresses

I don't have much context here, but that sounds like a bug.

comment:25 in reply to:  24 Changed 6 years ago by ln5

Replying to arma:

Replying to ln5:

  • 'accept6 *:*,reject *:*' makes the client try IPv4 addresses

I don't have much context here, but that sounds like a bug.

Hmm, does the following mean that we do try to use the internets of IPv4 routers to reach a dirserver?

Jun 04 18:24:38.000 [info] connection_ap_make_link(): Making internal direct tunnel to 77.247.181.162:443 ...

The "internal tunnel" part of it indicates no, while the next line

Jun 04 18:24:38.000 [warn] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 1; recommendation warn)

indicates something else. I will try to read code tomorrow if no one beats me to it.

comment:26 Changed 6 years ago by nickm

Any leads here? I don't actually have an IPv6 connection to test this out with.

comment:27 Changed 6 years ago by nickm

BTW, has anybody actually reviewed this code, or is everybody testing it without reading it?

comment:28 Changed 6 years ago by nickm

The branch to look at is now "bug6027_rebased". No other changes made.

comment:29 in reply to:  27 Changed 6 years ago by ln5

Replying to nickm:

BTW, has anybody actually reviewed this code, or is everybody testing it without reading it?

The changes in bug6027_rebased looks correct to me. I think that we're stumbling over lack of IPv6 support in other parts of tor.

I have suggestions for function documentation improvements in commit 92f5daf3 of branch bug6027_rebased in my public repo.

comment:30 Changed 6 years ago by ln5

I think that onion_extend_cpath() is bad at picking IPv6 first hops
when a client wants a one-hop circuit for dir tunnel. The test for
"picking last node" is true in the case where state->desired_path_len
is 1 which means that we'll never call extend_info_from_node() for
finding out where to download a consensus.

This is one of several things going wrong when trying to bootstrap
without IPv4.

Also, there seems to be something wrong when clients use microdescs
w.r.t. IPv6 addresses in routerlist -- there are no IPv6 addresses
present. This needs further investigation, separate from this
enhancement.

comment:31 Changed 5 years ago by andrea

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final
Status: needs_reviewneeds_revision

Deferring to 0.2.6 and putting in needs_revision per triage discussion with nickm.

comment:32 Changed 5 years ago by nickm

Keywords: 026-triaged-1 026-deferrable added

comment:33 Changed 5 years ago by nickm

Keywords: nickm-patch added

Add nickm-patch keyword to needs_revision tickets in 0.2.6 where (I think) I wrote the patch, so I know which ones are my responsibility to revise.

comment:34 Changed 4 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final

comment:35 Changed 4 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:36 Changed 4 years ago by teor

Parent ID: #15228

Make #15228 the parent to collect all fallback tickets in one place

comment:37 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:38 Changed 4 years ago by nickm

Points: medium

comment:39 Changed 4 years ago by nickm

Keywords: pre028-patch added

comment:40 Changed 4 years ago by arma

Severity: Normal

There's a lot of comments here, and don't change your great plan just because I'm writing this, but: if you don't have a great plan, maybe we should close this one as wont-fix and instead focus on getting the fallback directories to be able to do ipv6, and then on shipping with a set of ipv6 addresses in the fallback directories? And that list could include the ipv6 addresses of dir auths if they want.

comment:41 Changed 4 years ago by teor

Resolution: duplicate
Status: needs_revisionclosed

I agree. I think other tickets cover this ticket, see #15235 for details.

(It's also worth noting that the branch nickm/bug6027_rebased can't possibly merge cleanly into master, as FallbackDirs on IPv6 has already been implemented. I'll pick anything useful out of it in #17327.)

Note: See TracTickets for help on using tickets.