The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-07-01T20:27:30Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33235Prop 312: 3.2.1. Test Address torrc Option Configurations2020-07-01T20:27:30ZteorProp 312: 3.2.1. Test Address torrc Option ConfigurationsThis ticket depends on IPv6 Addresses in legacy/trac#33233, and automatic IPv6 ORPorts in legacy/trac#33246. These tests should be in CI, or they should be repeated after each change.
We should support the following combinations of addr...This ticket depends on IPv6 Addresses in legacy/trac#33233, and automatic IPv6 ORPorts in legacy/trac#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:
1. (A) No configured Address option
2. (B) Address IPv4 literal
3. (C) Address hostname (use IPv4 and IPv6 DNS addresses)
New configurations:
1. (D) Address IPv6 literal
2. (E) Address IPv4 literal / Address IPv6 literal
3. (F) Address hostname / Address hostname (use IPv4 and IPv6 DNS addresses)
4. (G) Address IPv4 literal / Address hostname (only use IPv6 DNS addresses)
5. (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#n270Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33240Prop 312: 3.2.4. Use Own Hostname IPv6 Addresses2020-06-29T11:09:37ZteorProp 312: 3.2.4. Use Own Hostname IPv6 AddressesThis ticket depends on `Address IPv6` support in legacy/trac#33233 and IPv6 resolution support in legacy/trac#33234.
If they don't have usable Address, ORPort, or interface addresses, relays (and bridges) should get their local hostname...This ticket depends on `Address IPv6` support in legacy/trac#33233 and IPv6 resolution support in legacy/trac#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#n408David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/33618Add IPv6 Support to is_local_addr()2020-06-29T14:38:48ZTracAdd IPv6 Support to is_local_addr()We propose this optional change, to improve the accuracy of IPv6 address
detection from directory documents.
Directory servers use is_local_addr() to detect if the requesting tor
instance is on the same local network. If it is, the dire...We propose this optional change, to improve the accuracy of IPv6 address
detection from directory documents.
Directory servers use is_local_addr() to detect if the requesting tor
instance is on the same local network. If it is, the directory server does
not include the X-Your-Address-Is HTTP header in directory documents.
Currently, is_local_addr() checks for:
* an internal IPv4 or IPv6 address, or
* the same IPv4 /24 as the directory server.
We propose also checking for:
* the same IPv6 /48 as the directory server.
We choose /48 because it is typically the smallest network in the global
IPv6 routing tables, and it was previously the recommended per-customer
network block. (See [RFC 6177: IPv6 End Site Address Assignment].)
Tor currently uses:
* IPv4 /8 and IPv6 /16 for port summaries,
* IPv4 /16 and IPv6 /32 for path selection (avoiding relays in the same
network block).
Source: https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1099
**Trac**:
**Username**: kimimaroTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33919Write unit tests for channel_matches_target_addr_for_extend()2021-09-16T14:21:51ZteorWrite unit tests for channel_matches_target_addr_for_extend()In legacy/trac#33817, we modify channel_matches_target_addr_for_extend() to take an IPv4 and an IPv6 address.
We also modify channel_get_for_extend() to take an IPv4 and an IPv6 address. It has existing tests, but they ignore IP address...In legacy/trac#33817, we modify channel_matches_target_addr_for_extend() to take an IPv4 and an IPv6 address.
We also modify channel_get_for_extend() to take an IPv4 and an IPv6 address. It has existing tests, but they ignore IP addresses. (And mock the matches_target() method, which is called by channel_matches_target_addr_for_extend().)
It would be useful to have tests that check that a channel matches, if its IP address matches the IPv4 or IPv6 address. But it's not urgent. (And the actual changes to the function are pretty trivial.)
The setup for these tasks is a bit tricky, we need to set up a channel_tls_t and an associated connection_t with a real_addr. (Note that legacy/trac#33898 may change the name of real_addr.)
This task is not urgent or important. Anyone can do this task.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31812http URL's in docs/comments should be https2021-07-22T16:19:25ZJeremyRandhttp URL's in docs/comments should be httpsThe documentation and comments in Tor's repo have quite a few http URL's that should be changed to https. Patch incoming shortly for this.The documentation and comments in Tor's repo have quite a few http URL's that should be changed to https. Patch incoming shortly for this.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40052S55: Make router_has_advertised_ipv6_orport() look at the descriptor2020-07-21T15:54:06ZNick MathewsonS55: Make router_has_advertised_ipv6_orport() look at the descriptorRight now, `router_has_advertised_ipv6_orport()` only looks at the configured advertised ports, and doesn't look at whether we have a published ORPort. That's not what we want it to do; we should look at the descriptor we're publishing,...Right now, `router_has_advertised_ipv6_orport()` only looks at the configured advertised ports, and doesn't look at whether we have a published ORPort. That's not what we want it to do; we should look at the descriptor we're publishing, I think.Tor: 0.4.5.x-freezeNick 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/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/33238Prop 312: 3.2.3. Use Local Interface IPv6 Address2020-07-03T13:21:32ZteorProp 312: 3.2.3. Use Local Interface IPv6 AddressThis ticket depends on `Address IPv6` support in legacy/trac#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 ...This ticket depends on `Address IPv6` support in legacy/trac#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#n359Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40025Prop 312: Make relay pick IPv4 or/and IPv6 resolved address in descriptor2020-07-21T12:04:11ZDavid Gouletdgoulet@torproject.orgProp 312: Make relay pick IPv4 or/and IPv6 resolved address in descriptorAt the moment, `router_pick_published_address()` is used to pick the address we'll put in a relay descriptor. It checks at the last resolved address, then attempts to locally find the address and finally attempts to look at what a direct...At the moment, `router_pick_published_address()` is used to pick the address we'll put in a relay descriptor. It checks at the last resolved address, then attempts to locally find the address and finally attempts to look at what a directory server suggested us.
With the work in tor#40022, we now discover our address with the `NETINFO` cell for both IPv4 and IPv6. We should use that.
Thus this ticket means that we need a new interface to query "what address should I use in my descriptor" so it is usable per address family and queries the right caches (that is not the directory guessed IP cache anymore).Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/30971Rebuild the fallback list in late 2019 or early 20202020-07-24T17:25:50ZteorRebuild the fallback list in late 2019 or early 2020Late in 2019, or early in 2020, we should rebuild the fallback list again.
We usually do this when 25% or more go down.
(When 25% of fallbacks are down, a warning is logged daily in #tor-bots on IRC, and via email to the fallback mainta...Late in 2019, or early in 2020, we should rebuild the fallback list again.
We usually do this when 25% or more go down.
(When 25% of fallbacks are down, a warning is logged daily in #tor-bots on IRC, and via email to the fallback maintainers.)
Here are the instructions for running a rebuild:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors
See the child tickets for each step.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32910trace: Add tracepoints and userspace tracer support2020-07-10T17:24:17ZDavid Gouletdgoulet@torproject.orgtrace: Add tracepoints and userspace tracer supportTor-dev email: https://lists.torproject.org/pipermail/tor-dev/2019-December/014111.html
These are what needs to be done but they sorta need to be together to make sense thus this one ticket:
a. Add a series of tracepoints in tor code b...Tor-dev email: https://lists.torproject.org/pipermail/tor-dev/2019-December/014111.html
These are what needs to be done but they sorta need to be together to make sense thus this one ticket:
a. Add a series of tracepoints in tor code base. I propose to start with circuit and cell level tracepoints for now.
b. Add USDT (User Statically-Defined Tracing) probes support which is used by SystemTap, DTrace and perf.
c. Add LTTng support which if enable also emits USDT.
d. Integrate all this to our build system.
About(d), the consensus among the network team is that it should NEVER be enabled in production and should be a configure switch.
I believe if we add on top a torrc option, it might not be that useful in the end considering the configure switch but mainly it will degrade performance since the check needs to be at runtime for every tracepoint.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33245Prop 312: 3.2.6. Add an AddressDisableIPv6 torrc option2020-07-21T13:02:03ZteorProp 312: 3.2.6. Add an AddressDisableIPv6 torrc optionShould be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
Relays (and bridges) that have a reachable IPv6 address, but that address
is unsuitable for the relay, need to be able to disable IPv6...Should be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
Relays (and bridges) that have a reachable IPv6 address, but that address
is unsuitable for the relay, need to be able to disable IPv6 address
resolution.
Currently, relays are required to have an IPv4 address. So if the guessed
IPv4 address is unsuitable, operators can set the Address option to a
suitable IPv4 address. But IPv6 addresses are optional, so relay operators
may need to disable IPv6 entirely.
We propose a new torrc-only option, AddressDisableIPv6. This option is set
to 0 by default. If the option is set to 1, tor disables IPv6 address
resolution, IPv6 ORPorts, IPv6 reachability checks, and publishing an IPv6
ORPort in its descriptor.
See proposal 312, section 3.2.6:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n498Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40033Rename blacklist and whitelist to something without a harmful connotation2020-07-21T20:23:42ZDavid Gouletdgoulet@torproject.orgRename blacklist and whitelist to something without a harmful connotationThis is to remove from our codebase the obvious connotation that black is bad and white is good.
And please, lets keep etymology out of this discussion.This is to remove from our codebase the obvious connotation that black is bad and white is good.
And please, lets keep etymology out of this discussion.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40036tracing: Detailed more in depth tracepoints and their parameters2020-10-22T15:12:32ZDavid Gouletdgoulet@torproject.orgtracing: Detailed more in depth tracepoints and their parametersThis comes from as a task post tor#32910.
Idea here is to either document the `lttng_circuit.inc` file in much more depth explaining each parameters or do a separate file that lists all our stable tracepoints and document. Unclear which...This comes from as a task post tor#32910.
Idea here is to either document the `lttng_circuit.inc` file in much more depth explaining each parameters or do a separate file that lists all our stable tracepoints and document. Unclear which is best.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40049CID 1465290: Passing null pointer "ipv4_addr" to "geoip_get_country_by_addr"2020-07-16T18:17:57ZDavid Gouletdgoulet@torproject.orgCID 1465290: Passing null pointer "ipv4_addr" to "geoip_get_country_by_addr"```
*** CID 1465290: Null pointer dereferences (FORWARD_NULL)
/src/feature/nodelist/nodelist.c: 1991 in node_set_country()
1985 /* XXXXipv6 */
1986 if (node->rs)
1987 ipv4_addr = &node->rs->ipv4_addr;
1988 els...```
*** CID 1465290: Null pointer dereferences (FORWARD_NULL)
/src/feature/nodelist/nodelist.c: 1991 in node_set_country()
1985 /* XXXXipv6 */
1986 if (node->rs)
1987 ipv4_addr = &node->rs->ipv4_addr;
1988 else if (node->ri)
1989 ipv4_addr = &node->ri->ipv4_addr;
1990
>>> CID 1465290: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "ipv4_addr" to "geoip_get_country_by_addr", which dereferences it.
1991 node->country = geoip_get_country_by_addr(ipv4_addr);
1992 }
1993
1994 /** Set the country code of all routers in the routerlist. */
1995 void
1996 nodelist_refresh_countries(void)
```Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40054prop 312: Don't publish IPv6 address if ORPort is IPv4Only2020-07-21T13:03:50ZDavid Gouletdgoulet@torproject.orgprop 312: Don't publish IPv6 address if ORPort is IPv4OnlyNow that tor#40025 is merged, I believe there is an issue for which we assume we'll find an ORPort if we have found an IPv6 address.
In `router_build_fresh_unsigned_routerinfo()`, we should check at the returned value of `router_get_adv...Now that tor#40025 is merged, I believe there is an issue for which we assume we'll find an ORPort if we have found an IPv6 address.
In `router_build_fresh_unsigned_routerinfo()`, we should check at the returned value of `router_get_advertised_or_port_by_af()` and not publish a port value of 0. It is possible for instance if the `ORPort` is `IPv4Only`.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33246Prop 312: 3.2.7. Automatically Enable an IPv6 ORPort2020-07-22T13:56:19ZteorProp 312: 3.2.7. Automatically Enable an IPv6 ORPortAfter we implement legacy/trac#33233, relays (and bridges) should try to open an IPv6 ORPort.
The ORPort should be opened on the port configured in the relay's ORPort
torrc option. Relay operators can use the IPv4Only and IPv6Only optio...After we implement legacy/trac#33233, relays (and bridges) should try to open an IPv6 ORPort.
The ORPort should be opened on the port configured in the relay's ORPort
torrc option. Relay operators can use the IPv4Only and IPv6Only options
to configure different ports for IPv4 and IPv6.
If the ORPort is auto-detected, there will not be any specific bind
address. (And the detected address may actually be on a NAT box, rather
than the local machine.) Therefore, relays should attempt to bind to all
IPv4 and IPv6 addresses (or all interfaces).
Some operating systems expect applications to bind to IPv4 and IPv6
addresses using separate API calls. Others don't support binding only to
IPv4 or IPv6, and will bind to all addresses whenever there is no specified
IP address (in a single API call). Tor should support both styles of
networking API.
In particular, if binding to all IPv6 addresses fails, relays should still
try to discover their public IPv6 address, and check the reachability of
that address. Some OSes may not support the IPV6_V6ONLY flag, but they may
instead bind to all addresses at runtime. (The tor install may also have
compile-time / runtime flag mismatches.)
See proposal 312, section 3.2.7, IPv6 ORPort part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n540
Once this ticket is implemented, we should test the different IPv4/IPv6 configs listed in legacy/trac#33235.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/chutney/-/issues/40008Add a relay-v6.tmpl template file2020-07-22T14:27:22ZDavid Gouletdgoulet@torproject.orgAdd a relay-v6.tmpl template fileFor some reasons, `relay.tmpl` includes `exit-v6.i` which now requires `ipv6_addr` to be set else `None` is put in place.
This makes `basic-min` fails because it ends up with `ORPort None:5001 IPv6Only`. Instead, make `relay.tmpl` to be...For some reasons, `relay.tmpl` includes `exit-v6.i` which now requires `ipv6_addr` to be set else `None` is put in place.
This makes `basic-min` fails because it ends up with `ORPort None:5001 IPv6Only`. Instead, make `relay.tmpl` to be IPv4 only and `relay-v6.tmpl` to be v4 _and_ v6.
This makes all network configuration using `relay.tmpl` to work normally with IPv4 only.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org