[tor-dev] IPv6 and v3 onion services

[teor]

Hi David (and others interested in IPv6),

We want to add better IPv6 support to Tor relays, clients, and v3 onion services.

But if we do IPv6 v3 onion services first, the hop before intro and rend points
will know that the circuit is a v3 onion service circuit, because its EXTEND2
cells will have an IPv6 address.

So I suggest that we implement IPv6 support in this order:
IPv6 single onion services (at any time, only uses direct IPv6 CREATE)
IPv6 relay extends
IPv6 relay reachability (provides cover traffic for IPv6 client extends)
IPv6 client extends for exit circuits
IPv6 client extends for multi-hop onion service circuits
I've added this to an "Overview" section in:
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features

I also like the idea of testing and deploying our IPv6 code on relays first.
It's less risky than experimenting on clients or onion services.
And our relay operators give us some excellent bug reports.

And we can re-use some of the common code from the relay implementation
in the client and onion service implementations. (For example, we'll write
code that handles link specifiers.)

Also, if we get IPv6 relay reachability checks working, that makes it easier
to automatically configure IPv6 on relays. More IPv6 relays will make the
anonymity set larger for IPv6 clients.

What do you think?

T

[David Goulet]

Post by teor
Hi David (and others interested in IPv6),
We want to add better IPv6 support to Tor relays, clients, and v3 onion services.
But if we do IPv6 v3 onion services first, the hop before intro and rend points
will know that the circuit is a v3 onion service circuit, because its EXTEND2
cells will have an IPv6 address.
IPv6 single onion services (at any time, only uses direct IPv6 CREATE)
IPv6 relay extends
IPv6 relay reachability (provides cover traffic for IPv6 client extends)
IPv6 client extends for exit circuits
IPv6 client extends for multi-hop onion service circuits
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features
I also like the idea of testing and deploying our IPv6 code on relays first.
It's less risky than experimenting on clients or onion services.
And our relay operators give us some excellent bug reports.
And we can re-use some of the common code from the relay implementation
in the client and onion service implementations. (For example, we'll write
code that handles link specifiers.)
Also, if we get IPv6 relay reachability checks working, that makes it easier
to automatically configure IPv6 on relays. More IPv6 relays will make the
anonymity set larger for IPv6 clients.
What do you think?

When I did some of IPv6 work on hidden service v3 (before we rolled it back
:P), we are missing IPv6 foundations in some places that I think would be good
to nail down before we do anything with HS.

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).

Then, making sure a client can do IPv6 seems the natural next step. And then
we finish with HS.

So to summarize (in order of what I think we should do first):

1. Relay
2. Client
3. HS/Single Onion

My two cents on this.

Also, 033 freeze is arriving rather fast that is in theory mid-january so we
have to consider the fact that we might not get the whole thing in 033 but we
can certainly try :).

Cheers!
David

Post by teor
T

[teor]

Post by David Goulet
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.

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.

Post by David Goulet
Then, making sure a client can do IPv6 seems the natural next step. And then
we finish with HS.
1. Relay
2. Client
3. HS/Single Onion
My two cents on this.

Seems good to me.
I want to try and focus on getting minimum working code.
Then we can add extra features later.

Post by David Goulet
Also, 033 freeze is arriving rather fast that is in theory mid-january so we
have to consider the fact that we might not get the whole thing in 033 but we
can certainly try :).

We can do parts in 0.3.3 and parts in 0.3.4.

T

[David Goulet]

Post by teor

Post by David Goulet
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?

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

Post by teor
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?

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

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)?

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

Post by teor

Post by David Goulet
Then, making sure a client can do IPv6 seems the natural next step. And then
we finish with HS.
1. Relay
2. Client
3. HS/Single Onion
My two cents on this.

Seems good to me.
I want to try and focus on getting minimum working code.
Then we can add extra features later.

Agree++!

Post by teor

Post by David Goulet
Also, 033 freeze is arriving rather fast that is in theory mid-january so we
have to consider the fact that we might not get the whole thing in 033 but we
can certainly try :).

We can do parts in 0.3.3 and parts in 0.3.4.

Sure thing.

Cheers!
David

Post by teor
T

[teor]

Post by David Goulet

Post by teor

Post by David Goulet
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

Post by David Goulet
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

Post by David Goulet

Post by teor
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.

Post by David Goulet
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.

Post by David Goulet
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.

Post by David Goulet
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

[David Goulet]

Post by teor

Post by David Goulet

Post by teor

Post by David Goulet
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

Sure! I've already done much work on it but stopped because I wasn't sure
which direction we want to go. I've tried to summarize it in:

https://trac.torproject.org/projects/tor/ticket/22781#comment:6

Any feedback would be very appreciated so I can finalize this for review.

Cheers!
David