[tor-bugs] #29570 [Core Tor/Tor]: Enforce mutually exclusive logic for IPv6 ORPort flags

[Tor Bug Tracker & Wiki]

#29570: Enforce mutually 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                               |     Resolution:
 Keywords:  tor-relay, ipv6, reachability,       |  Actual Points:
  needs-proposal-or-tor-dev-email                |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by AVee):

 I'll summarize my take on this.

 Assuming as fact:
 - Tor treats all incoming data the same independently of the socket it
 arrived on, so nothing breaks if data which was originally send to IPv6
 arrives in Tor on an IPv4 socket (or vice-versa).
 - The load on consensus data, authorities etc. caused by an advertised
 address is the same for any ''functioning'' address independently of how
 the relay operator sets things up. I.e. forwarding IPv6 to IPv4 does not
 change descriptors, reachability checks etc.

 Assuming as valid goals for Tor:
 - Any properly functioning relay added to the network is desirable,
 regardless of how the operator made it work. Tor does not ''enforce'' any
 opinion on network (or OS, or hardware) choices.
 - Being able to fully separate where Tor is ''listening'' and what it
 ''advertises'' is desirable because it gives relay operators maximum
 flexibility to set up their networking according to their needs.

 Therefore:
 - It's OK to advertise an address family even when the node is not
 listening at that family because it can be made reachable in other ways.
 - The man page does not mention anything which would suggest otherwise, so
 there is no bug there.
 - The description of the `NoListen` flag clearly indicates reachability is
 expected to be achieved through other means, so there's no need for
 improvement there.
 - There is no indication this is a common source of configuration errors,
 so there is no need to take drastic measures here because it causes
 excessive load somewhere else.

 That said, there are separate things which may be worth looking into (as
 separate issues):
 - The connectivity check for IPv6 seems to take several days, giving nodes
 a `UnreachableIpv6` flag in the mean time. This causes operators to start
 looking for errors in their setup even though it is correct. It even
 causes operators to give up on IPv6 altogether.
 - If there specific configurations which are often causing invalid
 addresses to be advertised it could be worth while putting effort into
 preventing that. But that should (imho) be a more generic solution for all
 common errors, not something specific to this case.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29570#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online