Filename: 186-multiple-orports.txt Title: Multiple addresses for one OR or bridge Author: Nick Mathewson Created: 19-Sep-2011 Supersedes: 118 Status: Draft
Overview:
This document is a proposal for servers to advertise multiple address/port combinations for their ORPort.
It supersedes proposal 118.
Motivation:
Sometimes servers want to support multiple ports for incoming connections, either in order to support multiple address families (ie, to add IPv6 support), 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.
Configuring additional addresses and ports:
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.
The new syntax will be:
"SocksPort" PortDescription Options?
Options = "NoAdvertise" | "NoListen" | "AllAddrs" | "IPV4Only" | "IPV6Only"
PortDescription = PORTLIST | ADDRESS ":" PORTLIST | Hostname ":" PORTLIST
(PORTLIST and ADDRESS are defined below.)
The 'NoAdvertise' option performs the function of the old SocksListenAddress option. If it is set, we bind a port, but don't put it in our descriptor.
The 'NoListen' option tells Tor to advertise an address, but not bind to it. The operator needs to use some other mechanism to ensure that ports are redirected to ports that _are_ listened on.
The 'AllAddrs' option tells Tor that if no address is given in the PortDescription part, we should bind/advertise every one of our publicly visible unicast addresses; and that if a hostname address is given in the PortDescription, we should bind/advertise every publicly visible unicast address that the hostname resolves to. (Q: Should this be on by default?) The 'IPv4Only' and 'IPv6Only' options tell Tor to interpret such situations as applying only to 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 SocksPorts 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 address:port combinations, you'll want to do it at the firewall/routing level.
Example: We want to bind on 0.0.0.0:9001
SocksPort 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.
SocksPort 2929 no-advertise SocksPort x.244.2.0/24:80,443,7000-8000 no-listen
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 port 1337.
SocksPort 1337 no-advertise alladdrs SocksPort tornode.example.com:443 no-bind alladdrs
Self-testing:
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 extending to or connecting to a sample of the address/port combinations.
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.
{Until support is added for extend cells to IPv6 addresses, it will only be possible to test IPv6 addresses by connecting directly. We might want to just skip self-testing those until we have IPv6 extend support.}
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 PORT = a number between 1 and 65535 inclusive.
[This is the regular format for specifying sets of addresses and ports in Tor.]
A descriptor should not include an or-address line that does nothing but duplicate the address:port pair from its "router" line.
A node must not list more than 8 or-address lines.
(Q: Any reason to allow more than 2? Multiple interfaces, I guess.)
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 multiple ports, it needs to test all of them if they are few, or a sample if they are not.
An authority shouldn't list a node as Running unless every or-address line it advertises looks like it will work.
Consensus directories and microdescriptors:
We introduce a new line type for microdescriptors and consensuses, "a". Each "a" line has the same format as an or-address line. The "a" lines (if any) appear immediately after the "r" line for a router in the consensus, and immediately after the "onion-key" entry in a microdescriptor.
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 that use full descriptors should consider a node's addresses to be everything listed in its descriptor.
We will have to define a new voting algorithm version; when using this version or later, votes should include a single "a" line for every relay that has an IPv6 address, to include the first IPv6 line in its descriptor. (If there are no or-address lines, then they shouldn't include any "a" lines.) The remaining or-address lines will turn into "a" lines in the microdescriptor.
As with other data in the vote derived from the descriptor, the vote will include whichever set of "a" lines are given by the most authorities who voted for the descriptor digest that will be used for the router.
Directory authorities with more addresses:
We need a way for a client to configure a TrustedDirServer as having multiple OR addresses, specifically so that we can give at least one default authority an IPv6 address for bootstrapping purposes.
(Q: Do any of the current authorities have stable IPv6 addresses?)
We will want to allow the address in a "dir-source" line in a vote to contain an IPv6 address, and/or allow voters to list themselves with more addresses in votes/consensuses. But right now, nothing actually uses the addresses listed for voters in dir-source lines for anything besides log messages.
Client behavior:
I propose that initially we shouldn't change client behavior too much here.
(Q: Is there any advantage to having a client choose a random 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 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, using the lowest-numbered listed port for that address. They should only connect to nodes with an IPv6 address.
Clients should accept Bridge lines with IPv6 addresses, and address:port sets, in addition to the lines they currently accept.
Clients, for now, should only use the address:port from the router line when making EXTEND cells; see below.
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 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 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.
We can make this work, though: let's allow nodes to list themselves with a magic IPv4 address (say, 127.1.1.1) if they have or-address entries containing only IPv6 address. We could give these nodes a new flag other than Running to indicate that they're up, and not give them the Running flag. That way, old clients would never try to use them, but new clients could know to treat the new flag as indicating that the node is running, and know not to connect to a node listed with address 127.1.1.1.
Interaction with EXTEND and NETINFO:
Currently, EXTEND cells only support IPv4 addresses, so we should use only those. There is a proposal draft to support more address types.
A server's NETINFO cells must list all configured addresses for a server.
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 provide not only ranges of ports, but also ranges of addresses, specified with bitmasks. That's a neat idea for circumvention, but if we did that, you wouldn't want to advertise publicly that you have an entire address range.
Coding impact:
In addition to the obvious changes, we need to audit everything that looks up or compares OR connections and nodes by address:port under the assumptions that each node has only a single address or ORPort.
Hi Nick,
a few comments to proposal 186 below:
On 9/21/11 8:13 PM, Nick Mathewson wrote:
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.
When you say "Socks" in this document in most cases you mean "OR".
The new syntax will be:
"SocksPort" PortDescription Options?
The syntax allows multiple options per SocksPort line, right? Would that be "Options*" then?
The 'NoListen' option tells Tor to advertise an address, but not bind to it. The operator needs to use some other mechanism to ensure that ports are redirected to ports that _are_ listened on.
Do we need to check that we have at least one SocksPort line without the NoListen option?
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 address:port combinations, you'll want to do it at the firewall/routing level.
64 seems very high for the number sockets to open. If someone wants to open more than 8 sockets and doesn't know how to edit firewall rules, that person probably shouldn't be opening this number of sockets.
Example: Our firewall is redirecting ports 80, 443, and 7000-8000 on all hosts in x.244.2.0/24 onto our port 2929.
SocksPort 2929 no-advertise SocksPort x.244.2.0/24:80,443,7000-8000 no-listen
"no-advertise" -> "noadvertise"
"no-listen" -> "nolisten"
The "/24" should probably also go away.
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 port 1337.
SocksPort 1337 no-advertise alladdrs SocksPort tornode.example.com:443 no-bind alladdrs
"no-advertise" -> "noadvertise"
"no-bind" -> "nolisten"
I wonder what the effect of putting in a dynamic hostname is. Tor uses an IP address in the server descriptor anyway, and wouldn't it find out the IP address(es) by itself?
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.
What if a partial SocksPort line was found to work, that is, if only a few ports work?
A node must not list more than 8 or-address lines.
Should there also be a restriction of PORTSPECs per line? I can imagine how these lines can get quite long: 1.2.3.4:1-2,4-5,7-8,...
Rest looks good!
Best, Karsten
On Thu, Sep 22, 2011 at 3:43 AM, Karsten Loesing karsten.loesing@gmx.net wrote:
Hi Nick,
a few comments to proposal 186 below:
On 9/21/11 8:13 PM, Nick Mathewson wrote:
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.
When you say "Socks" in this document in most cases you mean "OR".
Yeowch, you're right.
The new syntax will be:
"SocksPort" PortDescription Options?
The syntax allows multiple options per SocksPort line, right? Would that be "Options*" then?
Yup.
The 'NoListen' option tells Tor to advertise an address, but not bind to it. The operator needs to use some other mechanism to ensure that ports are redirected to ports that _are_ listened on.
Do we need to check that we have at least one SocksPort line without the NoListen option?
s/SocksPort/ORPort/
No, but we shouldn't advertise ourselves unless we do, just like we currently don't advertise ourselves unless we have an ORPort set.
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 address:port combinations, you'll want to do it at the firewall/routing level.
64 seems very high for the number sockets to open. If someone wants to open more than 8 sockets and doesn't know how to edit firewall rules, that person probably shouldn't be opening this number of sockets.
Feels bikesheddy to me; any power of two between 8 and 64 seems fine here.
Example: Our firewall is redirecting ports 80, 443, and 7000-8000 on all hosts in x.244.2.0/24 onto our port 2929.
SocksPort 2929 no-advertise SocksPort x.244.2.0/24:80,443,7000-8000 no-listen
"no-advertise" -> "noadvertise"
"no-listen" -> "nolisten"
The "/24" should probably also go away.
Done.
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 port 1337.
SocksPort 1337 no-advertise alladdrs SocksPort tornode.example.com:443 no-bind alladdrs
"no-advertise" -> "noadvertise"
"no-bind" -> "nolisten"
done.
I wonder what the effect of putting in a dynamic hostname is. Tor uses an IP address in the server descriptor anyway, and wouldn't it find out the IP address(es) by itself?
You can already specify a hostname as your Address, I believe; this is meant to work the same.
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.
What if a partial SocksPort line was found to work, that is, if only a few ports work?
Then, by the terms of this document, the whole socksport line is discarded.
A node must not list more than 8 or-address lines.
Should there also be a restriction of PORTSPECs per line? I can imagine how these lines can get quite long: 1.2.3.4:1-2,4-5,7-8,...
Good point. Also, they should be disjoint.
I've made changes in the torspec git repo corresponding to notes above. Thanks!
[Quoting the original mail, but it's actually the file in git that I read and am commenting on.]
On Wed, Sep 21, 2011 at 02:13:18PM -0400, Nick Mathewson wrote:
The 'AllAddrs' option tells Tor that if no address is given in the PortDescription part, we should bind/advertise every one of our publicly visible unicast addresses; and that if a hostname address is given in the PortDescription, we should bind/advertise every publicly visible unicast address that the hostname resolves to. (Q: Should this be on by default?)
Yes, I think. And if it's on by default, does the option need to exist at all?
Example: Our firewall is redirecting ports 80, 443, and 7000-8000 on all hosts in x.244.2.0/24 onto our port 2929.
SocksPort 2929 no-advertise SocksPort x.244.2.0/24:80,443,7000-8000 no-listen
This address has a bitmask, but your note at the end says the bitmask feature is no longer in the proposal.
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 port 1337.
SocksPort 1337 no-advertise alladdrs SocksPort tornode.example.com:443 no-bind alladdrs
This drives home the issue with alladdrs: what would we do if that flag isn't listed here?
{Until support is added for extend cells to IPv6 addresses, it will only be possible to test IPv6 addresses by connecting directly. We might want to just skip self-testing those until we have IPv6 extend support.}
Agreed that we don't want to waste time with some temporary alternate checking mechanism.
(Q: Any reason to allow more than 2? Multiple interfaces, I guess.)
By the same logic that we chose not to allow bitmasks in addresses, it's easy to argue that we shouldn't list more than 2 addresses (one ipv4, one ipv6). But does limiting it to 2 in the spec simplify the design in any way, or just constrain us down the road?
An authority shouldn't list a node as Running unless every or-address line it advertises looks like it will work.
This part makes me sad -- I worry that we'll end up with situations where most addresses work but we discard the whole relay because of a network hiccup somewhere (e.g. between the directory authority and one of the relay's addresses). How much more would it complexify things if we list the ones we think are up in the consensus, and then the voting process decides which ones get advertised?
Consensus directories and microdescriptors:
We introduce a new line type for microdescriptors and consensuses, "a". Each "a" line has the same format as an or-address line. The "a" lines (if any) appear immediately after the "r" line for a router in the consensus, and immediately after the "onion-key" entry in a microdescriptor.
We should clarify which flavors we mean when we say consensuses. That is, are we going to add "a" lines to the microdescriptor-flavor consensus too, even though clients will soon find the same lines when they fetch the microdescriptors? I think yes, on the theory that clients will find the addresses useful in fetching microdescriptors. But it feels like a shame to include this mostly static info in every consensus when it's only really helpful for initial bootstrap for a tiny subset of users.
I could imagine an ipv6-micro flavored consensus which includes ipv6 addresses for the clients who need that, and then those clients fetch the normal consensus after that. But maybe I'm trying to optimize too much for bandwidth.
We will have to define a new voting algorithm version; when using this version or later, votes should include a single "a" line for every relay that has an IPv6 address, to include the first IPv6 line in its descriptor. (If there are no or-address lines, then
You meant "If there are no IPv6 or-address lines", yes?
As with other data in the vote derived from the descriptor, the vote will include whichever set of "a" lines are given by the most authorities who voted for the descriptor digest that will be used for the router.
Just to clarify, we treat the whole set of "a" lines for the router as an atomic blob, and vote for the blob that is most common? We could also do something more fine-grained, but I don't think we want to.
Directory authorities with more addresses:
We need a way for a client to configure a TrustedDirServer as having multiple OR addresses, specifically so that we can give at least one default authority an IPv6 address for bootstrapping purposes.
Looks like there are lots of ways to do this. For example, looking at the code, it seems easy to add an ipv6=[...] argument that shows up before the addr:port argument.
(Q: Do any of the current authorities have stable IPv6 addresses?)
I'd look to tor26 and maatuska.
We will want to allow the address in a "dir-source" line in a vote to contain an IPv6 address, and/or allow voters to list themselves with more addresses in votes/consensuses. But right now, nothing actually uses the addresses listed for voters in dir-source lines for anything besides log messages.
Yeah, I wouldn't worry about this yet (or ever).
Client behavior:
I propose that initially we shouldn't change client behavior too much here.
(Q: Is there any advantage to having a client choose a random 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 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, using the lowest-numbered listed port for that address. They should only connect to nodes with an IPv6 address.
A) What's the recommended way for the Tor client to discover that it doesn't have ipv4 support?
B) What if the client supports ipv4 and ipv6 yet the public ipv4 relays are blocked? We need some way for the user to explicitly ask for ipv6, and ideally some way to auto detect that Tor should try the other.
Clients should accept Bridge lines with IPv6 addresses, and address:port sets, in addition to the lines they currently accept.
Do you mean address:portlist sets?
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 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.
They will.
We can make this work, though: let's allow nodes to list themselves with a magic IPv4 address (say, 127.1.1.1) if they have or-address entries containing only IPv6 address. We could give these nodes a new flag other than Running to indicate that they're up, and not give them the Running flag. That way, old clients would never try to use them, but new clients could know to treat the new flag as indicating that the node is running, and know not to connect to a node listed with address 127.1.1.1.
It would be nice to come up with a color for the fence that doesn't involve forever maintaining a separate Running6 flag and forever including a hack in the consensus. For example, what if we have an "r6" line that is like an "r" line except its address is v6? I think we can't do that because the "w", "p", etc lines in the r6 stanza would be interpreted by old clients as part of the previous router's stanza. Does that realization mean we should declare one of the lines in the router stanza "at end, exactly once" in the spec, so in the future we can add new types of stanzas? Does it mean we can't add a "w" line to the directory footer stanza because it would confuse clients who don't know there's a directory footer stanza? Whee.
--Roger
On Sun, Oct 23, 2011 at 1:26 PM, Roger Dingledine arma@mit.edu wrote:
[Quoting the original mail, but it's actually the file in git that I read and am commenting on.]
On Wed, Sep 21, 2011 at 02:13:18PM -0400, Nick Mathewson wrote:
The 'AllAddrs' option tells Tor that if no address is given in the PortDescription part, we should bind/advertise every one of our publicly visible unicast addresses; and that if a hostname address is given in the PortDescription, we should bind/advertise every publicly visible unicast address that the hostname resolves to. (Q: Should this be on by default?)
Yes, I think. And if it's on by default, does the option need to exist at all?
I actually don't think it should be on-by-default at this point. It'd change the behavior of ORPort 9001 in a possibly surprising way that I'm not sure we agree with. See below.
[...]
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 port 1337.
ORPort 1337 no-advertise alladdrs ORPort tornode.example.com:443 no-bind alladdrs
This drives home the issue with alladdrs: what would we do if that flag isn't listed here?
The same as we currently do if you say "ORPort 1337": Try to figure out a single value for "our address," and advertise that address with that port, and not open or advertise any other ports.
(Q: Any reason to allow more than 2? Multiple interfaces, I guess.)
By the same logic that we chose not to allow bitmasks in addresses, it's easy to argue that we shouldn't list more than 2 addresses (one ipv4, one ipv6). But does limiting it to 2 in the spec simplify the design in any way, or just constrain us down the road?
Hm. In practice, keeping track of an IPv4 address and an IPv6 address seems to be enough for now. I'm going to suggest that we remove port ranges from the proposal too, and just have lists of ports, and start by having servers only list up to two addresses with one port each, but have clients able to parse more than that, in case we someday come up with a better approach.
An authority shouldn't list a node as Running unless every or-address line it advertises looks like it will work.
This part makes me sad -- I worry that we'll end up with situations where most addresses work but we discard the whole relay because of a network hiccup somewhere (e.g. between the directory authority and one of the relay's addresses). How much more would it complexify things if we list the ones we think are up in the consensus, and then the voting process decides which ones get advertised?
Well, it would complexify things somewhat, but I'm not so sure it's avoidable: It seems like it'll be pretty common to autoconfig a working ipv4 address but not a working ipv6 address, or vice versa.
But on the other hand, self-testing is *supposed* to prevent that.
Consensus directories and microdescriptors:
We introduce a new line type for microdescriptors and consensuses, "a". Each "a" line has the same format as an or-address line. The "a" lines (if any) appear immediately after the "r" line for a router in the consensus, and immediately after the "onion-key" entry in a microdescriptor.
We should clarify which flavors we mean when we say consensuses. That is, are we going to add "a" lines to the microdescriptor-flavor consensus too, even though clients will soon find the same lines when they fetch the microdescriptors? I think yes, on the theory that clients will find the addresses useful in fetching microdescriptors. But it feels like a shame to include this mostly static info in every consensus when it's only really helpful for initial bootstrap for a tiny subset of users.
I think so; without them, ipv6-only clients just can't work.
I could imagine an ipv6-micro flavored consensus which includes ipv6 addresses for the clients who need that, and then those clients fetch the normal consensus after that. But maybe I'm trying to optimize too much for bandwidth.
Adding new flavors can totally happen after the first implementation here.
We will have to define a new voting algorithm version; when using this version or later, votes should include a single "a" line for every relay that has an IPv6 address, to include the first IPv6 line in its descriptor. (If there are no or-address lines, then
You meant "If there are no IPv6 or-address lines", yes?
yes.
As with other data in the vote derived from the descriptor, the vote will include whichever set of "a" lines are given by the most authorities who voted for the descriptor digest that will be used for the router.
Just to clarify, we treat the whole set of "a" lines for the router as an atomic blob, and vote for the blob that is most common? We could also do something more fine-grained, but I don't think we want to.
Hmmm. I actually think being more fine-grained is right if we want to be able to vote on individual addresses working or not.
[...]
Client behavior:
I propose that initially we shouldn't change client behavior too much here.
(Q: Is there any advantage to having a client choose a random 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 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, using the lowest-numbered listed port for that address. They should only connect to nodes with an IPv6 address.
A) What's the recommended way for the Tor client to discover that it doesn't have ipv4 support?
Not having a public unicast IPv4 address; having all attempts to connect to IPv4 addresses fail pretty early on.
B) What if the client supports ipv4 and ipv6 yet the public ipv4 relays are blocked? We need some way for the user to explicitly ask for ipv6, and ideally some way to auto detect that Tor should try the other.
Good idea.
[...]
We can make this work, though: let's allow nodes to list themselves with a magic IPv4 address (say, 127.1.1.1) if they have or-address entries containing only IPv6 address. We could give these nodes a new flag other than Running to indicate that they're up, and not give them the Running flag. That way, old clients would never try to use them, but new clients could know to treat the new flag as indicating that the node is running, and know not to connect to a node listed with address 127.1.1.1.
It would be nice to come up with a color for the fence that doesn't involve forever maintaining a separate Running6 flag and forever including a hack in the consensus. For example, what if we have an "r6" line that is like an "r" line except its address is v6? I think we can't do that because the "w", "p", etc lines in the r6 stanza would be interpreted by old clients as part of the previous router's stanza. Does that realization mean we should declare one of the lines in the router stanza "at end, exactly once" in the spec, so in the future we can add new types of stanzas? Does it mean we can't add a "w" line to the directory footer stanza because it would confuse clients who don't know there's a directory footer stanza? Whee.
I think that your long series of questions here basically comes out to "yeah". Did you have an idea on this point that _would_ work out? I guess we could do a new consensus flavor, but minimizing those is probably smart.
On 1/17/12 5:41 PM, Nick Mathewson wrote:
ORPort 1337 no-advertise alladdrs ORPort tornode.example.com:443 no-bind alladdrsThis drives home the issue with alladdrs: what would we do if that flag isn't listed here?
This feature would allow a single node, for example, to expose to the internet 10.000 different IP:Port pairs?
For example think about a single node that have 10.000 different small TCP forwarders around the internet.
Could it possible?
Fabio
-
Fabio Pietrosanti (naif) -
Karsten Loesing -
Nick Mathewson -
Nick Mathewson -
Roger Dingledine