[tor-dev] Student project to work on IPv6 support (was: [tor-relays] About relay size)

[teor]

> On 12 Oct 2017, at 09:15, Santiago R.R. <santiagorr at riseup.net> wrote:
> 
> (Moving this thread from tor-relay)
> 
>> El 03/10/17 a las 14:25, teor escribió:
>> 
>>> On 3 Oct 2017, at 10:57, Roman Mamedov <rm at romanrm.net> wrote:
>>> 
>>> On Tue, 3 Oct 2017 09:53:46 -0400
>>> teor <teor2345 at gmail.com> wrote:
>>> 
>>>>>   For interposing dual-protocoled nodes along the way, how many do there
>>>>> have to be for it to become "not too limiting"?
>>>> 
>>>> This is one of the questions we need researchers to answer.
>>> 
>>> I can't help but feel you are overcomplicating this.
>>> 
>>> Clients create a circuit by randomly picking 3 nodes out of the all-nodes
>>> pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over
>>> IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are
>>> IPv4-only, the whole selection can be thrown away and repeated.
>>> 
>>> That way IPv6-only relays could get some usage on a totally random basis, with
>>> no compromises and no restraining "of the next hop based on the previous one",
>>> not hurting anonymity. Clients just need to know which nodes are IPv4-only,
>>> IPv6-only or dual-stack, to not attempt unworkable combinations, discarding
>>> them instead.
>> 
>> Discarding unworkable combinations and restraining node choices seem
>> equivalent to me, although the relay weights may be different.
>> 
>>> And as there are more and more dual-stack or IPv6-only relays, the "throw
>>> away" step will be needed less and less often.
>> 
>> If you think this will work and is safe for client anonymity, then the next step
>> is to write a tor proposal. Having a concrete design could help with
>> analysing the anonymity implications as well.
>> 
>> I think IPv6-only relays are a lower priority than better IPv6 and dual-stack
>> client support, and IPv6-only bridge support  But we could do both in the
>> same release.
> 
> Hello tor-dev,
> 
> With my colleague JC Bach (in CC), we have proposed a last-year student
> project to address IPv6-related issues in Tor for the upcoming semester,
> at IMT Atlantique engineering school. There will be two students working
> on it. It is hard to say now how far we will arrive, especially because
> this is our first approach to Tor entrails.
> 
> So this message is to say we have good chances to come back here looking
> for help :-)

Hi Santiago,

This is great! We would like some help with Tor's IPv6 support.
And we are happy to help you and your students.

How many students?
How much time?
What are your goals for the project?
How much do you expect to get done?

We are at a Tor meeting this week.
We are revising Tor's IPv6 roadmap for the next year.
Next week, this page will be updated:
https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/IPv6Hackfest

We want to help people get code accepted into tor.
Here is how we write code:
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/GettingStarted.md
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandards.md

It can help to start by submitting a small change, so you can see how we work.
Then you can make larger changes more easily.
Our bug tracker is:
https://trac.torproject.org/

We are also in #tor-dev IRC on irc.oftc.net.

Please ask questions early, and ask often!
We would love to help you help tor.

Tim (teor)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171012/6d41efd6/attachment-0001.html>