[tor-relays] ipv6 behaviour consensus

Charly Ghislain charlyghislain at gmail.com
Fri Apr 19 00:20:52 UTC 2019


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 at 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 at lists.torproject.org> *On Behalf
> Of *Charly Ghislain
> *Sent:* Thursday, April 18, 2019 2:41 PM
> *To:* tor-relays at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20190419/7d965453/attachment-0001.html>


More information about the tor-relays mailing list