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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

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

Comment (by s7r):

 Not really. IPv4 is scarce, limited resources. NAT is a hack to get around
 this, and it's quite useful because THERE IS NO OTHER WAY to have multiple
 boxes if you have just one public IPv4, as most providers default to.

 In IPv6 however, this is not the case. To the contrary that its 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.

 Nobody is happy about NAT. In fact, everyone indicates to avoid it. That
 is why IPv6 came along. NAT is just a necessary evil, a hack that was made
 so things can go on. Obviously we don't have a choice in NOT supporting
 it. But we do have a choice for IPv6, and we should. Have you ever
 questioned why IPv6 does not support NAT? Not because it was hard to
 implement of course, but because it's evil and is best to be avoided.
 There's nothing that we can do f or the legacy IPv4 internet, but let's
 not turn IPv6 into the same.

 Why would you want to pretend to listen on an IPv6 address if you have no
 open socket for it? It just doesn't make any sense. How is that better
 than just listening on IPv4? 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. Basically follow the industry standard RFCs and recommendation +
 prevent users to make accidental mistakes and fill the consensus with
 garbage. Right now I configure an IPv6 NoListen ORPort and that gets
 filled in the consensus,  and I spend resources of directory authorities
 trying to test if it is reachable and also eat up even more space by
 having to be assigned with an additional UnreachableIPv6 flag. All this
 because something we say in the manual (mutually exclusive flags for torrc
 options) are not properly sanitized at start-up.

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

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