[tor-dev] Proposal 186: Multiple addresses for one OR or bridge

[Roger Dingledine]

[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