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
On 12 Dec (09:54:43), teor wrote:
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?
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
T
On 15 Dec 2017, at 03:29, David Goulet dgoulet@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.
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.
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):
- Relay
- Client
- 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.
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
On 15 Dec (03:47:25), teor wrote:
On 15 Dec 2017, at 03:29, David Goulet dgoulet@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?
Let me know how I can be most useful here while you do that.
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).
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):
- Relay
- Client
- 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++!
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
T
On 15 Dec 2017, at 04:04, David Goulet dgoulet@torproject.org wrote:
On 15 Dec (03:47:25), teor wrote:
On 15 Dec 2017, at 03:29, David Goulet dgoulet@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
On 15 Dec (04:31:45), teor wrote:
On 15 Dec 2017, at 04:04, David Goulet dgoulet@torproject.org wrote:
On 15 Dec (03:47:25), teor wrote:
On 15 Dec 2017, at 03:29, David Goulet dgoulet@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
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
-
David Goulet -
teor