<!DOCTYPE html>
<html><head>
<meta charset="UTF-8">
</head><body><p><br></p><blockquote><blockquote><p><a href="https://trac.torproject.org/projects/tor/ticket/4847">https://trac.torproject.org/projects/tor/ticket/4847</a><br></p><p>so my planned setup would not work I guess.</p><p>A workaround would probably be to bind to IPv4 as well and ignore the fact that the IPv4 bridge wont be useable since it runs on the same IP as the public relay, but I'd rather wait for a fix of #4847.</p><p>#4847 has the milestone set to unknown "0.2.???"</p></blockquote><p>You might be waiting some time, as we've already triaged tasks for the next Tor release 0.2.9, which comes out in 6 months.</p><p>The relay's IPv4 address may be blocked in some jurisdictions, but not others.<br>So it still could be useful for some users.<br>And the bridge's IPv6 address is far less likely to be blocked, so it will be useful by itself.</p><p>Please also note that you can have a maximum of 2 relays per IPv4 address (or a relay and a bridge), on different ports.</p><br></blockquote><p>Thanks for that reminder, so I cannot make use of all these unused IPv6 IPs anyway since I would have as many IPv4 IPs currently. <br></p><p>It is no problem to wait since they are running relays already, but it is just a pitty that all these IPs are of no use. And last time I checked I was unable to get any IPv6 bridge via <a href="https://bridges.torproject.org/">https://bridges.torproject.org/</a> (any pluggable transport).<br></p><p>"Uh oh, spaghettios! There currently aren't any bridges available..."</p><p>hoping for 0.2.10 in 2017.<br></p></body></html>