#29570: Enforce emutually exclusive logic for IPv6 ORPort flags ------------------------------+------------------------------------------- Reporter: s7r | Owner: (none) Type: defect | Status: new Priority: Medium | Milestone: Tor: unspecified Component: Core Tor/Tor | Version: Tor: unspecified Severity: Normal | Keywords: tor-relay, ipv6, reachability Actual Points: | Parent ID: Points: | Reviewer: Sponsor: | ------------------------------+------------------------------------------- For details:
https://lists.torproject.org/pipermail/tor- relays/2019-February/016988.html and my reply: https://lists.torproject.org/pipermail/tor- relays/2019-February/016991.html This is one rare and strange setup of using IPv6 in a way it is not intended, but we should still make sure that: - if ORPort [IPv6:address::x]:port '''NoListen''' was set in torrc, and there is no following ORPort [IPv6:address::y]:port '''NoAdvertise''' or [::]:port '''NoAdvertise''' (as in use all available IPv6 addresses) is set, warn in the log and '''do not build the descriptor using the NoListen address''', since the daemon is not listening on any address from the v6 class. - check if the logic is applied for IPv4 also, even it's impossible to experience this in IPv4 since UnreachableIPv4 doesn't exist and can't possibly exist. Otherwise we fill the descriptor with useless data and also have the directory authorities chase green horses. I think we have this since forever, but not marking this as a backport given the rare cases when it can occur and the state of current IPv6 adoption. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29570> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs