commit 4036bd9cd1d43f9cfb28e4fdb198fbbce113c1fb Author: Roger Dingledine arma@torproject.org Date: Sun Oct 23 13:22:23 2011 -0400
unobjectionable (i hope) proposal fixes --- proposals/186-multiple-orports.txt | 22 +++++++++++----------- proposals/187-allow-client-auth.txt | 2 +- 2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/proposals/186-multiple-orports.txt b/proposals/186-multiple-orports.txt index 56a76c7..192d758 100644 --- a/proposals/186-multiple-orports.txt +++ b/proposals/186-multiple-orports.txt @@ -58,14 +58,14 @@ Configuring additional addresses and ports: IPv4 addresses or to IPv6 addresses.
As with the client *Port options, only the old format or the new - format are allowed: either a single numeric socksport and zero or - more sockslistenaddress options, or a set of one or more + format are allowed: either a single numeric ORPort and zero or + more ORListenAddress options, or a set of one or more ORPorts in the new extended format.
In current operating systems (unless we get into crazy nonportable tricks) we need to use one socket for every address:port that Tor - bind on. As a sanity check, we can limit the number of such - sockets we use to, say, 64. If you want to bind lots more + binds on. As a sanity check, we can limit the number of such + sockets we use to, say, 64. If you want to bind lots of address:port combinations, you'll want to do it at the firewall/routing level.
@@ -74,14 +74,14 @@ Configuring additional addresses and ports: ORPort 9001
Example: Our firewall is redirecting ports 80, 443, and 7000-8000 - on all hosts in x.244.2.0/24 onto our port 2929. + on all hosts in 18.244.2.0/24 onto our port 2929.
ORPort 2929 noadvertise - ORPort x.244.2.0/24:80,443,7000-8000 nolisten + ORPort 18.244.2.0/24:80,443,7000-8000 nolisten
Example: We have a dynamic DNS provider that maps tornode.example.com to our current external IPv4 and IPv6 - addresses. Our firewall forwards port 443 on those address to our + addresses. Our firewall forwards port 443 on those addresses to our port 1337.
ORPort 1337 noadvertise alladdrs @@ -99,7 +99,7 @@ Self-testing:
It will now be possible for a Tor node to find that some addresses work and others do not. In this case, the node should only - advertise socksport lines that have been checked. + advertise ORPort lines that have been checked.
{Until support is added for extend cells to IPv6 addresses, it will only be possible to test IPv6 addresses by connecting @@ -138,7 +138,7 @@ New authority behavior:
The same rationale applies as for self-testing. An authority needs to test the main address:port from the router line, and - every or-address line. For or-address lines that contains + every or-address line. For or-address lines that contain multiple ports, it needs to test all of them if they are few, or a sample if they are not.
@@ -156,7 +156,7 @@ Consensus directories and microdescriptors: Clients that use microdescriptors should consider a node's addresses to be the address:port listed in the "r" line of a consensus, plus all "a" lines for that node in the consensus, plus - all "a" lines for that node in the its microdescriptor. Clients + all "a" lines for that node in its microdescriptor. Clients that use full descriptors should consider a node's addresses to be everything listed in its descriptor.
@@ -198,7 +198,7 @@ Client behavior:
Tor clients not running with bridges, and running with IPv4 support, should still use the address and ORPort as advertised in - the router or r line of the appropriate directory object. + the "router" or "r" line of the appropriate directory object.
Tor clients not running with bridges, and running without IPv4 support, should use the first listed IPv6 address for a node, diff --git a/proposals/187-allow-client-auth.txt b/proposals/187-allow-client-auth.txt index 3d3cf25..5e71599 100644 --- a/proposals/187-allow-client-auth.txt +++ b/proposals/187-allow-client-auth.txt @@ -44,7 +44,7 @@ Design:
Instead, we make the following specification changes:
- We reserve a new variable-length cell type, "AUTHORIZE." + We reserve a new variable-length cell type, "AUTHORIZE".
We specify that any number of PADDING or VPADDING or AUTHORIZE cells may be sent by the client before it sends a VERSIONS cell.