[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:
Parent ID:                                 |         Points:
 Reviewer:                                 |        Sponsor:
-------------------------------------------+-------------------------------

Comment (by AVee):

 Do you agree on this? Firstly, this example shows a relay which is
 functioning correctly on both IPv6 and IPv4. Secondly, if this change is
 implemented this relay would not start up anymore.

 Right there is my main issue with this, it simply isn't true this config
 is ''always'' invalid. The change as proposed would break a currently
 correctly functioning relay. I don't think that's a good thing to do.
 Also, in my mind at least, it pretty clear what's going on in this config.
 If you use {{{NoListen}}} you need to make sure traffic to that ip/address
 reaches your relay in some way. Tor should not have a opinion on the how,
 as long as it works. And that's what the reachability check is for.

 If you really want to go further there should still be a way to get a
 setup like this running anyway. The {{{Advertise6to4OrportAddress}}}
 config parameter would work for this specific case. A more generic
 solution would be a {{{YesIHaveSeenTheConfigWarnings}}} flag. You could
 have a category of "this is probably wrong, are you really sure" warnings
 on which Tor fails to start until the flag is set. That way errors are
 still caught early (and loudly), but 'weird' setups can still be made to
 work. That mechanism could then be applied to any common source of config
 errors...

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