[tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery

Fri Nov 27 10:43:56 UTC 2020

Hello,

I have a hard time trying to correctly update my configuration following 
this change, with Tor 0.4.5.2 on Ubuntu focal.
The machine has both an IPv4 and IPv6 connectivity, but my relay must 
only use IPv4 to listen for connections.

The relevant parts of my configuration before moving to the 0.4.5 branch 
was:
```
ORPort 192.168.2.1:9001 NoAdvertise
ORPort <public-ipv4>:9001 NoListen

Address <public-ipv4>

OutboundBindAddress 192.168.2.1
```

Since 0.4.5, the order of the ORPort lines seem to matter.

* First case:

torrc ORPort lines:
```
ORPort 192.168.2.1:9001 NoAdvertise
ORPort <public-ipv4>:9001 NoListen
```

Log from `tor --verify-config -f torrc`:
```
Nov 27 11:26:30.043 [warn] We are advertising an ORPort, but not 
actually listening on one.
Nov 27 11:26:30.043 [warn] Failed to parse/validate config: 
Misconfigured server ports
Nov 27 11:26:30.043 [err] Reading config failed--see warnings above.
```

* Second case:

torrc ORPort lines:
```
ORPort <public-ipv4>:9001 NoListen
ORPort 192.168.2.1:9001 NoAdvertise
```

Log from `tor --verify-config -f torrc`:

```
Nov 27 11:29:17.236 [warn] We are listening on an ORPort, but not 
advertising any ORPorts. This will keep us from building a router 
descriptor, and make us impossible to use.
Nov 27 11:29:17.237 [warn] Failed to parse/validate config: 
Misconfigured server ports
Nov 27 11:29:17.237 [err] Reading config failed--see warnings above.
```

It looks like the second ORPort line always supersedes the first one?

Finally, by changing the configuration to:

```
ORPort 192.168.2.1:9001 NoAdvertise
OrPort 9001 NoListen IPv4Only
```

Log from `tor --verify-config -f torrc`:

```
Nov 27 11:34:12.699 [warn] Could not interpret ORPort address as IPv4
Nov 27 11:34:12.699 [warn] Failed to parse/validate config: Invalid 
ORPort configuration
Nov 27 11:34:12.699 [err] Reading config failed--see warnings above.
```

So I am unsure what is the correct approach with what I am trying to 
achieve.
I am not sure if I am missing something or if it's a bug in the new feature?

Thanks,

On 22/07/2020 21:54, David Goulet wrote:
> Greetings everyone!
> 
> We've very recently merged upstream (tor.git) full IPv6 supports which implies
> many many things. We are still finalizing the work but most of it is in at the
> moment.
> 
> This is a call for help if anyone would like to test either git master[1] or
> nightly builds[2] (only Debian) to test for us a specific feature.
> 
> The feature we would love for some of you to test is the IPv6 address
> discovery. In short, with this new feature, specifying an ORPort without an
> address will automatically bind tor to [::]:<port> and attempt to find the
> IPv6 address by looking at (in this order):
> 
>    1. "Address" from torrc
>    2. "ORPort address:port" from torrc
>    3. Interface address. First public IPv6 is used.
>    4. Local hostname, DNS AAAA query.
> 
> If all fails, the relay will simply never publish an IPv6 in the descriptor
> but it will work properly with the IPv4 (still mandatory).
> 
> The other new thing is that now tor supports *two* "Address" statement which
> can be a hostname or IPv4 or IPv6 now.
> 
> Thus this is now valid:
> 
>    Address 1.2.3.4
>    Address [4242::4242]
>    ORPort 9001
> 
> Your Tor will bind to 0.0.0.0:9001 and [::]:9001 but will publish the 1.2.3.4
> for the IPv4 address and [4242::4242] for IPv6 in the descriptor that is the
> address to use to reach your relay's ORPort.
> 
> Now, if you happen to have this configuration which I believe might be common
> at the moment:
> 
>    ORPort 9001
>    ORPort [4242::4242]:9001
> 
> The second ORPort which specifies an IPv6 address will supersede the "ORPort
> 9001" which uses [::] and thus you will bind on 0.0.0.0:9001 and
> [4242::4242]:9001. You should get a notice log about this.
> 
> Thus the recommended configuration to avoid that log notice would be to bind
> to specific addresses per family:
> 
>    ORPort <IPv4>:9001
>    ORPort <IPv6>:9001
> 
> And of course, if you want your relay to _not_ listen on IPv6:
> 
>    ORPort 9001 IPv4Only
> 
> In your notice log, you will see which address is used to bind on the ORPort
> and then you will see the reachability test succeed or not on the address that
> tor either used from the configuration or auto discovered that is the address
> you are supposedly reachable from.
> 
> Man page has NOT been updated yet, it will arrive once we stabilize the IPv6
> feature and everything around it.
> 
> Please, do report (on this thread) _anything_ even slightly annoying about
> this like logging or lack of logging and so on. This is a complex feature and
> errors can be made thus any testing you can offer is extremely appreciated.
> 
> Thanks!!
> David
> 
> [1] https://gitweb.torproject.org/tor.git/
> [2] https://2019.www.torproject.org/docs/debian.html.en
> 
> 
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x18E899E680C4FF62.asc
Type: application/pgp-keys
Size: 8712 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20201127/2cbae0fa/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20201127/2cbae0fa/attachment.sig>