On 11 Nov. 2016, at 05:39, diffusae punasipuli@t-online.de wrote:
Hello,
thanks for your help.
On 10.11.2016 02:31, teor wrote:
No-one is working on it, as far as I know.
All right, now I see. It's a "nice to have feature", but I don't rely on it. If it disturbs, than I will find a solution.
The other drawback of autodetection is that if we turned it on by default, operators with broken IPv6 configs might find their relays being excluded from the consensus because they are unreachable on IPv6.
We'd have to teach Tor to test IPv6 reachability, and stop advertising IPv6 if it was unreachable.
But this is counted as an address change by OnionOO, so it has flow-on effects in systems that analyse relay stability.
It's quite a challenge to get this right.
That just changes the IPv6 address selected by the OS.
I can't see how it's relevant - unless you have *not* configured privacy extensions, and so autodetection exposes your MAC address to the world.
The second point might only be relevant to me in this case with a bad ISP. I am using SLAAC and can't change the MAC address, due to a driver bug. And that's only if you haven't fixed IP addresses or such strange kind of dynamically created address space.
No, Tor ignores private addresses during autodetection, and relies on other relays to provide the external address.
Ahh, that's good to know, than it also ignores the Shared Address Space for use in ISP CGN: 100.64.0.0/10. As I remember it was recognized, but I've used FQDNs with the Address option. Does autodetection take really longer, than to configure a static IP address?
Some autodetection options resolve hostnames using DNS, or wait for directory documents to download. So yes, it takes longer.
T