commit 3d8044ae4b9c6b2201325e743dcaae3bbf760624 Author: Nick Mathewson nickm@torproject.org Date: Wed Sep 21 14:12:52 2011 -0400
Revise my proposal draft for a 118 replacement based on comments from linus --- proposals/ideas/xxx-multiple-orports.txt | 20 ++++++++++++-------- 1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/proposals/ideas/xxx-multiple-orports.txt b/proposals/ideas/xxx-multiple-orports.txt index fc3a741..4d5b7fb 100644 --- a/proposals/ideas/xxx-multiple-orports.txt +++ b/proposals/ideas/xxx-multiple-orports.txt @@ -22,7 +22,7 @@ Motivation:
Configuring additional addresses and ports:
- In consonance with our chances to the (Socks|Trans|NATD|DNS)Port + In consonance with our changes to the (Socks|Trans|NATD|DNS)Port options made in 0.2.3.x for proposal 171, I make a corresponding change to allow multiple SocksPort options and deprecate SocksListenAddress. @@ -81,7 +81,7 @@ Configuring additional addresses and ports:
Example: We have a dynamic DNS provider that maps tornode.example.com to our current external IPv4 and IPv6 - addresses. Our firefall forwards port 443 on those address to our + addresses. Our firewall forwards port 443 on those address to our port 1337.
SocksPort 1337 no-advertise alladdrs @@ -89,8 +89,8 @@ Configuring additional addresses and ports:
Self-testing:
- Right now, Tor nodes need to check every port that advertise - before they declare themselves reachable. If a Tor has a large IP + Right now, Tor nodes need to check every port that they advertise + before they declare themselves reachable. If a Tor has a lot of advertised ports, that could be prohibitive. Instead, it should try a sample of ports for each address. It should not advertise any given SocksPort line until it has tried @@ -129,7 +129,7 @@ New descriptor syntax:
A node must not list more than 8 or-address lines.
- (Q: Any reason to allow more than 2?) + (Q: Any reason to allow more than 2? Multiple interfaces, I guess.)
New authority behavior:
@@ -190,7 +190,8 @@ Client behavior: much here.
(Q: Is there any advantage to having a client choose a random - address? If so we can do it later.) + address? If so we can do it later. If not, why list any more + than one IPv4 and one IPv6 address?)
Tor clients not running with bridges, and running with IPv4 support, should still use the address and ORPort as advertised in @@ -211,11 +212,11 @@ Nodes without IPv4 addresses:
Currently Tor requires every node or bridge to have an IPv4 address. We will want to maintain this property for the - forseeable future, but we should define how a node without an IPv4 + foreseeable future, but we should define how a node without an IPv4 address would advertise itself.
Right now, there's no way to do that: if anything but an IPv4 - address appears in a router line of a routerdesc, or the r line of + address appears in a router line of a routerdesc, or the "r" line of a consensus, then it won't parse. If something that looks like an IPv4 address appears there, clients will (I believe) try to connect to it. @@ -242,6 +243,9 @@ Why not extend DirPort this way too?
Because clients are all using BEGINDIR these days.
+ That is, clients tunnel their directory requests inside OR + connections, and don't generally connect to DirPorts at all. + Why not have address ranges?
Earlier drafts of this proposal suggested that clients should