[tor-dev] IPv6 and v3 onion services

[teor]

On 15 Dec 2017, at 04:04, David Goulet <dgoulet at torproject.org> wrote:

>> On 15 Dec (03:47:25), teor wrote:
>> 
>>>> On 15 Dec 2017, at 03:29, David Goulet <dgoulet at torproject.org> wrote:
>>> 
>>> The place I'm thinking of is the EXTEND in IPv6 and relay self-testing in
>>> IPv6. This seems a more critical point to build into the network before we can
>>> start building HS support on top (single onion is different but will have to
>>> do with HS code in some ways).
>> 
>> I'm working on this right now.
>> It should be ready by mid-January, but it needs a proposal, so maybe it will
>> end up in 0.3.4 instead.
> 
> Ok!
> 
> Can you tell me which ticket is that so I don't start poking at it? I think
> without a nice layer of link specifier IPv6, we can't move forward on much
> other things?

Yes, it's important, and it would be great if you could do it.

Is that this ticket?

hs: Unify link specifier API/ABI
https://trac.torproject.org/projects/tor/ticket/22781

> Let me know how I can be most useful here while you do that.

Here is the wiki page I am using for planning:
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features

Feel free to edit it :-)

Here's the high-level ticket, please pick any task I haven't started on:

https://trac.torproject.org/projects/tor/ticket/24403

>> I would also like to make it easier to configure IPv6 relays. IPv6 support isn't
>> as useful as it could be, because only 15% of relays support IPv6.
>> Address autodetection would go a long way here.
> 
> Are you suggesting something like "Address auto" or "ORPort auto:<port>" kind
> of thing that we enable by default for both v4 and v6 and then explicitly set
> it if you want a specific address?

Eventually, but it doesn't need to be done in 0.3.3.

> Auto detection of address becomes complicated with interfaces that have
> multiple IPs... Which one do you choose?

Tor does this already with IPv4.

We check these sources for IPv4 (in about this order):
The configured Address
NETINFO cells from our outbound connections to other relays
The first IPv4 address in the order the OS provides them

I think we stopped using the X-Your-IP-Address-Is headers in
directory documents.

We check these sources for IPv6:
The first advertised IPv6 ORPort

Eventually, I want to make both use this order:
The configured Address
The first advertised ORPort
NETINFO cells from our outbound connections to other relays
The first address in the order the OS provides them

If we want to be clever, we can skip addresses that aren't reachable.
Or we can check all the addresses, and try to choose the shortest
address text to put in directory documents.
But these features can wait.

> But aren't you worried of Tor finding an IPv6 for a relay and starting using
> it while the operator has no idea that it is happening? Dunno, maybe some
> relays are bandwidth capped on v4 or/and v6 (would suck but)?

I've never heard of such a thing.
And we can't support every weird scenario by default.
There will be a way to turn the feature off.

I think we have to get used to treating IPv4 and IPv6 the same.
We guess IPv4, we should guess IPv6 as well.

If we need to have a release where the feature is available but off by default,
that's ok. But I think it's not a big deal. Let's just tell people at the top of the
release notes.

It will make a lot of relay operators happy.

> Anyway this can be a ticket (if not already done)

Reachability checks are:

Missing IPv6 ORPort reachability check
https://trac.torproject.org/projects/tor/ticket/6939

I'm sure we have a ticket for relay IPv6 autodetection, but I can't find it
right now.

T

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171215/34dc6fa6/attachment-0001.html>