Relay 'Binnacle' experienced outages due to a loose fiber-option junction in the overhead wires that has been repaired. I believe it would make the list if not for this and do not foresee further trouble.
Has a static IP and another Verizon FiOS relay qualifies, a positive reflection on the network.
Available if desired. Can configure IPv6 on the HE tunnel here if helpful.
$ python updateFallbackDirs.py
DEBUG:root:Failed to get an ipv6 address for 4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2. DEBUG:root:Adding uptime 4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2. DEBUG:root:4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2 not a candidate: guard avg too low (0.910189)
{ "dir_address":"108.53.208.157:80", "or_addresses":["108.53.208.157:443"], "contact":"starlight dot YYYYqQ at binnacle dot cx", "consensus_weight":17500, "fingerprint":"4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2", "recommended_version":true, "nickname":"Binnacle", "last_changed_address_or_port":"2015-06-12 18:00:00" }
On 18 Dec 2015, at 06:03, starlight.2015q3@binnacle.cx wrote:
Relay 'Binnacle' experienced outages due to a loose fiber-option junction in the overhead wires that has been repaired. I believe it would make the list if not for this and do not foresee further trouble. ... Available if desired. Can configure IPv6 on the HE tunnel here if helpful.
Once clients start bootstrapping over IPv6[0], more IPv6 fallback directories and relays would be helpful.
But I don't know enough about IPv6 tunnels in general and Hurricane Electric in particular to know whether a tunnel is advisable for a tor relay.
I think if a client is just using it for bootstrap, any extra latency shouldn't be an issue. But IPv6 clients may also pick it as a guard, so that should be taken into account.
Should we be running relays over IPv6 tunnels?
Tim
[0]: We're working on it in https://trac.torproject.org/projects/tor/ticket/17840 https://trac.torproject.org/projects/tor/ticket/17840
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On Mon, 18 Jan 2016 10:16:40 +1100 Tim Wilson-Brown - teor teor2345@gmail.com wrote:
I think if a client is just using it for bootstrap, any extra latency shouldn't be an issue. But IPv6 clients may also pick it as a guard, so that should be taken into account.
Should we be running relays over IPv6 tunnels?
Hurricane Electric has tunnel servers all over the world, so it's easy to pick one which will only add negligible latency: https://tunnelbroker.net/status.php
Performance is not a concern either, these are not overloaded and should be quite fast.
On the other hand HE.net may or may not want to have a word with you if you run a relay through them with hundreds of megabits of IPv6 traffic; but that's not something we can expect in the nearest future. [and such powerful relays are most likely in proper DCs with easily obtainable native IPv6 anyways]
There's a possible privacy issue that all the HE.net tunnel traffic can technically be captured by HE.net;
however all of these provide IPv6 addresses under the same AS (6939) and the same prefix of 2001:470::/32, so perhaps the same-AS avoidance code will ensure that a HE.net IPv6 is only used once in a circuit? Does it correctly handle cases when a router's IPv4 and IPv6 addresses are from different ASes?
On 18 Jan 2016, at 11:07, Roman Mamedov rm@romanrm.net wrote:
On Mon, 18 Jan 2016 10:16:40 +1100 Tim Wilson-Brown - teor teor2345@gmail.com wrote:
I think if a client is just using it for bootstrap, any extra latency shouldn't be an issue. But IPv6 clients may also pick it as a guard, so that should be taken into account.
Should we be running relays over IPv6 tunnels?
Hurricane Electric has tunnel servers all over the world, so it's easy to pick one which will only add negligible latency: https://tunnelbroker.net/status.php
Performance is not a concern either, these are not overloaded and should be quite fast.
On the other hand HE.net may or may not want to have a word with you if you run a relay through them with hundreds of megabits of IPv6 traffic; but that's not something we can expect in the nearest future. [and such powerful relays are most likely in proper DCs with easily obtainable native IPv6 anyways]
We're still working to get Tor clients bootstrapping over IPv6, so there isn't going to be much IPv6 relay traffic at the moment.
There's a possible privacy issue that all the HE.net tunnel traffic can technically be captured by HE.net;
however all of these provide IPv6 addresses under the same AS (6939) and the same prefix of 2001:470::/32, so perhaps the same-AS avoidance code will ensure that a HE.net IPv6 is only used once in a circuit? Does it correctly handle cases when a router's IPv4 and IPv6 addresses are from different ASes?
Tor doesn't use ASs for same-network avoidance, it only uses network masks.
In the current Tor codebase, onion_populate_cpath()/addrs_in_same_network_family() avoids adding relays in the same IPv4 /16 to the same circuit. IPv6 addresses are not considered, because this check uses the relay's primary ORPort IPv4 address.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-relays@lists.torproject.org
-
Roman Mamedov -
starlight.2015q3＠binnacle.cx -
Tim Wilson-Brown - teor