Hi!
Is this already solved in 0.2.8.9-1 for addresses with global scope?
https://trac.torproject.org/projects/tor/ticket/17153
I was trying to configure a global reachable IPv6 address, but getting the following error:
"unable to use configured ipv6 address "[::]" in a descriptor."
The only way ist to set a clear global address in the config.
The ISP is changing the 64 bit prefix a bit from time to time and I don't want to configure it manually every two weeks or so.
Best regards,
On 9 Nov. 2016, at 05:40, diffusae punasipuli@t-online.de wrote:
Hi!
Is this already solved in 0.2.8.9-1 for addresses with global scope?
No, that's a ticket related to private IPv6 addresses on test networks.
You want this one, which is not fixed: https://trac.torproject.org/projects/tor/ticket/5940
I was trying to configure a global reachable IPv6 address, but getting the following error:
"unable to use configured ipv6 address "[::]" in a descriptor."
The only way ist to set a clear global address in the config.
Yes, the only way to have an IPv6 ORPort is for the operator to explicitly configure an ORPort with a globally routable IPv6 address.
Address autodetection is error-prone.
IPv4 address autodetection is the source of many accidental misconfigurations by relay operators.
IPv6 autodetection would be worse, because relays don't ever use IPv6 to connect to directory servers or other relays, so they would have to scan their local interfaces, and pick an arbitrary IPv6 address. This doesn't work well in the IPv4 case, so it really is better for operators to select a routable IPv6 address.
The ISP is changing the 64 bit prefix a bit from time to time and I don't want to configure it manually every two weeks or so.
It probably is best to avoid configuring IPv6, or get a better ISP.
(There's no reason for an ISP to change prefixes for IPv6, they should have plenty of address space. Sounds like they're treating it just like IPv4.)
T
Hi!
Thanks a lot for you reply.
On 08.11.2016 22:56, teor wrote:
No, that's a ticket related to private IPv6 addresses on test networks.
Yes, I used the wrong URL.
You want this one, which is not fixed: https://trac.torproject.org/projects/tor/ticket/5940
Maybe it will be fixed or something in this direction.
Address autodetection is error-prone.
That sounds logical. Also, if you have configured IPv6 privacy extensions.
IPv4 address autodetection is the source of many accidental misconfigurations by relay operators.
Especially, if you are behind a CGN and your ISP DNS returns an private IPv4 address.
better for operators to select a routable IPv6 address.
That's the way I've configured it in the past.
It probably is best to avoid configuring IPv6, or get a better ISP.
It depends. If you only have the choice between cable or xDSL networks. I would be happy, if I could get a Gigabit connection for an affordable price to spend more bandwidth. But the EU is sometimes like an underdeveloped country. They call it: "Connecting Europe" or Digital Single Market (DAE 2020).
(There's no reason for an ISP to change prefixes for IPv6, they should have plenty of address space. Sounds like they're treating it just like IPv4.)
Hmm, I've called some technicians of the ISP, they said, that they have disabled IPv6 in some of there modems, because of issues. And it's a relative new thing. My answer was, that the RFC 2460 exists since 1998. That's a really innovation.
Regards,
On 10 Nov. 2016, at 10:12, diffusae punasipuli@t-online.de wrote:
Hi!
Thanks a lot for you reply.
On 08.11.2016 22:56, teor wrote: ...
You want this one, which is not fixed: https://trac.torproject.org/projects/tor/ticket/5940
Maybe it will be fixed or something in this direction.
No-one is working on it, as far as I know.
Address autodetection is error-prone.
That sounds logical. Also, if you have configured IPv6 privacy extensions.
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.
IPv4 address autodetection is the source of many accidental misconfigurations by relay operators.
Especially, if you are behind a CGN and your ISP DNS returns an private IPv4 address.
No, Tor ignores private addresses during autodetection, and relies on other relays to provide the external address.
This only works for IPv4, because relays almost always use IPv4.
...
T
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.
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?
Regards, Reiner
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
Hi,
I didn't read this to the end:
https://trac.torproject.org/projects/tor/ticket/18387
"Just so you know, we want to implement this enhancement in the next release (0.2.9)."
So, hopefully 0.2.9 stable will be released soon.
Regards,
On 10 Nov. 2016, at 09:17, diffusae punasipuli@t-online.de wrote:
Hi,
I didn't read this to the end:
https://trac.torproject.org/projects/tor/ticket/18387
"Just so you know, we want to implement this enhancement in the next release (0.2.9)."
So, hopefully 0.2.9 stable will be released soon.
This feature will not be in 0.2.9.
It was something we wanted to do 8 months ago, but no-one actually worked on it, so the ticket was triaged out of 0.2.9.
You can watch here for any progress: https://trac.torproject.org/projects/tor/ticket/5940
T
tor-relays@lists.torproject.org
-
diffusae -
teor