Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:51:08Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33242Prop 312: 3.2.5. Make Relays do IPv4 and IPv6 Directory Fetches2020-06-13T15:51:08ZteorProp 312: 3.2.5. Make Relays do IPv4 and IPv6 Directory FetchesRelays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients...Relays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients. (So they can't find their IPv6 addresses in this way.)
We propose to use a simple load balancing scheme for IPv4 and IPv6
directory requests:
* choose between IPv4 and IPv6 directory requests at random.
We do not expect this change to have any load-balancing impact on the public
tor network, because the number of relays is much smaller than the number
of clients. However, the 6 directory authorities with IPv6 enabled may see
slightly more directory load, particularly over IPv6.
See proposal 312, section 3.2.5, directory fetch part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n429https://gitlab.torproject.org/legacy/trac/-/issues/33241Prop 312: 3.2.5. Use Directory Header IPv6 Addresses2020-06-13T15:51:07ZteorProp 312: 3.2.5. Use Directory Header IPv6 AddressesThis is a parent ticket.
If relays are unable to discover their IPv6 address in any other way, they should get their IPv6 address from the X-Your-Address-Is HTTP header in tor directory documents. To support this change, we propose that...This is a parent ticket.
If relays are unable to discover their IPv6 address in any other way, they should get their IPv6 address from the X-Your-Address-Is HTTP header in tor directory documents. To support this change, we propose that relays start fetching directory documents over IPv4 and IPv6.
We propose that bridges continue to only fetch directory documents over IPv4, because they try to imitate clients. Therefore, they can't use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
See proposal 312, section 3.2.5:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n429https://gitlab.torproject.org/legacy/trac/-/issues/33240Prop 312: 3.2.4. Use Own Hostname IPv6 Addresses2020-06-13T15:51:07ZteorProp 312: 3.2.4. Use Own Hostname IPv6 AddressesThis ticket depends on `Address IPv6` support in #33233 and IPv6 resolution support in #33234.
If they don't have usable Address, ORPort, or interface addresses, relays (and bridges) should get their local hostname, look
up its addresse...This ticket depends on `Address IPv6` support in #33233 and IPv6 resolution support in #33234.
If they don't have usable Address, ORPort, or interface addresses, relays (and bridges) should get their local hostname, look
up its addresses, and use them as its IPv4 and IPv6 addresses.
We propose to use the same underlying lookup functions to look up the IPv4
and IPv6 addresses for:
* the Address torrc option (see section 3.2.1), and
* the local hostname.
However, OS APIs typically only return a single hostname. (Rather than a
separate hostname for IPv4 and IPv6.)
The hostname lookup should ignore private addresses on public relays. If
multiple IPv4 or IPv6 addresses are returned, the first public address from
each family should be used.
See proposal 312, section 3.2.4:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n408https://gitlab.torproject.org/legacy/trac/-/issues/33238Prop 312: 3.2.3. Use Local Interface IPv6 Address2020-06-13T15:51:05ZteorProp 312: 3.2.3. Use Local Interface IPv6 AddressThis ticket depends on `Address IPv6` support in #33233.
If they don't have usable Address or ORPort addresses, relays (and bridges) should use publicly routable addresses
from the OS interface addresses or routing table, as their IPv4 ...This ticket depends on `Address IPv6` support in #33233.
If they don't have usable Address or ORPort addresses, relays (and bridges) should use publicly routable addresses
from the OS interface addresses or routing table, as their IPv4 and IPv6
addresses.
Tor has local interface address resolution functions, which support most
major OSes. Tor uses these functions to guess its IPv4 address. We propose
using them to also guess tor's IPv6 address.
We also propose modifying the address resolution order, so interface
addresses are used before the local hostname. This decision is based
on our principles: interface addresses are local, trusted, and reliable;
hostname lookups may be remote, untrusted, and unreliable.
If the local interface addresses are unavailable, tor opens a UDP socket to
a publicly routable address, but doesn't actually send any packets.
Instead, it uses the socket APIs to discover the interface address for the
socket. (UDP is used because it is stateless, so the OS will not send any
packets to open a connection.)
Tor already ignores private IPv4 interface addresses on public relays. We
propose to also ignore private IPv6 interface addresses.
See proposal 312, section 3.2.1, general case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n359https://gitlab.torproject.org/legacy/trac/-/issues/33236Prop 312: 3.2.2. Use Advertised ORPort IPv4 Address in Descriptors2020-06-13T15:51:04ZteorProp 312: 3.2.2. Use Advertised ORPort IPv4 Address in DescriptorsIf the Address option is not set for IPv4 or IPv6, relays (and bridges) should use the first advertised ORPort IPv4 and IPv6 addresses.
Note that relays already use the first advertised IPv6 ORPort address in their descriptors. So we ju...If the Address option is not set for IPv4 or IPv6, relays (and bridges) should use the first advertised ORPort IPv4 and IPv6 addresses.
Note that relays already use the first advertised IPv6 ORPort address in their descriptors. So we just need to preserve that behaviour.
The ORPort address may be a hostname. If it is, tor should try to use it to
resolve an IPv4 and IPv6 address, and open ORPorts on the first available
IPv4 and IPv6 address. Tor should respect the IPv4Only and IPv6Only port
flags, if specified. (Tor currently resolves IPv4 and IPv6 addresses from
hostnames in ORPort lines.)
Relays (and bridges) currently use the first advertised ORPort IPv6 address
as their IPv6 address. We propose to use the first advertised IPv4 ORPort
address in a similar way, for consistency.
Tor currently uses its listener port list to look up its IPv6 ORPort for
its descriptor. We propose that tor's address discovery uses the listener
port list for both IPv4 and IPv6. (And does not attempt to independently
parse or resolve ORPort configs.)
This design decouples ORPort option parsing, ORPort listener opening, and
address discovery. It also implements a form of caching: IPv4 and IPv6
addresses resolved from hostnames are stored in the listener port list,
then used to open listeners. Therefore, tor should continue to use the same
address, while the listener remains open. (See also sections 3.2.7 and
3.2.8.)
For the purposes of address resolution, tor should ignore private
configured ORPort addresses on public tor networks. (Binding to private
ORPort addresses is supported, even on public tor networks, for relays that use NAT to reach the Internet.)
See proposal 312, section 3.2.2, general case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n306https://gitlab.torproject.org/legacy/trac/-/issues/33235Prop 312: 3.2.1. Test Address torrc Option Configurations2020-06-13T15:51:03ZteorProp 312: 3.2.1. Test Address torrc Option ConfigurationsThis ticket depends on IPv6 Addresses in #33233, and automatic IPv6 ORPorts in #33246. These tests should be in CI, or they should be repeated after each change.
We should support the following combinations of address literals and hostn...This ticket depends on IPv6 Addresses in #33233, and automatic IPv6 ORPorts in #33246. These tests should be in CI, or they should be repeated after each change.
We should support the following combinations of address literals and hostnames:
Legacy configurations:
A. No configured Address option
B. Address IPv4 literal
C. Address hostname (use IPv4 and IPv6 DNS addresses)
New configurations:
D. Address IPv6 literal
E. Address IPv4 literal / Address IPv6 literal
F. Address hostname / Address hostname (use IPv4 and IPv6 DNS addresses)
G. Address IPv4 literal / Address hostname (only use IPv6 DNS addresses)
H. Address hostname (only use IPv4 DNS addresses) / Address IPv6 literal
If we can't find an IPv4 or IPv6 address using the configured Address options:
* No IPv4: guess IPv4, and its reachability must succeed.
* No IPv6: guess IPv6, publish if reachability succeeds.
Combinations A and B are the most common legacy configurations. We want to support the following outcomes for all legacy configurations:
* automatic upgrades to guessed and reachable IPv6 addresses,
* continuing to operate on IPv4 when the IPv6 address can't be guessed, and
* continuing to operate on IPv4 when the IPv6 address has been guessed, but it is unreachable.
See proposal 312, section 3.2.1, testing notes:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n270https://gitlab.torproject.org/legacy/trac/-/issues/33234Prop 312: 3.2.1. Make the Address torrc Option Resolve IPv6 Hostnames2020-06-13T15:51:02ZteorProp 312: 3.2.1. Make the Address torrc Option Resolve IPv6 HostnamesThis ticket depends on `Address IPv6` support in #33233.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 hostname / DNS case:
2. Hostnames / DNS names:
* allow the ...This ticket depends on `Address IPv6` support in #33233.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 hostname / DNS case:
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.
These lookups should ignore private addresses on public tor networks. If
multiple IPv4 or IPv6 addresses are returned, the first public address from each family should be used.
Tor should warn if a configured Address hostname does not resolve
to any publicly routable IPv4 or IPv6 addresses. (If
tor is configured with a custom set of directory authorities, private
addresses should be allowed, with a notice-level log.)
For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory authorities only accept IPv4 or IPv6 address literals in their Address option. They must not attempt to resolve their Address using DNS. It is a config error to provide a hostname as a directory authority's Address.
See proposal 312, section 3.2.1, case 2:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n258https://gitlab.torproject.org/legacy/trac/-/issues/33233Prop 312: 3.2.1. Make the Address torrc Option Support IPv6 Literals2020-06-13T15:51:01ZteorProp 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
#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 addresse...We can work on this ticket now, but we should do the code movement in
#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 #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 #33235.https://gitlab.torproject.org/legacy/trac/-/issues/33227Prop 311: 5.1. Update Tor Spec Relay Subprotocols2020-06-13T15:51:00ZteorProp 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/legacy/trac/-/issues/33225Prop 311: 4.4.1. Extend IPv6 From All Supported Second-Last Hops2020-06-13T15:50:59ZteorProp 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 #33222. (The alternative design requires creating different circuit types for IPv4 and IPv6 reachability checks.)
...This is an optional change.
This change has a zero points estimate, because I think it is the fastest way of implementing #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#n439Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33230Prop 311: 6.1. Ask Relay Operators to Test IPv6 Reachability2020-06-13T15:50:58ZteorProp 311: 6.1. Ask Relay Operators to Test IPv6 ReachabilitySee #33229 for advice on testing stages.
Write an email to the tor-relays list, asking relay operators to help test the proposal 311 IPv6 ORPort Reachability and Extends changes.
Once these changes are merged, volunteer relay and bridg...See #33229 for advice on testing stages.
Write an email to the tor-relays list, asking relay operators to help test the proposal 311 IPv6 ORPort Reachability and Extends changes.
Once these changes are merged, volunteer relay and bridge operators will be able to test them by:
* compiling from source,
* running nightly builds, or
* running alpha releases.
See proposal 311, section 6.1, relay operator test part:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n671Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33229Prop 311: 6.1. Test IPv6 ORPort Reachability on the Tor Network2020-06-13T15:50:58ZteorProp 311: 6.1. Test IPv6 ORPort Reachability on the Tor NetworkTest the IPv6 ORPort Reachability and Extends changes in proposal 311, on the public tor network, with a small number of relays and bridges.
We can do public tests after each major feature is merged. We can
also wait for multiple featur...Test the IPv6 ORPort Reachability and Extends changes in proposal 311, on the public tor network, with a small number of relays and bridges.
We can do public tests after each major feature is merged. We can
also wait for multiple features to merge, and test them all.
Here are some useful features that we can test:
#33222 / #33226 IPv6 ORPort Reachability Self-Tests / Relay=3 Protocol
#33223 Don't Publish Descriptor if IPv6 ORPort is Unreachable
See proposal 311, section 6.1, initial public test part:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n671Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33223Prop 311: 4.3.1. Don't Publish Descriptor if IPv6 ORPort is Unreachable2020-06-13T15:50:57ZteorProp 311: 4.3.1. Don't Publish Descriptor if IPv6 ORPort is UnreachableThis ticket depends on the protocol version ticket #33226.
Since it stops relays publishing their descriptors, it needs to be
tested on the public tor network, see #33229 and #33230.
If IPv6 reachability checks fail, relays (and bridge...This ticket depends on the protocol version ticket #33226.
Since it stops relays publishing their descriptors, it needs to be
tested on the public tor network, see #33229 and #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#n351https://gitlab.torproject.org/legacy/trac/-/issues/33221Prop 311: 4. Ensure Relay and Bridge IPv6 ORPorts are Reachable2020-06-13T15:50:54ZteorProp 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#n246teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33220Prop 311: 3. Allow Relay IPv6 Extends2020-06-13T15:50:53ZteorProp 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#n112teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33195Require IPv6 tests in Travis CI2020-06-13T15:50:47ZteorRequire 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/legacy/trac/-/issues/33159Write a proposal for monitoring IPv62020-06-13T15:50:42ZteorWrite 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 (#33051)
* O1.5 - Measure the number of connections, and consumed bandwidth, using I...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 (#33051)
* O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6 (#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/legacy/trac/-/issues/33091Remove redundant checks in ip_address_changed()2020-06-13T15:50:29ZteorRemove 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/legacy/trac/-/issues/33073Write a proposal for Tor Relays to Automatically Find their IPv6 Address2020-06-13T15:50: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/legacy/trac/-/issues/33056Tor relays fail to understand /etc/resolv.conf ipv6 lines with % in them2020-06-13T15:50:23ZRoger 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-final