On 22 Sep 2016, at 11:55, Dennis Ljungmark spider@takeit.se wrote:
On Thu, Sep 22, 2016 at 6:30 PM, teor teor2345@gmail.com wrote:
...
Have you considered configuring an IPv6 ORPort as well? (It's unlikely to affect traffic, but it will help clients that prefer IPv6.)
Not sure right now, I've had _horrid_ experiences with running Tor on ipv6, ranging from the absurd ( Needing ipv4 configured to set up ipv6)
IPv4 addresses are mandatory for relays for a few reasons:
- Tor assumes that relays form a fully-connected clique - this isn't possible if some are IPv4-only and some are IPv6-only;
- some of Tor's protocols only send an IPv4 address - they're being redesigned, but protocol upgrades are hard;
- until recently, clients could only bootstrap over IPv4 (and they still can't using microdescriptors, only full descriptors);
- and IPv6-only clients have poor anonymity, because they stick out too much.
to the inane ( Config keys named "Port" not valid for both ipv6 and ipv4, horrid documentation)
We're working on the IPv6 documentation, and happy to fix any issues. What particular Port config? What was bad about the documentation?
DirPort tor.modio.se:888 won't actually bind on ipv6, even when it's resolving to both ipv4 and ipv6
On most OSs, you can only bind to one IP address per socket. Tor tends to choose the IPv4 address when resolving domain names, because it's what most operators want.
So I'd encourage you to use an explicit IPv4 or IPv6 address. Tor tries not to depend too much on DNS, because it's not particularly secure in general.
DirPort 888 ; won't actually bind on ipv6. DirPort [::]:888; Won't actually bind on ipv6
The binding does work with explicit IPv4 and IPv6 addresses.
But an IPv6 DirPort will never be used by any other Tor client or relay. Clients use the IPv4 or IPv6 ORPort, and relays use the IPv4 DirPort.
We have an open ticket to clarify this in the DirPort documentation.
Adding more DirPort statements means that you have to pick and choose, ipv6 or ipv4. Can only broadcast one.
Yes, the relay descriptor syntax only supports one IPv4 address, with one DirPort. However, it is possible to supply an IPv6 ORPort using an explicit IPv6 address.
ORPort same as above.
Have you tried explicit IPv4 or IPv6 addresses?
Having to actually hard-code ipv6 (in the dynamic nature that it is) in the config files is a pure failure, and I ended up writing a way too annoying template file to fill it in a boot, simply because Tor can't bind to a port when it's told.
The current default is IPv4 0.0.0.0, as documented in the ORListenAddress man page entry.
Tor doesn't detect your IPv6 address at the moment, so you have to supply it explicitly. There's an open ticket for that, but address autodetection is fraught with confusion. We really do encourage operators to provide explicit, known stable addresses.
Although it looks like we could also improve the resolution and binding when relay operators supply a domain name. Feel free to open a ticket with the issues that you're seeing: https://trac.torproject.org/
My general consensus from last I looked in depth at this is that "Tor doesn't support ipv6. It claims to, but it doesn't."
Choosing anonymous, random paths through a non-clique network (mixed IPv4-only, dual-stack, and IPv6-only) is an open research problem. We can't really implement IPv6-only relays until there are some reasonable solutions to this issue. Until then, we have dual-stack relays.
And IPv6-only Tor clients can connect using IPv6 bridges, or bootstrap over IPv6 with ClientUseIPv4 0 and UseMicrodescriptors 0.
That's pretty much the limit of what we can do with IPv6, until researchers come up with solutions to the non-clique issue.
You can fix the daemon to actually be capable of binding to ports, and to not require us to jump through annoying settings just to get it to even _listen_ to ipv6.
IPv6 DirPorts are not used.
IPv6 ORPorts work like this:
ORPort [IPv6 address]:Port
I'm not sure what we could improve, given that the operator really needs to nominate a stable IPv6 address.
How much downtime can the node have before losing consensus weight/flags?
A restart loses the HSDir flag for 72 hours, and the Guard flag for a period that is dependent on how old your relay is. (It should be inversely related, currently it seems to be positively correlated, which is a bug we're working on fixing.)
Is it just for restarting the tor process as well?
Yes. Try sending it a HUP instead, when you've just changed the config.
HUP appearantly isn't enough to not make it restart when it's resolving addresses on ipv4/ipv6. Turns out its closing sockets first, then resolving the domainnames, realizing it can't listen, and then stop.
Yes, there's an open ticket for one case where 0.0.0.0 and a particular IPv4 address overlap. You might have just discovered another one.
I'd encourage you to log a ticket with more detail at: https://trac.torproject.org/
Or, if you let me know a few more details, I can log one for you. What's the config? What are the log messages?
I'd avoid the reboots if you can, there's a known bug affecting at least the Guard flag and restarts, where a long-lived stable relays are disproportionately impacted compared with new relays. I haven't seen any evidence that it affects other flags or consensus weight, but you could try not restarting and see if that helps.
Right, I can tune that for a week and see.
Thanks. Hope it works out for you.
Me too, I'm hoping to see what the heck is going on to get a stable load before I start adding more relays/exits.
The performance characteristics of an exit are... not very well documented.
Typically, exit bandwidth is rare in the Tor network, and tends to be over-utilised. So any issues using Exits to their full potential disproportionately impact Tor users.
We would love some help with investigating and documenting Exit performance!
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org