[tor-relays] Unwarranted discrimination of relays with dynamic IP

[Kurt Besig]

On 12/4/2016 1:03 AM, teor wrote:
> 
>> On 4 Dec. 2016, at 01:06, Rana <ranaventures at gmail.com> wrote:
>>
>> I have been running a relay with dynamic IP for a month now and quite obviously my relay is severely punished for having a dynamic IP. The IP may change once in several days (currently running over a week with the same IP and I just got my Stable flag back again, about 3 weeks after losing it). The relay’s throughput is a tiny fraction (less than 10%) of the actual capacity which I programmed the torrc file to donate. The capacity I wanted to donate is less than the uplink speed of my internet connection (the downlink speed is higher than downlink and is thus irrelevant here).
> 
> A slow ramp-up is normal, but you seem to be experiencing something
> different:
> 
> https://blog.torproject.org/blog/lifecycle-of-a-new-relay
> 
> Given what you said about the flags, it's likely the directory
> authorities' reachability and stability checks that are removing the
> flags from your relay:
> 
> https://gitweb.torproject.org/tor.git/tree/src/or/dirserv.c#n851
> https://gitweb.torproject.org/tor.git/tree/src/or/dirserv.c#n3170
> 
>> I started with a consensus rating of 21, which went up to 30 and then after a couple of IP changes collapsed to 13. It is now 14, and never went above this again,  with the relay running ALL THE TIME stably for a month minus a small number of restarts due to IP changes. As I said, stable IP for a week now and a Stable flag. 
> 
> The Tor bandwidth authorities don't store your relay's IP address, so
> it's probably not the bandwidth measurements that are the issue:
> 
> https://gitweb.torproject.org/pytorctl.git/tree/SQLSupport.py#n85
> 
>> 1.       Why is the relay with dynamic IP punished? This makes zero sense to me. IMHO changing an IP once a week and running stably between such changes is stable enough for all practical purposes. And since the fingerprint of the relay does not change when the IP is changed, dirauths know that this is the same stable node.
> 
> No, that's not strictly true, all the directory authorities know is that
> it is a node that has access to the same private key.
> 
> There are advantages to resetting when a relay's IP address changes:
> * a changed IP usually means a changed network with different
>   characteristics,
> * if the relay IP address changes, there's no guarantee it will be just
>   as reachable or stable at the new IP,
> * stolen keys become much less valuable,
> * duplicate keys / failover strategies are discouraged.
> 
> To resolve this issue, I recommend getting a static IPv4 address with
> your ISP, or renting a cheap VPS with a static IPv4 address.
> 
>> 2.       The “advertised bandwidth” that I see in Atlas has absolutely nothing to do either with the bandwidth that I advertise (it is 3-4 times larger than what I see in Atlas) or with the actual data throughput of my relay (it is 20 times smaller than what I see in Atlas). Can somebody explain this?
> 
> It's likely related to the fact that your relay is never on the same IP
> long enough to get the Stable or Fast flags, so no clients use it.
> 
> But I don't know your relay's fingerprint, so I can only repeat the
> general advice I have given others with similar questions:
> 
> https://lists.torproject.org/pipermail/tor-relays/2016-November/010913.html
> https://lists.torproject.org/pipermail/tor-relays/2016-November/010928.html
> https://lists.torproject.org/pipermail/tor-relays/2016-November/010916.html
> 
> (There are more if you search the list archives.)
> 
> That should be enough to get you started, if you'd still like specific
> advice after reading those threads, feel free to let us know your
> relay's fingerprint.
> 
> T
> 
For as little as $10.00 US there are VPS' with static ip's..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20161204/ab46eb52/attachment.sig>