Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-07-28T16:03:17Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24406Implement IPv6 ORPort reachability fallback2020-07-28T16:03:17ZteorImplement IPv6 ORPort reachability fallbackImplement the IPv6 ORPort reachability fallback from legacy/trac#24404.Implement the IPv6 ORPort reachability fallback from legacy/trac#24404.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24405Implement relay IPv6 extends with proposed protover2020-07-28T16:02:57ZteorImplement relay IPv6 extends with proposed protoverMake relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.)
Make these relays declare t...Make relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.)
Make these relays declare the protover from legacy/trac#24404.
Make them implement the IPv4/IPv6 Extend behviour from legacy/trac#24404.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24404Propose a relay protover that allows IPv6 extends2020-06-27T13:54:52ZteorPropose a relay protover that allows IPv6 extendsWrite a proposal for a relay protover, in which relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may ...Write a proposal for a relay protover, in which relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.)Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24403Propose and implement IPv6 ORPort reachability checks on relays2020-06-27T13:54:52ZteorPropose and implement IPv6 ORPort reachability checks on relaysThis is the top-level task for relay IPv6 ORPort reachability checks.
See:
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features#ReachabilityChecks
Check the child tickets for details.This is the top-level task for relay IPv6 ORPort reachability checks.
See:
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features#ReachabilityChecks
Check the child tickets for details.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24394add ipv6 dirauth address2020-06-27T13:54:52ZStefani Banerianadd ipv6 dirauth address
bastet added to dirauth in oct 2017 has ipv6 addr
2620:13:4000:6000::1000:118
per request of dirauth list message
bastet added to dirauth in oct 2017 has ipv6 addr
2620:13:4000:6000::1000:118
per request of dirauth list messageTor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24393Clients should check IPv4 and IPv6 subnets when choosing circuit paths2021-08-23T15:17:07ZteorClients should check IPv4 and IPv6 subnets when choosing circuit pathsCurrently, clients only check IPv4 subnets when choosing circuit paths. But they should probably also check IPv6 subnets as well.
Once legacy/trac#15518 is fixed, we can make them check both.Currently, clients only check IPv4 subnets when choosing circuit paths. But they should probably also check IPv6 subnets as well.
Once legacy/trac#15518 is fixed, we can make them check both.Tor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24322make IPv6-only clients bootstrap without needing config changes.2020-06-27T13:54:56Zdkgmake IPv6-only clients bootstrap without needing config changes.legacy/trac#17281 suggests that an IPv6-only client should be able to bootstrap by setting some flags in torrc. I've done:
```
ClientUseIPv4 0
ClientUseIPv6 1
```
But, most clients are not *always* IPv4-only or IPv6-only. In particul...legacy/trac#17281 suggests that an IPv6-only client should be able to bootstrap by setting some flags in torrc. I've done:
```
ClientUseIPv4 0
ClientUseIPv6 1
```
But, most clients are not *always* IPv4-only or IPv6-only. In particular, i tend to move my laptop between networks that have different properties (i'm writing this from a v6-only network).
I shouldn't have to fiddle with my torrc to make tor work. it should be able to auto-detect this situation and do the right thing automatically.https://gitlab.torproject.org/tpo/core/tor/-/issues/24193Make v3 single onion services parse and use IPv6 introduce link specifiers2020-06-27T13:55:01ZteorMake v3 single onion services parse and use IPv6 introduce link specifiersOnce legacy/trac#23577 is merged, we can make single onion services parse IPv6 addresses in introduce link specifiers. Then they can choose the address they want to use to connect to the rend point using their firewall settings.Once legacy/trac#23577 is merged, we can make single onion services parse IPv6 addresses in introduce link specifiers. Then they can choose the address they want to use to connect to the rend point using their firewall settings.Tor: 0.4.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24181v3 Onion Services: Put IPv6 and unrecognised link specifiers in onion service...2022-06-17T14:20:39Zteorv3 Onion Services: Put IPv6 and unrecognised link specifiers in onion service EXTEND cellsProp224 says:
```
The hidden service SHOULD NOT reject any LSTYPE fields which it
doesn't recognize; instead, it should use them verbatim in its EXTEND
request to the rendezvous point.
```
https://gitweb.torproject.org/torspec.git/tree/p...Prop224 says:
```
The hidden service SHOULD NOT reject any LSTYPE fields which it
doesn't recognize; instead, it should use them verbatim in its EXTEND
request to the rendezvous point.
```
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1689
We should either remove this from the spec, or we should:
* add a similar sentence for client descriptor lspecs
* put unrecognised lspecs in descriptors in client intro EXTEND requests
* put unrecognised lspecs in INTRODUCE cells in service rend EXTEND requestshttps://gitlab.torproject.org/tpo/core/tor/-/issues/24109Test IPv6-only clients using microdescriptors in make-test-network-all2020-06-27T13:55:06ZteorTest IPv6-only clients using microdescriptors in make-test-network-allNow that legacy/trac#21001 is implemented in chutney, we can test that IPv6-only tor clients can use microdescriptors.
IPv6-only clients using microdescs are supported by tor 0.3.0.4-alpha and later, so we can backport to 0.3.0 if we wa...Now that legacy/trac#21001 is implemented in chutney, we can test that IPv6-only tor clients can use microdescriptors.
IPv6-only clients using microdescs are supported by tor 0.3.0.4-alpha and later, so we can backport to 0.3.0 if we want to.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24006IPv6-only Tor2web has never actually connected to rend points over IPv62020-06-27T13:55:12ZteorIPv6-only Tor2web has never actually connected to rend points over IPv6This code should pass 1 to extend_info_from_node() when running Tor2web, and it should fall back to a 3-hop path if the node is NULL:
```
const node_t *node =
choose_good_exit_server(circ->base_.purpose, state->need_uptime,
...This code should pass 1 to extend_info_from_node() when running Tor2web, and it should fall back to a 3-hop path if the node is NULL:
```
const node_t *node =
choose_good_exit_server(circ->base_.purpose, state->need_uptime,
state->need_capacity, state->is_internal,
is_hs_v3_rp_circuit);
if (!node) {
log_warn(LD_CIRC,"Failed to choose an exit server");
return -1;
}
exit_ei = extend_info_from_node(node, 0);
if (BUG(exit_ei == NULL))
return -1;
```
I don't think we'll fix this, but I'm logging it for the record.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24000circuit_send_intermediate_onion_skin() and extend_cell_format() should check ...2020-07-28T14:20:42Zteorcircuit_send_intermediate_onion_skin() and extend_cell_format() should check for IPv6When circuit_send_intermediate_onion_skin() and extend_cell_format() handle tor_addr_t, they assume they are IPv4.
But in legacy/trac#23502, we almost wrote code that sent them an IPv6 address. In this case, they put 0.0.0.0 in the exte...When circuit_send_intermediate_onion_skin() and extend_cell_format() handle tor_addr_t, they assume they are IPv4.
But in legacy/trac#23502, we almost wrote code that sent them an IPv6 address. In this case, they put 0.0.0.0 in the extend cell, but they could issue a BUG() warning and refuse to send the cell instead.
Or they could send a proper IPv6 link specifier where the extend cell allows it.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23975Make node_get_pref_ipv6_orport() check addresses in the right order2022-06-17T18:39:55ZteorMake node_get_pref_ipv6_orport() check addresses in the right ordernode_get_pref_ipv6_orport() and node_get_prim_orport() check addresses in the following order:
* routerinfo / descriptor (modified by rewrite_bridge_address_for_node())
* routerstatus / consensus
* microdesc
Clients, bridge clients, an...node_get_pref_ipv6_orport() and node_get_prim_orport() check addresses in the following order:
* routerinfo / descriptor (modified by rewrite_bridge_address_for_node())
* routerstatus / consensus
* microdesc
Clients, bridge clients, and relays usually get the correct address from node_get_pref_ipv6_orport() and node_get_prim_orport(), whether they are using microdescriptors or not.
But there are a few cases when this breaks:
* bridge clients should only check routerinfo for configured bridges
* all clients and relays that use microdescs should never check full descriptors (and vice versa, except for the bridge case)
* all clients and relays that use full descriptors should ignore the IPv6 address in the descriptor
* all clients and relays that use microdescriptors should ignore the IPv6 address in the microdescriptor, when using a consensus method that puts IPv6 addresses in the microdesc consensus, otherwise they should use the microdescriptorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23898tor-spec: move IPv6 addresses from microdescs to microdesc consensus2020-06-27T13:55:15Zteortor-spec: move IPv6 addresses from microdescs to microdesc consensusMy torspec branch bug20916 documents the changes in legacy/trac#20916 and children. And it fixes legacy/trac#13043.My torspec branch bug20916 documents the changes in legacy/trac#20916 and children. And it fixes legacy/trac#13043.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23870Authorities: document what happens when relays have misconfigured IPv62021-07-22T16:22:27ZteorAuthorities: document what happens when relays have misconfigured IPv6~~~Otherwise, we lose useful relays when authorities set AuthDirHasIPv6Connectivity.~~~~~~Otherwise, we lose useful relays when authorities set AuthDirHasIPv6Connectivity.~~~Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23828Authorities: Remove IPv6 addresses from microdescriptors2020-06-27T13:55:19ZteorAuthorities: Remove IPv6 addresses from microdescriptorsWhen legacy/trac#23826 is locked in, we should remove IPv6 addresses from microdescs.When legacy/trac#23826 is locked in, we should remove IPv6 addresses from microdescs.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23827Clients/Relays: Use IPv6 Addresses from microdesc consensus2020-06-27T13:55:19ZteorClients/Relays: Use IPv6 Addresses from microdesc consensusClient/Relay Implementation for legacy/trac#20916.
We need to use the IPv6 addresses from consensuses with versions that implement legacy/trac#23826, and ignore microdesc IPv6 addresses.Client/Relay Implementation for legacy/trac#20916.
We need to use the IPv6 addresses from consensuses with versions that implement legacy/trac#23826, and ignore microdesc IPv6 addresses.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23826Authorities: Put Relay IPv6 addresses in the microdesc consensus2020-06-27T13:55:19ZteorAuthorities: Put Relay IPv6 addresses in the microdesc consensusAuthority Implementation for legacy/trac#20916Authority Implementation for legacy/trac#20916Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23824Make IPv6-only bridges work2022-06-24T14:24:45ZteorMake IPv6-only bridges workThis needs bridge guards (#7144 - so the bridge can connect via a dual-stack bridge guard to whatever guard the client has selected), and it needs IPv6 bridges to work in general (#4847).This needs bridge guards (#7144 - so the bridge can connect via a dual-stack bridge guard to whatever guard the client has selected), and it needs IPv6 bridges to work in general (#4847).https://gitlab.torproject.org/tpo/core/tor/-/issues/23820Make sure v3 single onion services and v3 onion service clients only send IPv...2020-06-27T13:55:20ZteorMake sure v3 single onion services and v3 onion service clients only send IPv4 addressesThis fixes the bug warning in legacy/trac#23493, and allows our users to migrate to IPv4 v3 single onion services.This fixes the bug warning in legacy/trac#23493, and allows our users to migrate to IPv4 v3 single onion services.Tor: 0.3.2.x-finalteorteor