doc/spec/proposals/118-multiple-orports.txt

   1 Filename: 118-multiple-orports.txt
   2 Title: Advertising multiple ORPorts at once
   3 Version: $Revision$
   4 Last-Modified: $Date$
   5 Author: Nick Mathewson
   6 Created: 09-Jul-2007
   7 Status: Accepted
   8 Target: 0.2.1.x
   9
  10 Overview:
  11
  12    This document is a proposal for servers to advertise multiple
  13    address/port combinations for their ORPort.
  14
  15 Motivation:
  16
  17    Sometimes servers want to support multiple ports for incoming
  18    connections, either in order to support multiple address families, to
  19    better use multiple interfaces, or to support a variety of
  20    FascistFirewallPorts settings.  This is easy to set up now, but
  21    there's no way to advertise it to clients.
  22
  23 New descriptor syntax:
  24
  25    We add a new line in the router descriptor, "or-address".  This line
  26    can occur zero, one, or multiple times.  Its format is:
  27
  28       or-address SP ADDRESS ":" PORTLIST NL
  29
  30       ADDRESS = IP6ADDR / IP4ADDR
  31       IPV6ADDR = an ipv6 address, surrounded by square brackets.
  32       IPV4ADDR = an ipv4 address, represented as a dotted quad.
  33       PORTLIST = PORTSPEC | PORTSPEC "," PORTLIST
  34       PORTSPEC = PORT | PORT "-" PORT
  35
  36    [This is the regular format for specifying sets of addresses and
  37    ports in Tor.]
  38
  39 New OR behavior:
  40
  41    We add two more options to supplement ORListenAddress:
  42    ORPublishedListenAddress, and ORPublishAddressSet.  The former
  43    listens on an address-port combination and publishes it in addition
  44    to the regular address.  The latter advertises a set of address-port
  45    combinations, but does not listen on them.  [To use this option, the
  46    server operator should set up port forwarding to the regular ORPort,
  47    as for example with firewall rules.]
  48
  49    Servers should extend their testing to include advertised addresses
  50    and ports.  No address or port should be advertised until it's been
  51    tested.  [This might get expensive in practice.]
  52
  53 New authority behavior:
  54
  55    Authorities should spot-test descriptors, and reject any where a
  56    substantial part of the addresses can't be reached.
  57
  58 New client behavior:
  59
  60    When connecting to another server, clients SHOULD pick an
  61    address-port ocmbination at random as supported by their
  62    reachableaddresses.  If a client has a connection to a server at one
  63    address, it SHOULD use that address for any simultaneous connections
  64    to that server.  Clients SHOULD use the canonical address for any
  65    server when generating extend cells.
  66
  67 Not addressed here:
  68
  69    * There's no reason to listen on multiple dirports; current Tors
  70    mostly don't connect directly to the dirport anyway.
  71
  72    * It could be advantageous to list something about extra addresses in
  73    the network-status document.  This would, however, eat space there.
  74    More analysis is needed, particularly in light of proposal 141
  75    ("Download server descriptors on demand")
  76
  77 Dependencies:
  78
  79    Testing for canonical connections needs to be implemented before it's
  80    safe to use this proposal.
  81
  82
  83 Notes 3 July:
  84   - Write up the simple version of this.  No ranges needed yet.  No
  85     networkstatus chagnes yet.
  86