ipv6 behaviour consensus
Hi list, Last reply from s7r on jake Visser' issue included a link to an open issue waiting for a consensus on a mailing list: https://trac.torproject.org/projects/tor/ticket/29570 Not sure if teor implied the dev mailing list or this one, but maybe gathering feedback from operators is a good idea. AFAIC, as avee stated on the ticket I don't find the current setup much confusing. The documentation on ipv6 setup was not as clear as one would expect, I came across what appeared to be outdated docs, and I think this is the area that could be improved to eases operator setup. I agree with Avee that any update on that matter should be backward compatible, allowing relays running behind custom natted networks to continue operating without any trouble. I feel there is an issue in case the operator advertises an unreachable ip6 address in the config. This seems like a configuration error that should be spotted by a self-reachability mechanism that is yet to come, like for ipv4. I can imagine however that directories could be able to flag the relay as reachable over ipv4 and not over ipv6, and that the relay would still be usable over ip4. I thought it was the case actually. Please provide your feedback. ip6 is around for so long, it is depressing to see how hard it is for so many software to provide a nice user experience with it. Regards, Charly
selfreplying as I hadn't read the whole ticket thread at the time of writing (still haven't, tbh). I think there are real reason to use natted traffic in this period of transition toward ip6 and that must be supported. My setup (ha proxy litening on both interfaces, tor relay listening on ip4 only) was used because tor is running in a containerized environment, heavily relying on natted ipv4 networks to route the traffic to the correct container, which might run on another host. Corporates still use internal ip4 vpn/firewalls, with load balancers accepting ip6 traffic. For many other reasons, the ip/interface/port you are listening to might be very different than the one you publicly advertise. Lets keep it that way. On Fri, Apr 19, 2019 at 12:41 AM Charly Ghislain <charlyghislain@gmail.com> wrote:
Hi list,
Last reply from s7r on jake Visser' issue included a link to an open issue waiting for a consensus on a mailing list:
https://trac.torproject.org/projects/tor/ticket/29570
Not sure if teor implied the dev mailing list or this one, but maybe gathering feedback from operators is a good idea.
AFAIC, as avee stated on the ticket I don't find the current setup much confusing. The documentation on ipv6 setup was not as clear as one would expect, I came across what appeared to be outdated docs, and I think this is the area that could be improved to eases operator setup.
I agree with Avee that any update on that matter should be backward compatible, allowing relays running behind custom natted networks to continue operating without any trouble.
I feel there is an issue in case the operator advertises an unreachable ip6 address in the config. This seems like a configuration error that should be spotted by a self-reachability mechanism that is yet to come, like for ipv4. I can imagine however that directories could be able to flag the relay as reachable over ipv4 and not over ipv6, and that the relay would still be usable over ip4. I thought it was the case actually.
Please provide your feedback. ip6 is around for so long, it is depressing to see how hard it is for so many software to provide a nice user experience with it.
Regards,
Charly
Hello, Charly Ghislain wrote:
selfreplying as I hadn't read the whole ticket thread at the time of writing (still haven't, tbh).
I think there are real reason to use natted traffic in this period of transition toward ip6 and that must be supported. My setup (ha proxy litening on both interfaces, tor relay listening on ip4 only) was used because tor is running in a containerized environment, heavily relying on natted ipv4 networks to route the traffic to the correct container, which might run on another host. Corporates still use internal ip4 vpn/firewalls, with load balancers accepting ip6 traffic.
For many other reasons, the ip/interface/port you are listening to might be very different than the one you publicly advertise. Lets keep it that way.
I totally agree. But why would you want to advertise an IPv6 ORPort if your Tor daemon only truly has IPv4 socket? This is what I don't understand. Why would one want that? Just to look neat in the consensus? It's like having a Diesel car, but buying gasoline and exchanging that at the corner for Diesel with another person (in the context where both products have equal cost, and there is no additional gain by doing this effort). IPv6 is optional for the time being when running a Tor relay. Two basic purposes IPv6 was designed for are: - eliminate the need for NAT - nobody is happy about it. It was just a necessary evil at the time, to ensure keep things on going on IPv4; - ensure better end-to-end connectivity; There are so many ways to properly do it. Like encapsulate traffic, 6-in-4 tunnels, etc. etc. , many ways that would allow the Tor host to actually have an IPv6 socket. Having an application advertising it is reachable on an address class, but not having an open socket (not listening anywhere) on that other class is confusing, wrong and breaks logic. It hasn't anything to do with the fact that migration solutions are needed for quite some time in the future. On this I agree, but there are plenty of solutions that will allow Tor to behave logically and ask one open socket from the family it is advertising to authorities, like use a tunnel or transparent encapsulation method. If a Tor daemon doesn't actually have (listen) on IPv6, and some middle box does the translation and forwards to the same v4 socket already advertised in the consensus as IPv4, what is the use for it? It's useless, it adds data to the consensus. I know it works without problems, but I can't see the real use of it. One use I can think for this is in a world where an IPv6 only client gets to use such a relay as Guard, by connecting it to its advertised IPv6 address (regardless that will be actually converted to IPv4 before it hits the relay, this will be transparent to the client and will actually work). Is it worth it? I don't know, but I am looking forward to hear more opinions from people that know much more about this.
On Fri, 19 Apr 2019 01:46:19 +0300 s7r <s7r@sky-ip.org> wrote:
I totally agree. But why would you want to advertise an IPv6 ORPort if your Tor daemon only truly has IPv4 socket? This is what I don't understand. Why would one want that? Just to look neat in the consensus?
It is supported to advertise an IPv4 ORPort while my daemon only has an IPv6 socket. This is extremely useful for me and allows to still run Tor on some IPv6-only machines, working around Tor's lack of useful IPv6 support via the use of IPv4 load balancers at the frontend, and IPv4 NAT. There is no reason to specifically disallow a combination where IPv6 and IPv4 would be swapped compared to be above. You don't know what network conditions and configs people have (or have to put up with). -- With respect, Roman
Thanks Charly – yes.. in this case a flag or error in logging that IPv6 was not reachable would have saved me many hours of debugging (for us, this was an obscure IPv6 issue, where all other IPs on the same range work; it was broken as a function of a very restrictive ND policy on the firewall). So regardless of Full v6 support, or v6 only support [both are needed], at the very least some good logging to say if its failing would be great 😉 From: tor-relays <tor-relays-bounces@lists.torproject.org> On Behalf Of Charly Ghislain Sent: Thursday, April 18, 2019 2:41 PM To: tor-relays@lists.torproject.org Subject: [tor-relays] ipv6 behaviour consensus Hi list, Last reply from s7r on jake Visser' issue included a link to an open issue waiting for a consensus on a mailing list: https://trac.torproject.org/projects/tor/ticket/29570 Not sure if teor implied the dev mailing list or this one, but maybe gathering feedback from operators is a good idea. AFAIC, as avee stated on the ticket I don't find the current setup much confusing. The documentation on ipv6 setup was not as clear as one would expect, I came across what appeared to be outdated docs, and I think this is the area that could be improved to eases operator setup. I agree with Avee that any update on that matter should be backward compatible, allowing relays running behind custom natted networks to continue operating without any trouble. I feel there is an issue in case the operator advertises an unreachable ip6 address in the config. This seems like a configuration error that should be spotted by a self-reachability mechanism that is yet to come, like for ipv4. I can imagine however that directories could be able to flag the relay as reachable over ipv4 and not over ipv6, and that the relay would still be usable over ip4. I thought it was the case actually. Please provide your feedback. ip6 is around for so long, it is depressing to see how hard it is for so many software to provide a nice user experience with it. Regards, Charly
In reply to s7r, The reason I want my services to be reachable over ipv6 is just that we have to move on. IoT is at our door, and ip4 address space is exhausted. Indeed some client nowadays only have an ip6 interface. Maybe not in tor, as ip4 is still mandatory, but nevertheless, we all have to move that way. That is all. I want my services to be reachable over ip6. The reason I cannot make tor listen on a dedicated ip6 address is mentionned in my previous post: I deploy tor as a docker swarm service, and docker does not route ip6 traffic through its overlay network. I don't think this is useless. A lot of service sockets are not bound to a public interface. Many connections initiated by client end up at some frontend, and the network administrator should have the liberty to route that traffic the way they want, the way they can. On Fri, Apr 19, 2019 at 1:54 AM Jake Visser <jake@emeraldonion.org> wrote:
Thanks Charly – yes.. in this case a flag or error in logging that IPv6 was not reachable would have saved me many hours of debugging (for us, this was an obscure IPv6 issue, where all other IPs on the same range work; it was broken as a function of a very restrictive ND policy on the firewall).
So regardless of Full v6 support, or v6 only support [both are needed], at the very least some good logging to say if its failing would be great 😉
*From:* tor-relays <tor-relays-bounces@lists.torproject.org> *On Behalf Of *Charly Ghislain *Sent:* Thursday, April 18, 2019 2:41 PM *To:* tor-relays@lists.torproject.org *Subject:* [tor-relays] ipv6 behaviour consensus
Hi list,
Last reply from s7r on jake Visser' issue included a link to an open issue waiting for a consensus on a mailing list:
https://trac.torproject.org/projects/tor/ticket/29570
Not sure if teor implied the dev mailing list or this one, but maybe gathering feedback from operators is a good idea.
AFAIC, as avee stated on the ticket I don't find the current setup much confusing. The documentation on ipv6 setup was not as clear as one would expect, I came across what appeared to be outdated docs, and I think this is the area that could be improved to eases operator setup.
I agree with Avee that any update on that matter should be backward compatible, allowing relays running behind custom natted networks to continue operating without any trouble.
I feel there is an issue in case the operator advertises an unreachable ip6 address in the config. This seems like a configuration error that should be spotted by a self-reachability mechanism that is yet to come, like for ipv4. I can imagine however that directories could be able to flag the relay as reachable over ipv4 and not over ipv6, and that the relay would still be usable over ip4. I thought it was the case actually.
Please provide your feedback. ip6 is around for so long, it is depressing to see how hard it is for so many software to provide a nice user experience with it.
Regards,
Charly
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi,
On 19 Apr 2019, at 07:41, Charly Ghislain <charlyghislain@gmail.com> wrote:
I feel there is an issue in case the operator advertises an unreachable ip6 address in the config. This seems like a configuration error that should be spotted by a self-reachability mechanism that is yet to come, like for ipv4. I can imagine however that directories could be able to flag the relay as reachable over ipv4 and not over ipv6, and that the relay would still be usable over ip4. I thought it was the case actually.
We asked the directory authority operators what they wanted Tor to do when relays are reachable over IPv4 but not IPv6. They told us that the relays should not be in the consensus, because then operators would notice, and fix them. (As Jake Visser did.) We also talked with relay operators, and there were a range of different opinions. If we want to have enough IPv6 relays to support lots of IPv6 clients, we need every relay that can do IPv6, to have working IPv6.
On 19 Apr 2019, at 08:46, s7r <s7r@sky-ip.org> wrote:
One use I can think for this is in a world where an IPv6 only client gets to use such a relay as Guard, by connecting it to its advertised IPv6 address (regardless that will be actually converted to IPv4 before it hits the relay, this will be transparent to the client and will actually work).
I think having more ways to do IPv6 is useful as we transition to IPv6. When most relays support IPv6, we can start deprecating some of the less useful ways of doing IPv6. But we're not there yet.
On 19 Apr 2019, at 08:54, Jake Visser <jake@emeraldonion.org> wrote:
Thanks Charly – yes.. in this case a flag or error in logging that IPv6 was not reachable would have saved me many hours of debugging (for us, this was an obscure IPv6 issue, where all other IPs on the same range work; it was broken as a function of a very restrictive ND policy on the firewall).
So regardless of Full v6 support, or v6 only support [both are needed], at the very least some good logging to say if its failing would be great 😉
After a few hours, your relays should have warned you that they were not in the consensus. Maybe you missed the warning, because you were looking at debug logs? A relay can't tell you that its own IPv6 address is unreachable, because it never checks its IPv6 address for reachability. We have a ticket to implement IPv6 reachability checks, but it's more complex than you might expect, because relays don't extend to other relays over IPv6 yet. https://trac.torproject.org/projects/tor/ticket/24403 We're working on getting funding for IPv6 improvements in 2020, and this feature will be first. (There's no point in making clients do IPv6 better, if we don't have enough IPv6 relays.) T
participants (5)
-
Charly Ghislain -
Jake Visser -
Roman Mamedov -
s7r -
teor