Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3785 closed task (implemented)

Write proposal 186 to replace 118, and implement it

Reported by: ln5 Owned by: nickm
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay
Cc: ln5 Actual Points:
Parent ID: #3563 Points:
Reviewer: Sponsor:

Description

  • proposal 118 revised/reworked: listen on and advertise multiple orports; support microdescriptors [oct 1, nickm]
  • implementation of prop 118 []

Child Tickets

Change History (13)

comment:1 Changed 8 years ago by nickm

Status: newaccepted

comment:2 Changed 8 years ago by nickm

This is revised as proposal 186; not yet implemented. I really need comment on proposal 186.

comment:3 Changed 8 years ago by nickm

See branch prop186_hacking in my public repository for a partial implementation of the minimum needed to implement this, proposal #3787, and #3788 .

I'm not putting this into "needs_review" yet, because there are lots more known problems to solve here. But you can review it if you want!

Let me copy-and-paste my caveats and notes from IRC:

22:59 < nickm> It implements the new options insofar as letting you bind on 
               multiple orports.
22:59 < nickm> It also migrates dirport and controlport to the new port 
               configuration system because why not
23:00 < nickm> It lets routerinfo_t support exactly one IPv6 address, as a 
               stopgap measure.
23:01 < nickm> It handles parsing and formatting such routerinfo_t instances

Additionally, since then, I added a commit so that bridges with an IPv6 address will advertise it in their router descriptor (#3788) .

comment:4 Changed 8 years ago by ln5

Cc: ln5 added

We should implement (parts of) prop 186 in order to make bridges only
on IPv6 happy.

From 186-multiple-orports.txt:

{Until support is added for extend cells to IPv6 addresses, it
will only be possible to test IPv6 addresses by connecting
directly. We might want to just skip self-testing those until we
have IPv6 extend support.}

How bad is it to advertise an addr:port without self-testing it first?

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

The proposal seems to have discontinued the 'auto' argument for the
ORPort option. Wouldn't that break old configuration pretty badly?
Or do we not care about backward compatibility regarding torrc?

If it is indeed gone, connection_get_by_type() should be rewritten.

comment:6 Changed 8 years ago by ln5

Tor isn't automatically aware of its IPv6 address yet. It's not
necessary for getting an ORPort to listen an IPv6 address since
'ORPort [<addr>]:<port>' works just fine. But 'ORPort <port>' binds
only to the IPv4 address.

comment:7 in reply to:  4 ; Changed 8 years ago by nickm

Replying to ln5:

How bad is it to advertise an addr:port without self-testing it first?

For a bridge, bad, but not terrible.

Replying to ln5:

The proposal seems to have discontinued the 'auto' argument for the
ORPort option. Wouldn't that break old configuration pretty badly?

I think that's an oversight; we should continue to support auto. I'll try to edit the proposal soon in light of that and other comments.

Replying to ln:

But 'ORPort <port>' binds only to the IPv4 address

Hm. What about ORPort <port> IPv6Only , or ORPort [::]:<port> ?

One of the hard-to-implement thing in proposal 186 is the ability to have one ORPort directory specify more than one actual port; it will break the current one-to-one relation between listener sockets, port_cfg_t entries, and ORPort lines. (So it's _doable_, but not necessarily fun.)

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

Replying to nickm:

Hm. What about ORPort <port> IPv6Only , or ORPort [::]:<port> ?

--ORPort "4700 IPv6Only" ==>
Nov 19 23:46:13.263 [warn] Could not interpret ORPort address as IPv4

--ORPort "[::]:4700" ==> works

comment:9 Changed 8 years ago by nickm

Status: acceptedneeds_review
Summary: Revise/refine proposal 118 and implement itWrite proposal 186 to replace 186, and implement it

(This is currently partially done in my prop186_hacking branch, which ln5 is basing some work on)

comment:10 Changed 8 years ago by nickm

Summary: Write proposal 186 to replace 186, and implement itWrite proposal 186 to replace 118, and implement it

comment:11 Changed 8 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

My existing code for 186 is merged as part of #3786 . I should complete or disable the remaining parts for 0.2.3.x-rc: see #4613 and #4614 for that.

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.