[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):

 Replying to [comment:14 s7r]:

 We're running in circles here. You don't need to explain IPv6 to me, I've
 had native IPv6 since 2011 and tunnels before that. You don't need to
 argue the case that IPv6 is intended to bring full end-to-end connectivity
 back, I agree and would love to see that happen.

 > In IPv6 however, this is not the case. In addition that this is not the
 case, it is also NOT RECOMMENDED by any RFC to do this. With what you are
 saying, just because you think it's ok "as long as it works and the relay
 is willing to do it" you contradict all the RFCs.

 Let me quote an RFC then:
   4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.
    https://www.ietf.org/rfc/rfc2119.txt

 We should stick to that. We must not make it impossible to do this as
 'there may exist valid reasons in particular circumstances' to do this.
 And even if you feel no valid reason could ever exist, Tor is not the IPv6
 police so it still isn't up to us to enforce anything there.

 The proof of the pudding is in the eating. We have one example of this
 config. It may not be optimal, it may be utterly different from how I
 would have done it. But it worked, therefore it is valid, therefore it
 should be allowed.

 (On a more philosophical note, I feel it would be counter productive as
 well. You add extra barriers to people trying to get a Tor relay running
 as well as for people trying to get experience with IPv6. Allowing them to
 do it in a sub-optimal way and learn from that is far more useful then
 trying to force them to get it right the first time around.)

 > Why would you want to pretend to listen on an IPv6 address if you have
 no open socket for it?

 The Tor man page explains that nicely (emphasis mine):
     NoListen:
     By default, we bind to a port and tell our users about it. If
     NoListen is specified, we don't bind, but advertise anyway.  This
     can be useful **if something else  (for example, a firewall's port
     forwarding configuration) is causing connections to reach us.**

 In this case HAProxy was the 'something else'...

 > All this ticket recommends is, if you are willing to set an IPv6
 NoListen address, also set a NoAdvertise one, if you're willing to
 redirect and tunnel that somehow it's still OK but at least don't
 advertise an address class if you have no listening socket for it.

 So the if someone uses HAProxy (or anything else) to redirect IPv6 traffic
 to IPv4 he should configure his node to still listen on a IPv6 port even
 though it will never see any traffic?

 > All this because something we say in the manual (mutually exclusive
 flags for torrc options) are not properly sanitized at start-up.

 I guess you refer to this phrase in the man page:
     For obvious reasons, NoAdvertise and NoListen are mutually exclusive,
 ...

 That only states a {{{ORPort}}} line that sets {{{NoAdvertise}}} cannot
 also set {{{NoListen}}} (and vice-versa). This rule was not violated in
 the config in question.

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