Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-10-22T15:12:33Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33233Prop 312: 3.2.1. Make the Address torrc Option Support IPv6 Literals2020-10-22T15:12:33ZteorProp 312: 3.2.1. Make the Address torrc Option Support IPv6 LiteralsWe can work on this ticket now, but we should do the code movement in
legacy/trac#33789 first.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 literal case:
1. Explicit ...We can work on this ticket now, but we should do the code movement in
legacy/trac#33789 first.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 literal case:
1. Explicit IP addresses:
* allow the option to be specified up to two times,
* use the IPv4 address for IPv4,
* use the IPv6 address for IPv6.
Configuring two addresses in the same address family is a config error.
2. Hostnames / DNS names:
* allow the option to be specified up to two times,
* look up the configured name,
* use the first IPv4 and IPv6 address returned by the resolver, and
Resolving multiple addresses in the same address family is not a
runtime error, but only the first address from each family will be
used.
It is an error to configure an Address option with a private IPv4 or IPv6
address. (If tor is configured with a custom set of directory authorities, private addresses should be allowed, with a notice-level log.)
See proposal 312, section 3.2.1, case 1:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n252
As soon as we implement this ticket, we should implement legacy/trac#33246 to automatically open an IPv6 ORPort based on the Address config. (Or any discovered addresses.)
Then we should test the different IPv4/IPv6 configs listed in legacy/trac#33235.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33227Prop 311: 5.1. Update Tor Spec Relay Subprotocols2020-06-27T13:48:18ZteorProp 311: 5.1. Update Tor Spec Relay SubprotocolsWe propose the following changes to the [Tor Specification], once this
proposal is implemented.
Adding a new Relay subprotocol version lets testing relays identify other
relays that support IPv6 extends. It also allows us to eventually ...We propose the following changes to the [Tor Specification], once this
proposal is implemented.
Adding a new Relay subprotocol version lets testing relays identify other
relays that support IPv6 extends. It also allows us to eventually recommend
or require support for IPv6 extends on all relays.
For the draft text, see proposal 311, section 5.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n608Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33226Prop 311: 5. Declare Support for Subprotocol Version "Relay=3"2020-06-27T13:48:19ZteorProp 311: 5. Declare Support for Subprotocol Version "Relay=3"This ticket depends on relay IPv6 extends in legacy/trac#33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this propo...This ticket depends on relay IPv6 extends in legacy/trac#33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this proposal.
See proposal 311, section 5:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n601Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33225Prop 311: 4.4.1. Extend IPv6 From All Supported Second-Last Hops2022-06-17T18:01:44ZteorProp 311: 4.4.1. Extend IPv6 From All Supported Second-Last HopsThis is an optional change.
This change has a zero points estimate, because I think it is the fastest way of implementing legacy/trac#33222. (The alternative design requires creating different circuit types for IPv4 and IPv6 reachabilit...This is an optional change.
This change has a zero points estimate, because I think it is the fastest way of implementing legacy/trac#33222. (The alternative design requires creating different circuit types for IPv4 and IPv6 reachability checks.)
4.4.1. Extend IPv6 From All Supported Second-Last Hops
The testing relay (or bridge) puts both IPv4 and IPv6 ORPorts in its final
extend cell, and the receiving ORPort is selected at random by the
extending relay (see sections 3.2.1 and 4.2). Therefore, approximately half
of IPv6 ORPort reachability circuits will actually end up confirming IPv4
ORPort reachability.
We propose this optional change, to improve the rate of IPv6 ORPort
reachability checks:
If the second-last hop of an IPv4 ORPort reachability circuit supports IPv6
extends, testing relays may put the IPv4 and IPv6 ORPorts in the extend
cell for the final extend.
As the number of relays that support IPv6 extends increases, this change
will increase the number of IPv6 reachability confirmations. In the ideal
case, where the entire network supports IPv4 and IPv6 extends, IPv4 and IPv6
ORPort reachability checks would require a similar number of circuits.
See proposal 311, section 4.4.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n439https://gitlab.torproject.org/tpo/core/tor/-/issues/33224Prop 311: 4.3.2. Add AssumeReachableIPv6 Option and Consensus Parameter2020-06-27T13:48:19ZteorProp 311: 4.3.2. Add AssumeReachableIPv6 Option and Consensus ParameterWe add an AssumeReachableIPv6 torrc option and consensus parameter.
If IPv6 ORPort checks have bugs that impact the health of the network,
they can be disabled by setting AssumeReachableIPv6=1 in the consensus
parameters.
If IPv6 ORPor...We add an AssumeReachableIPv6 torrc option and consensus parameter.
If IPv6 ORPort checks have bugs that impact the health of the network,
they can be disabled by setting AssumeReachableIPv6=1 in the consensus
parameters.
If IPv6 ORPort checks have bugs that impact a particular relay (or bridge),
they can be disabled by setting "AssumeReachableIPv6 1" in the relay's
torrc.
This option disables IPv6 ORPort reachability checks, so relays publish
their descriptors if their IPv4 ORPort reachability checks succeed.
(Unlike AssumeReachable, AssumeReachableIPv6 has no effect on the existing
dirauth IPv6 reachability checks, which connect directly to relay ORPorts.)
The default for the torrc option is "auto", which checks the consensus
parameter. If the consensus parameter is not set, the default is "0".
"AssumeReachable 1" overrides all values of "AssumeReachableIPv6",
disabling both IPv4 and IPv6 ORPort reachability checks. Tor should warn if
AssumeReachable is 1, but AssumeReachableIPv6 is 0. (On directory
authorities, "AssumeReachable 1" also disables dirauth IPv4 and IPv6
reachability checks, which connect directly to relay ORPorts.
AssumeReachableIPv6 does not disable directory authority to relay IPv6
checks.)
See proposal 311, section 4.3.2:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n403Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33223Prop 311: 4.3.1. Don't Publish Descriptor if IPv6 ORPort is Unreachable2020-06-30T15:08:08ZteorProp 311: 4.3.1. Don't Publish Descriptor if IPv6 ORPort is UnreachableThis ticket depends on the protocol version ticket legacy/trac#33226.
Since it stops relays publishing their descriptors, it needs to be
tested on the public tor network, see legacy/trac#33229 and legacy/trac#33230.
If IPv6 reachabilit...This ticket depends on the protocol version ticket legacy/trac#33226.
Since it stops relays publishing their descriptors, it needs to be
tested on the public tor network, see legacy/trac#33229 and legacy/trac#33230.
If IPv6 reachability checks fail, relays (and bridges) should refuse to
publish their descriptors, if:
* enough existing relays support IPv6 extends, and
* the IPv6 address was explicitly configured by the operator
(rather than guessed using [Proposal 312: Relay Auto IPv6 Address]).
Directory authorities may perform reachability checks, and warn if those
checks fail. But they always publish their descriptors.
We set a threshold of consensus relays for reliable IPv6 ORPort checks:
* at least 30 relays, and
* at least 1% of the total consensus weight,
must support IPv6 extends.
We chose these parameters so that the number of relays is triple the
number of directory authorities, and the consensus weight is high enough
to support occasional reachability circuits.
In small networks with:
* less than 2000 relays, or
* a total consensus weight of zero,
the threshold should be the minimum tor network size to test reachability:
* at least 2 relays, excluding this relay.
(Note: we may increase this threshold to 3 or 4 relays if we discover a
higher minimum during testing.)
If the current consensus satisfies this threshold, testing relays (and
bridges, but not directory authorities) that fail IPv6 ORPort reachability
checks should refuse to publish their descriptors.
To ensure an accurate threshold, testing relays should exclude:
* the testing relay itself, and
* relays that they will not use in testing circuits,
from the:
* relay count, and
* the numerator of the threshold percentage.
Typically, relays will be excluded if they are in the testing relay's:
* family,
* IPv4 address /16 network,
* IPv6 address /32 network (a requirement as of Tor 0.4.0.1-alpha),
unless EnforceDistinctSubnets is 0.
As a useful side-effect, these different thresholds for each relay family
will reduce the likelihood of the network flapping around the threshold.
If flapping has an impact on the network health, directory authorities
should set the AssumeIPv6Reachable consensus parameter. (See the next
section.)
See proposal 311, section 4.3.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n351Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33222Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests2020-10-22T15:12:33ZteorProp 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests4.2. Checking IPv6 ORPort Reachability
We propose that testing relays (and bridges) select some IPv6 extend-capable
relays for their reachability circuits, and include their own IPv4 and IPv6
ORPorts in the final extend cells on those c...4.2. Checking IPv6 ORPort Reachability
We propose that testing relays (and bridges) select some IPv6 extend-capable
relays for their reachability circuits, and include their own IPv4 and IPv6
ORPorts in the final extend cells on those circuits.
The final extending relay will extend to the testing relay:
* using an existing authenticated connection to the testing relay
(which may be over IPv4 or IPv6), or
* over a new connection via the IPv4 or IPv6 ORPort in the extend cell.
The testing relay will confirm that test circuits can extend to both its
IPv4 and IPv6 ORPorts.
4.2.1. Selecting the Final Extending Relay
IPv6 ORPort reachability checks require an IPv6 extend-capable relay as
the second-last hop of reachability circuits. (The testing relay is the
last hop.)
IPv6-extend capable relays must have:
* Relay subprotocol version 3 (or later), and
* an IPv6 ORPort.
(See section 5.1 for the definition of Relay subprotocol version 3.)
The other relays in the path do not require any particular protocol
versions.
4.2.2. Extending from the Second-Last Hop
IPv6 ORPort reachability circuits should put the IPv4 and IPv6 ORPorts in
the extend cell for the final extend in reachability circuits.
Supplying both ORPorts makes these extend cells indistinguishable from
future client extend cells.
If reachability succeeds, the testing relay (or bridge) will accept the
final extend on one of its ORPorts, selected at random by the extending
relay (see section 3.2.1).
4.2.3. Separate IPv4 and IPv6 Reachability Flags
Testing relays (and bridges) will record reachability separately for IPv4
and IPv6 ORPorts, based on the ORPort that the test circuit was received on.
Here is a reliable way to do reachability self-tests for each ORPort:
1. Check for create cells on inbound ORPort connections from other relays
Check for a cell on any IPv4 and any IPv6 ORPort. (We can't know which listener(s) correspond to the advertised ORPorts, particularly when using port forwarding.) Make sure the cell was received on an inbound OR connection, that is authenticated to another relay.
2. Check for created cells from testing circuits on outbound OR connections
Check for a returned created cell on our IPv4 and IPv6 self-test circuits. Make sure those circuits were on outbound OR connections.
By combining these tests, we confirm that we can:
* reach our own ORPorts with testing circuits
* send and receive cells via inbound OR connections from other relays to our own ORPorts
* send and receive cells via outbound OR connections to other relays' ORPorts
This isn't a perfect test, there are a few false positives:
* relays with multiple IPv4 or IPv6 ORPorts, where only some ports are reachable:
* (this configuration is uncommon, but multiple ORPorts are supported)
* the final extend cell contains the advertised IPv6 address of the self-testing relay
* if the extending relay already has a connection to an old but working ORPort, it may use that connection instead
* so these tests can pass, even when the advertised ORPort is unreachable
* relays whose keys have been copied from another relay in the consensus, for similar reasons
* this configuration is rare and unsupported
From proposal 311, section 4.2:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n283teorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33221Prop 311: 4. Ensure Relay and Bridge IPv6 ORPorts are Reachable2020-07-28T15:01:44ZteorProp 311: 4. Ensure Relay and Bridge IPv6 ORPorts are ReachableThis is a parent ticket.
We propose that relays (and bridges) check their own IPv6 ORPort
reachability.
To check IPv6 ORPort reachability, relays (and bridges) extend circuits via
other relays (but not other bridges), and back to their...This is a parent ticket.
We propose that relays (and bridges) check their own IPv6 ORPort
reachability.
To check IPv6 ORPort reachability, relays (and bridges) extend circuits via
other relays (but not other bridges), and back to their own IPv6 ORPort.
If IPv6 reachability checks fail, relays (and bridges) should refuse to
publish their descriptors, if they believe IPv6 reachability checks are
reliable, and their IPv6 address was explicitly configured. (See
[Proposal 312: Relay Auto IPv6 Address] for the ways relays can guess their
IPv6 addresses.)
Directory authorities always publish their descriptors.
From Proposal 311, section 4:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n246
Parent:
* #33048 Propose and implement IPv6 orport reachability checks on relays
Children:
* [ ] #33860 finish test_onionskin_answer()
* [x] #33223 Don't publish descriptor if ipv6 orport is unreachable
* [x] #33224 Add AssumeReachableIPv6 option and consensus parameter
* [ ] #33225 Extend ipv6 from all supported second-last hops
* [ ] #34412 Additional unit tests for functions related to ipv6 self-test
* [x] #34064 Add an AssumeReachable consensus parameter
* [x] #34065 Make routerset_contains_router support ipv6
* [x] #34067 Separate Tor's ipv4 and ipv6 orport reachability flags
* [x] #34068 Decide how to handle control port events for ipv6 reachability self-tests
* [x] #34069 Allow extend_info to contain both ipv4 and ipv6 orport
* [x] #34200 Refactor tor's circuit path node selection checksNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33220Prop 311: 3. Allow Relay IPv6 Extends2020-07-21T13:33:54ZteorProp 311: 3. Allow Relay IPv6 ExtendsRelays may make a new connection over IPv6 when:
* they have an IPv6 ORPort,
* there is no existing authenticated connection to the requested relay, and
* the extend cell contains an IPv6 ORPort.
If these conditions are satisfied,...Relays may make a new connection over IPv6 when:
* they have an IPv6 ORPort,
* there is no existing authenticated connection to the requested relay, and
* the extend cell contains an IPv6 ORPort.
If these conditions are satisfied, and the extend cell also contains an
IPv4 ORPort, we propose that the relay choose between an IPv4 and an IPv6
connection at random.
If the extend cell does not contain an IPv4 ORPort, we propose that the
relay connects over IPv6. (Relays should support IPv6-only extend cells,
even though they are not used to test relay reachability in this proposal.)
A successful IPv6 connection also requires that:
* the requested relay has an IPv6 ORPort.
But extending relays must not check the consensus for other relays' IPv6
information. Consensuses may be out of date, particularly when relays are
doing reachability checks for new IPv6 ORPorts.
From proposal 311, section 3:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n112Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33195Require IPv6 tests in Travis CI2020-06-27T13:48:21ZteorRequire IPv6 tests in Travis CIWhile we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas th...While we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas that I can make fast_finish.
I think our Rust build might be a good candidate for fast_finish, we haven't changed that code much in about a year. But I should check with the team before making this change.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33159Write a proposal for monitoring IPv62020-06-27T13:48:22ZteorWrite a proposal for monitoring IPv6For sponsor 55, I need to write a proposal that covers these objectives:
* O1.4 - Measure the number of Tor relays that support IPv6 reachability checks (legacy/trac#33051)
* O1.5 - Measure the number of connections, and consumed bandwid...For sponsor 55, I need to write a proposal that covers these objectives:
* O1.4 - Measure the number of Tor relays that support IPv6 reachability checks (legacy/trac#33051)
* O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6 (legacy/trac#33052)
My current thinking is that:
* tor should log the number and consensus weight of relays that support IPv6 reachability checks, because we will need those numbers during testing
* these numbers are available in the consensus
Here's what the proposal requires:
* calculate relay IPv6 reachability numbers a few times during the project (we may as well use the tor logs)
* collect IPv6 connection and bandwidth statistics on tor relays
* calculate the IPv6 connection and bandwidth amounts a few times during the project
Here are some other useful things we might do:
* split the collected IPv6 statistics by client/relay
* calculate the guard-but-not-exit relays that support IPv6 client connections
* log IPv6 statistics in tor's heartbeat logs (we can't use these logs for our project reports, because they only show the local relay's statistics)
* calculate IPv6 reachability relay count and consensus weight on consensus-health
* add a pseudo-flag for relay IPv6 reachability support in Relay Search
* add metrics graphs that shows our progress on
* IPv6 reachability
* client IPv6 support on relays
* IPv6 connections and bandwidth
We definitely won't have time to do all of these optional things, so we should priorise, once the essential work is done.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33091Remove redundant checks in ip_address_changed()2021-09-16T14:22:17ZteorRemove redundant checks in ip_address_changed()ip_address_changed() does a separate exit policy check, but all relays need to refresh their descriptors when their address changes.ip_address_changed() does a separate exit policy check, but all relays need to refresh their descriptors when their address changes.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33073Write a proposal for Tor Relays to Automatically Find their IPv6 Address2020-06-27T13:48:25ZteorWrite a proposal for Tor Relays to Automatically Find their IPv6 AddressFor Sponsor 55, I need to write a proposal for IPv6 address detection on relays.For Sponsor 55, I need to write a proposal for IPv6 address detection on relays.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33056Tor relays fail to understand /etc/resolv.conf ipv6 lines with % in them2020-06-27T13:48:26ZRoger DingledineTor relays fail to understand /etc/resolv.conf ipv6 lines with % in themWe had a relay operator on irc just now who has this line in their /etc/resolv.conf:
```
nameserver fe80::7e2ebdff:fe99:4cb9%enp2s0
```
Apparently this is a totally normal thing: the % indicates a link local name server.
Two more hints...We had a relay operator on irc just now who has this line in their /etc/resolv.conf:
```
nameserver fe80::7e2ebdff:fe99:4cb9%enp2s0
```
Apparently this is a totally normal thing: the % indicates a link local name server.
Two more hints that % is a standard thing:
* https://bugs.launchpad.net/ubuntu/+source/wide-dhcpv6/+bug/1620221 "The link local name servers should be suffixed with the scope, e.g. "%eth0"."
* https://tools.ietf.org/html/rfc4007#section-11 "to specify an IPv6 non-global address without ambiguity, an intended scope zone should be specified as well."
Tor is unable to handle this % syntax in a resolv.conf line:
```
Jan 25 17:03:00.171 [warn] eventdns: Unable to parse nameserver address fe80::7e2ebdff:fe99:4cb9%enp2s0
```
It's not as bad as it could be, because Tor skips that line and uses whatever other lines there are. But (a) maybe we're not doing as well as we can do, and (b) maybe there are situations where that's the only configured nameserver and everything works on the host except Tor doesn't.
I think technically this might be a libevent bug (aka missing feature), since it's libevent's evdns_base_nameserver_ip_add() which calls evutil_parse_sockaddr_port() which helpfully explains that
```
/* recognized formats are:
* [ipv6]:port
* ipv6
* [ipv6]
* ipv4:port
* ipv4
*/
```
none of which are the % syntax. But I will file it here as a Tor ticket, since it's a Tor bug too, and then we can figure out where best to fix it.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33043Prop 306: Keep bridge IPv6 behaviour in sync with client behaviour2022-06-17T18:01:01ZteorProp 306: Keep bridge IPv6 behaviour in sync with client behaviourWe should make some minor changes to Proposal 306, so that bridge IPv6 behaviour stays in sync with client IPv6 behaviour:
https://gitweb.torproject.org/torspec.git/tree/proposals/306-ipv6-happy-eyeballs.txt
For an description of the ne...We should make some minor changes to Proposal 306, so that bridge IPv6 behaviour stays in sync with client IPv6 behaviour:
https://gitweb.torproject.org/torspec.git/tree/proposals/306-ipv6-happy-eyeballs.txt
For an description of the necessary changes, see section 3.3.1 and 3.3.2 of the draft proposal 311:
https://github.com/torproject/torspec/pull/103/files#diff-090a91ed4c8eac745c5ecc316b78dab4R153https://gitlab.torproject.org/tpo/core/tor/-/issues/32954Stop public authorities specifying an internal address for their IPv6 ORPort2022-06-24T14:53:56ZteorStop public authorities specifying an internal address for their IPv6 ORPortWhen we implement `Address [IPv6]` in legacy/trac#30954, we should check that the supplied IPv6 address is a public address on Directory Authorities.
This matches the current `Address IPv4` check for authorities.When we implement `Address [IPv6]` in legacy/trac#30954, we should check that the supplied IPv6 address is a public address on Directory Authorities.
This matches the current `Address IPv4` check for authorities.https://gitlab.torproject.org/tpo/core/tor/-/issues/32905Remove the ClientAutoIPv6ORPort option2020-06-27T13:48:31ZNeel Chauhanneel@neelc.orgRemove the ClientAutoIPv6ORPort optionIn legacy/trac#27490, we introduced the option `ClientAutoIPv6ORPort`, which randomly tries IPv4 or IPv6 randomly.
This option is not true Happy Eyeballs and fails very often, usually trying IPv6 on networks which are IPv4-only (legacy/...In legacy/trac#27490, we introduced the option `ClientAutoIPv6ORPort`, which randomly tries IPv4 or IPv6 randomly.
This option is not true Happy Eyeballs and fails very often, usually trying IPv6 on networks which are IPv4-only (legacy/trac#30639).
We should remove this option.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32888Log address config info when tor starts up2020-07-24T16:42:12ZteorLog address config info when tor starts upWe're going to be modifying tor's address detection and reachability code for an upcoming sponsor. To help us debug, we should log the following info when tor starts up:
IPv4:
* the `Address` torrc option
* and whether it is an IP add...We're going to be modifying tor's address detection and reachability code for an upcoming sponsor. To help us debug, we should log the following info when tor starts up:
IPv4:
* the `Address` torrc option
* and whether it is an IP address, or a DNS name
* the local hostname
* and whether it is an IP address, or a DNS name
* the local network interface addresses
See `resolve_my_address()` for details.
IPv6:
* the IPv6 address of the first IPv6 `ORPort` torrc option
See `router_build_fresh_descriptor()` and `router_get_advertised_ipv6_or_ap()` (in legacy/trac#32588) for details.
When (or if) we use them as part of address detection, we should also log the following info:
IPv4 and IPv6:
* the `Address` torrc option
* and whether it is an IP address, or a DNS name
* the IPv4 and IPv6 addresses of the first `ORPort` torrc option of each address family
* the local hostname
* and whether it is an IP address, or a DNS name
* the local network interface addresses
Notes:
* We'll need a proposal to decide if `ORPort` or hostname should come first
* We'll probably want a summary at notice level, and then detailed logs at info level
* If all these methods fail, relays use `X-Your-Address-Is:` headers from directory authorities. They are out of scope, because they are not available at startup.
* Similarly, we won't print address reachability self-testing info, because it's not available at startup.
* We may want to print similar log messages (including `X-Your-Address-Is:` and reachability info) as part of tor's regular heartbeat messages. But that deserves a separate ticket.
I don't think we'll use (or log):
* the addresses of any `DirPort` torrc options
* the addresses of multiple `ORPort` torrc optionsTor: unspecifiedcchttps://gitlab.torproject.org/tpo/core/tor/-/issues/32822Make authorities add their own IPv6 address to trusted dir servers2020-07-02T13:50:11ZteorMake authorities add their own IPv6 address to trusted dir serversAuthorities add themselves to trusted dir servers, but they don't add their own IPv6 addresses.Authorities add themselves to trusted dir servers, but they don't add their own IPv6 addresses.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32707need a mechanism to automatically detect the ipv6 address of the node2020-06-27T13:48:41ZTracneed a mechanism to automatically detect the ipv6 address of the nodebecause for a dynamic ipv6 address specifying the current ipv6 address requires automatic editing torrc by a scripts(or have i found no other way). it is also necessary to automatically detect when the ipv6 address changes as it is done ...because for a dynamic ipv6 address specifying the current ipv6 address requires automatic editing torrc by a scripts(or have i found no other way). it is also necessary to automatically detect when the ipv6 address changes as it is done for ipv4
**Trac**:
**Username**: babutTor: unspecified