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 thinkwithout a nice layer of link specifier IPv6, we can't move forward on muchother 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
Let me know how I can be most useful here while you do that.
Here is the wiki page I am using for planning:
Feel free to edit it :-)
Here's the high-level ticket, please pick any task I haven't started on:
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>" kindof thing that we enable by default for both v4 and v6 and then explicitly setit 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