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

[teor]

> On 14 Oct 2017, at 01:06, Santiago R.R. <santiagorr at riseup.net> wrote:
> 
>> El 12/10/17 a las 12:22, teor escribió:
>> 
>> On 12 Oct 2017, at 09:15, Santiago R.R. <santiagorr at riseup.net> wrote:
> 
> …
>> 
>> 
>>    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.
>> 
>>     …
>> 
>> 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?
> 
> There will be two.
> 
>> How much time?
> 
> From now until mid-March. Students will have 135h in their schedules to
> work on their projects.
> 
>> What are your goals for the project?
> 
> For now, it's still open, but addressing IPv6 support. We should limit
> the scope soon, according to open related tickets that could be feasible
> to work on.
> 
>> How much do you expect to get done?
> 
> At least, choose a couple of easy-tagged IPv6 tickets, and close them.
> However, it's difficult to state on this right now.

135h is enough to submit a small, one-line change to get used to the tor
patch process, and then do something more substantial with some testing.

Understanding the code, and testing and documenting the fix can take more
time than writing the patch.

Your students could work on getting IPv6 bridges working with private IPv4
addresses. The bridge needs to include a placeholder IPv4 address in its
descriptor, and then the bridge client needs to ignore this address.

Or they could work out why Tor Browser often fails IPv6-only sites like
ipv6.google.com?

We think it's because IPv4 exits don't resolve AAAA addresses. Failed
addresses should've resolved and sent back to the client. And then the
client can use the address to pick its next exit.

We've made some progress on both of these issues, but then ran out of
time.

>> 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
> 
> Good to know about this!

Sorry, this was the wrong link.

Please use:

https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Montreal/IPv6Hackfest

https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features

(We are still adding features to the matrix.)

>> 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.
> 
> Understood.
> 
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171019/3530c11c/attachment.html>