mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-28 14:23:30 +01:00
87 lines
3.0 KiB
Plaintext
87 lines
3.0 KiB
Plaintext
Filename: 118-multiple-orports.txt
|
|
Title: Advertising multiple ORPorts at once
|
|
Version: $Revision$
|
|
Last-Modified: $Date$
|
|
Author: Nick Mathewson
|
|
Created: 09-Jul-2007
|
|
Status: Accepted
|
|
Target: 0.2.1.x
|
|
|
|
Overview:
|
|
|
|
This document is a proposal for servers to advertise multiple
|
|
address/port combinations for their ORPort.
|
|
|
|
Motivation:
|
|
|
|
Sometimes servers want to support multiple ports for incoming
|
|
connections, either in order to support multiple address families, to
|
|
better use multiple interfaces, or to support a variety of
|
|
FascistFirewallPorts settings. This is easy to set up now, but
|
|
there's no way to advertise it to clients.
|
|
|
|
New descriptor syntax:
|
|
|
|
We add a new line in the router descriptor, "or-address". This line
|
|
can occur zero, one, or multiple times. Its format is:
|
|
|
|
or-address SP ADDRESS ":" PORTLIST NL
|
|
|
|
ADDRESS = IP6ADDR / IP4ADDR
|
|
IPV6ADDR = an ipv6 address, surrounded by square brackets.
|
|
IPV4ADDR = an ipv4 address, represented as a dotted quad.
|
|
PORTLIST = PORTSPEC | PORTSPEC "," PORTLIST
|
|
PORTSPEC = PORT | PORT "-" PORT
|
|
|
|
[This is the regular format for specifying sets of addresses and
|
|
ports in Tor.]
|
|
|
|
New OR behavior:
|
|
|
|
We add two more options to supplement ORListenAddress:
|
|
ORPublishedListenAddress, and ORPublishAddressSet. The former
|
|
listens on an address-port combination and publishes it in addition
|
|
to the regular address. The latter advertises a set of address-port
|
|
combinations, but does not listen on them. [To use this option, the
|
|
server operator should set up port forwarding to the regular ORPort,
|
|
as for example with firewall rules.]
|
|
|
|
Servers should extend their testing to include advertised addresses
|
|
and ports. No address or port should be advertised until it's been
|
|
tested. [This might get expensive in practice.]
|
|
|
|
New authority behavior:
|
|
|
|
Authorities should spot-test descriptors, and reject any where a
|
|
substantial part of the addresses can't be reached.
|
|
|
|
New client behavior:
|
|
|
|
When connecting to another server, clients SHOULD pick an
|
|
address-port ocmbination at random as supported by their
|
|
reachableaddresses. If a client has a connection to a server at one
|
|
address, it SHOULD use that address for any simultaneous connections
|
|
to that server. Clients SHOULD use the canonical address for any
|
|
server when generating extend cells.
|
|
|
|
Not addressed here:
|
|
|
|
* There's no reason to listen on multiple dirports; current Tors
|
|
mostly don't connect directly to the dirport anyway.
|
|
|
|
* It could be advantageous to list something about extra addresses in
|
|
the network-status document. This would, however, eat space there.
|
|
More analysis is needed, particularly in light of proposal 141
|
|
("Download server descriptors on demand")
|
|
|
|
Dependencies:
|
|
|
|
Testing for canonical connections needs to be implemented before it's
|
|
safe to use this proposal.
|
|
|
|
|
|
Notes 3 July:
|
|
- Write up the simple version of this. No ranges needed yet. No
|
|
networkstatus chagnes yet.
|
|
|