Skip to content
Snippets Groups Projects
New look: Off

Let relays bind and declare IPv6 addresses

    • Closed (moved) Issue created by Linus Nordberg @linus
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • Linus Nordberg added SponsorG20120930 component::core tor/tor owner::ln5 parent::4564 priority::medium resolution::implemented status::closed tor-relay type::enhancement labels

      added SponsorG20120930 component::core tor/tor owner::ln5 parent::4564 priority::medium resolution::implemented status::closed tor-relay type::enhancement labels

    • L
      Linus Nordberg @linus ·
      Author

      Trac:
      Component: - Select a component to Tor Relay

    • L
      Linus Nordberg @linus ·
      Author

      Trac:
      Milestone: N/A to Sponsor G: September 30, 2012
      Type: defect to enhancement

    • Karsten Loesing
      Karsten Loesing @karsten ·

      Switching from using milestones to keywords for sponsor deliverables. See #6365 (moved) for details.

      Trac:
      Milestone: Sponsor G: September 30, 2012 to N/A
      Keywords: N/A deleted, SponsorG20120930 added

    • L
      Linus Nordberg @linus ·
      Author

      Pushed the minimal change for letting all relays bind to and advertise an IPv6 OR port.

      Note that we're not able to do any self-testing until we have the EXTEND2 cell type (prop200). We do verify that the port can be bound to.

      Trac:
      Status: new to needs_review

    • L
      Linus Nordberg @linus ·
      Author

      Replying to ln5:

      Pushed the minimal change for letting all relays bind to and advertise an IPv6 OR port.

      Branch bug6362 in my public repo.

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Seems plausible. Was there a reason you said this wasn't ready yet other than the self-testing issue?

      Also, is there any risk of unintentionally getting an ipv6 address when you didn't mean to? If so, this patch is a little risky: it might make a working node accidentally advertise a non-working IPv6 address, thus getting the 0.2.4 authorities to mark it as down.

    • L
      Linus Nordberg @linus ·
      Author

      Replying to nickm:

      Seems plausible. Was there a reason you said this wasn't ready yet other than the self-testing issue?

      Is it possible that you're mixing up #6362 (moved) and #6363 (moved) (Make directory authorities vote on "a" lines in consensus network status documents). The latter lacks support for microdescriptors.

      Also, is there any risk of unintentionally getting an ipv6 address when you didn't mean to? If so, this patch is a little risky: it might make a working node accidentally advertise a non-working IPv6 address, thus getting the 0.2.4 authorities to mark it as down.

      At the moment, no. Advertising an IPv6 address requires not only that what's given in an ORPort option parses into AF_INET6 but also that it passed !tor_addr_is_internal() with 'for_listening==0, i.e. is not "[::]" (see #5146 (moved)). This might change when we fix #5940 (moved) (which needs design love btw).

      A related question is how we should treat "ORPort 4711" on a system with an IPv6 address. This is unresolved in prop186 -- should the 'AllAddrs' option be on by default?

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Replying to ln5:

      Replying to nickm:

      Seems plausible. Was there a reason you said this wasn't ready yet other than the self-testing issue?

      Is it possible that you're mixing up #6362 (moved) and #6363 (moved) (Make directory authorities vote on "a" lines in consensus network status documents). The latter lacks support for microdescriptors.

      You said:

      10:43 < ln5> nickm: #6621, #6362, #6363 (the last two probably not ready for merge yet, but feedback would be valuable)

      I read that as saying that #6362 (moved) (this ticket) was probably not ready for merge.

      Also, is there any risk of unintentionally getting an ipv6 address when you didn't mean to? If so, this patch is a little risky: it might make a working node accidentally advertise a non-working IPv6 address, thus getting the 0.2.4 authorities to mark it as down.

      At the moment, no. Advertising an IPv6 address requires not only that what's given in an ORPort option parses into AF_INET6 but also that it passed !tor_addr_is_internal() with 'for_listening==0, i.e. is not "[::]" (see #5146 (moved)). This might change when we fix #5940 (moved) (which needs design love btw).

      Okay. So, I don't know a reason not to merge this then.

      A related question is how we should treat "ORPort 4711" on a system with an IPv6 address. This is unresolved in prop186 -- should the 'AllAddrs' option be on by default?

      Eventually, yes! But not before self-testing can work, or there will be trouble.

      Last question: How tested is this?

    • L
      Linus Nordberg @linus ·
      Author

      Replying to nickm:

      10:43 < ln5> nickm: #6621, #6362, #6363 (the last two probably not ready for merge yet, but feedback would be valuable)
}}}

I read that as saying that #6362 (this ticket) was probably not ready for merge.

      You're right. I don't understand my own statement now. I think that this can be merged. Sorry for the confusion.

      Last question: How tested is this?

      I've been running it in a private test network for a couple of days, together with other changes related to #4564 (moved). There are 11 relays in all and three clients in the network. Things seem to be working fine. The only thing that puzzles me right now is that relays log

      {{{ Aug 21 18:12:44.000 [warn] No available nodes when trying to choose node. Failing. Aug 21 18:12:44.000 [warn] No available nodes when trying to choose node. Failing. Aug 21 18:12:44.000 [warn] Failed to find node for hop 0 of our path. Discarding this circuit.

      
which indicates that they have trouble finding an entry node.

I should try to isolate that before we merge this, or at least verify
that it's not because of the changes in this branch.


**Trac**:  
**Status**: needs_review **to** needs_revision
    • L
      Linus Nordberg @linus ·
      Author

      Last question: How tested is this?

      I've been running it in a private test network for a couple of days, together with other changes related to #4564 (moved). There are 11 relays in all and three clients in the network. Things seem to be working fine. The only thing that puzzles me right now is that relays log

      {{{ Aug 21 18:12:44.000 [warn] No available nodes when trying to choose node. Failing. Aug 21 18:12:44.000 [warn] No available nodes when trying to choose node. Failing. Aug 21 18:12:44.000 [warn] Failed to find node for hop 0 of our path. Discarding this circuit. }}}

      which indicates that they have trouble finding an entry node.

      I should try to isolate that before we merge this, or at least verify that it's not because of the changes in this branch.

      (Correction on the number of relays in the test network: There are 9 ordinary relays and 2 bridges running.)

      This problem disappeared when I reset and bootstrapped the network and undid some configuration changes like 'AssumeReachable 0' (dirauths and relays) and 'UseMicrodescriptors 0' (relays).

      Not really sure what happened there but it is hardly related to relays advertising IPv6 addresses -- I have that running now without any fuzz.

      Trac:
      Status: needs_revision to needs_review

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Okay; merged. thanks!

      Trac:
      Resolution: N/A to implemented
      Status: needs_review to closed

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Trac:
      Keywords: SponsorG20120930 deleted, SponsorG20120930 tor-relay added

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Trac:
      Component: Tor Relay to Tor

    • Trac closed

      closed

    • Trac moved to tpo/core/tor#6362 (closed)

      moved to tpo/core/tor#6362 (closed)

    Please register or sign in to reply