Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#6362 closed enhancement (implemented)

Let relays bind and declare IPv6 addresses

Reported by: ln5 Owned by: ln5
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: SponsorG20120930 tor-relay
Cc: Actual Points:
Parent ID: #4564 Points:
Reviewer: Sponsor:

Description


Child Tickets

Change History (13)

comment:1 Changed 7 years ago by ln5

Component: - Select a componentTor Relay

comment:2 Changed 7 years ago by ln5

Milestone: Sponsor G: September 30, 2012
Type: defectenhancement

comment:3 Changed 7 years ago by karsten

Keywords: SponsorG20120930 added
Milestone: Sponsor G: September 30, 2012

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

comment:4 Changed 7 years ago by ln5

Status: newneeds_review

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.

comment:5 in reply to:  4 Changed 7 years ago by ln5

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.

comment:6 Changed 7 years ago by 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.

comment:7 in reply to:  6 ; Changed 7 years ago by 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 and #6363 (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). This might change when we fix #5940 (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?

comment:8 in reply to:  7 ; Changed 7 years ago by 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 and #6363 (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 (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). This might change when we fix #5940 (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?

comment:9 in reply to:  8 ; Changed 7 years ago by ln5

Status: needs_reviewneeds_revision

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. 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.

comment:10 in reply to:  9 Changed 7 years ago by ln5

Status: needs_revisionneeds_review

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. 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.

comment:11 Changed 7 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Okay; merged. thanks!

comment:12 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:13 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.