Re: [tor-relays] ipv6 behaviour consensus

Subject: Re: [tor-relays] ipv6 behaviour consensus

From: Charly Ghislain <charlyghislain@xxxxxxxxx>

Date: Fri, 19 Apr 2019 01:08:42 +0300

Delivery-date: Thu, 18 Apr 2019 18:09:07 -0400

Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IQ0KghW58qKVket/5aHslpaX94c5nnTYdVkp/w85dag=; b=G9DOzmsRKwMjq7dbnys8S+pJgxJXxKOonmNFKVYrJUAksAymHg5wQxBQFwlA3AmSVH wQ0EOjfqF6UMtHT8tbiASbnSOB87uZAy3qHD8gAYBD9DesflJGFE8OEi/89PSk8PQ2NY wosrwaiv1m5gQI/M0T8nk5DstuV4VzL3cIkVB+TxeMBYNqfDMMv1z+t+uwY90/KTFrjp 1SG4sNWhkOYvNbKiKuZSE2dzfJCr2WnXIjVRmCbSQq/phpsyFs6x3cbyDaxlJs5lVZZ+ fQYkW6pJE34nJWbsZe3i3WljZtQqThXP+12Ul/NdiQRUxse5jBOsC0BvoeNYx2DrPIbc BLiA==

In-reply-to: <CAGOcNEZDcOuetuv8AF-VLQXOPWnAfoh9SYJMzbWqw7zJ=J_ODA@mail.gmail.com>

List-archive: <http://lists.torproject.org/pipermail/tor-relays/>

List-help: <mailto:tor-relays-request@lists.torproject.org?subject=help>

List-id: "support and questions about running Tor relays \(exit, non-exit, bridge\)" <tor-relays.lists.torproject.org>

List-post: <mailto:tor-relays@lists.torproject.org>

List-subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>, <mailto:tor-relays-request@lists.torproject.org?subject=subscribe>

List-unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-relays>, <mailto:tor-relays-request@lists.torproject.org?subject=unsubscribe>

References: <CAGOcNEZDcOuetuv8AF-VLQXOPWnAfoh9SYJMzbWqw7zJ=J_ODA@mail.gmail.com>

Reply-to: tor-relays@xxxxxxxxxxxxxxxxxxxx

Sender: "tor-relays" <tor-relays-bounces@xxxxxxxxxxxxxxxxxxxx>

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@xxxxxxxxx> 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

_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays