[tor-relays] Guidelines for lifetime of a bridge?

Sun Aug 16 19:24:49 UTC 2015

I'd say about a year is ideal. Maybe longer.

It takes a long time for your bridge's IP address to be handed out to 
users. Once they finally have one, the addresses should remain valid, 
instead of immediately expiring.

Of course once it looks like your bridge's IP address has been exposed, 
drop the bridge and move it.

Tom

starlight.2015q3 at binnacle.cx schreef op 16/08/15 om 20:49:
> Five, ten days?  I ran a bridge at a provider
> where IP addresses are easy to release and
> replace with new ones.  Seems to take the
> censors in China, Iran, Pakistan, etc less
> than a week to find and block new bridge
> IPs.
>
> I gave up in frustration.  Meek is
> a better solution but is not something
> an individual can readily put into
> operation.  China has cracked down
> on all GFW bypasses rather successfully,
> including VPN providers who have a
> strong financial incentive to
> succeed.  Iran is nearly as good.
>
> I find running a relay more satisfying
> and would add relays instead of bridges
> now.
>
>
>
>
> At 19:24 8/16/2015 +0100, you wrote:
>> Hi.
>>
>> Is there a guideline for how long a bridge should
>> exist on a particular IP address? For example,
>> does it make sense to keep a bridge on one IP
>> address forever? Or is it better to move a bridge
>> to a new IP address periodically, perhaps every
>> 120 days?
>>
>> I ask because I saw traffic to my bridge ramp-up
>> fairly steadily, and then quickly drop-off to a
>> low number of clients per day.
>>
>> Thanks!
>>
>> hope you are all well
>> t
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3729 bytes
Desc: S/MIME-cryptografische ondertekening
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150816/df7d7609/attachment.bin>