[tor-bugs] #23493 [Core Tor/Tor]: IPv6 v3 Single Onion Services fail with a bug warning

[Tor Bug Tracker & Wiki]

#23493: IPv6 v3 Single Onion Services fail with a bug warning
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:                                       |         Points:  1
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by dgoulet):

 Replying to [comment:4 teor]:
 > Replying to [comment:2 dgoulet]:
 > > Oh dear... hmmm proposal 224 makes IPv4 *mandatory* in order to extend
 to the relay and seems in this case you have IPv6 only?...
 >
 > The single onion service in this test can only make IPv6 connections.
 > This works for v2, but not v3.
 >
 > > Is this something we want to allow right now or should I say simply
 possible to have NO IPv4 for a relay?
 >
 > We can make IPv6 work with single-hop client and service connections to
 intro and rend points. It works for v2 single onion services. We talked
 about it for v3, but it never made it into the prop224 spec.

 Yeah, it will make it with #23502. Spec and code change for that matter.
 Basically, any link specifiers for the IP (in descriptor) and RP (in INTRO
 cell) were requiring an IPv4 else you couldn't use the relay.

 >
 > Edit: I opened #23507 with a list of steps we can add to the spec. We
 should implement them in this ticket!
 >
 > I don't see how #23502 is a dependency. Initiating clients/services
 should always include IPv4 and IPv6, even if they wouldn't use them (step
 0). And responding clients/services should use a direct connection if
 available, or a 3-hop connection if not (steps 1 & 2).

 In this scenario, no IPv4 were available with this chutney test so the
 code was just saying "nope" and you wouldn't pass step 0 which is what
 #23502 is addressing.

 Then considering the above fixed, you are right that if the chosen IP
 can't be reached via a direct connection, we fallback to 3-hop, see
 `pick_intro_point()`. However, for the RP, I'm not sure there is a
 fallback, even for v2... See `pick_rendezvous_node()`, that fallback
 concept is only if `ENABLE_TOR2WEB_MODE`.

 The second thing here that I want to raise is that including both IPv4 and
 IPv6 is *not* possible right now within tor and the reason is that from a
 `node_t`, we create an `extend_info_t` object used for opening a circuit
 and that object can only take one type of address, v4 or v6 (`tor_addr_t
 addr`). Furthermore, the `extend_cell_format()` simply doesn't care at all
 about IPv6. (#22810 is probably relevant and should be expanded to IPv6
 also).

 So, IPv6 can only be used in a direct connection really and is entirely
 ignored for 3-hop.

 If you can confirm the above, we should open tickets about all that.

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