torproject/torspec
1
0
Fork 0
mirror of https://github.com/torproject/torspec.git synced 2024-11-27 03:40:47 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

unobjectionable (i hope) proposal fixes

Browse Source
This commit is contained in:
Roger Dingledine 2011-10-23 13:22:23 -04:00
parent 9cd2dd3f9a
commit 4036bd9cd1
2 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
proposals/186-multiple-orports.txt
View File

@ -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,

2
proposals/187-allow-client-auth.txt
View File

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