[tor-relays] is it possible to relay using ipv6?

Mon Dec 19 02:33:45 UTC 2016

> On 19 Dec. 2016, at 05:56, root <tor at afo-tm.org> wrote:
> 
> On 28.11.2016 00:01, teor wrote:
>> (I've rearranged your threads for clarity, please bottom-post in future.)
>>>> On Nov 27, 2016 11:59 AM, "root" <tor at afo-tm.org <mailto:tor at afo-tm.org>> wrote:
>>>> 
>>>>    It is end 2016 we should change from must have IPv4 to must have
>>>>    IPv6 and can have IPv4.
>> When the proportion of Tor relays with IPv6 is above 60%, dual stack by
>> default on clients is a feasible option.
>> When the proportion exceeds 85% (the cube root of 60%), a switch may
>> become plausible.
>> The proportion of Tor relays with IPv6 is currently at 17% of
>> bandwidth.
>> You can help make Tor relays on IPv6-only possible by:
>> * running more Tor relays on dual-stack IPv4/IPv6, and
>> * running an IPv6-only Tor bridge, and
>> * testing the existing IPv6 client code.
>> (And writing patches that improve Tor's IPv6 support.)
>>>> All this new fancy ISPs that have FTTH and
>>>>    give you 500 MBit/s symmetric internet access have Carrier grade
>>>>    NAT because they were late to the Party and don't get IPv4 from
>>>>    the LIRs.
>>>>    You can't run there a relay because of the stupid you need a
>>>>    public accessible IPv4 address shit.
>> You can run a high-bandwidth IPv6-only bridge relay.
>> This really helps censored users on IPv6-only networks (or on networks
>> where IPv6 is less filtered).
>>>> So i see there a big gain in
>>>>    making that change, because then the guys with the big home pipes
>>>>    can run relays too. On the other hand datacenters that have only
>>>>    IPv4 are very uncommon, so there would be no big loss of relays.
>> AWS does not offer IPv6.
>> Many other services are the same, regardless of whether their AS has an
>> IPv6 allocation.
>>>>    Clients that are IPv4 only can use Dual-Stack relays so they won't
>>>>    have a problem.
>> No, they can't, there's no automatic IP version selection
>> ("happy eyeballs") in Tor's dual stack code. And if there were, it could
>> not be turned on by default, because the proportion of relays with IPv6
>> is too low.
>> (We would, however, accept a patch that automatically selected IPv4 or
>> IPv6 when specifically configured by the user.)
>>> On 28 Nov. 2016, at 06:41, root <tor at afo-tm.org> wrote:
>>> 
>>> I can't find any ISP in the Consensus that doesn't have IPv6 and more than 0,1% Consensus Weight, also
>> How did you arrive at this figure?
>> Can you publish the script somewhere?
>> While I agree most ASs have IPv6, they don't always offer it to users.
>> And while it's necessary that the AS has IPv6, it's not sufficient: the
>> relay operator needs to configure IPv6, both on the relay's network
>> interfaces, and in their torrc:
>> ORPort [IPv6]:Port
>> If IPv6 penetration among Tor relay ISPs/ASs is as high as you say, why
>> do only:
>> 7.6% (541/7145) of relays have an IPv6 OR address
>> 17.3% (7972687/45960632) of relay bandwidth has an IPv6 OR address
>> With IPv6 relay bandwidth this low, we can't even have clients try IPv6
>> by default - there are too few relays to meet Tor's existing 60% path
>> threshold in get_frac_paths_needed_for_circs().
>> So should Tor autoconfigure IPv6 on relays?
>> How do we deal with relays which have an IPv6 address that doesn't
>> work?
>> * Relays should self-test their IPv6 ORPort, but there's a race
>>   condition here:
>>   * if relays only publish their IPv6 ORPort after testing it, they
>>     can flip between having and not having an IPv6 address in their
>>     descriptor. This is bad for descriptor stability.
>> * If relays don't self-test their IPv6 ORPort, authorities will exclude
>>   them from the consensus if it turns out to be unreachable. This is a
>>   more significant issue if Tor autoconfigures IPv6
>> There are similar issues when clients build paths in a mixed IPv4/IPv6
>> network.
>> Source for the IPv6 figures:
>> import stem.descriptor.remote
>> consensus = stem.descriptor.remote.get_consensus()
>> ipv6_count = ipv6_bw = total_count = total_bw = 0
>> for relay in consensus:
>>   has_ipv6 = False
>>   for address in relay.or_addresses:
>>     (_, _, address_is_ipv6) = address
>>     if address_is_ipv6:
>>       has_ipv6 = True
>>   if has_ipv6:
>>     ipv6_count += 1
>>     ipv6_bw += relay.bandwidth
>>   total_count += 1
>>   total_bw += relay.bandwidth
>> print("%.1f%% (%d/%d) of relays have an IPv6 OR address" %
>>       (ipv6_count*100.0/total_count, ipv6_count, total_count))
>> print("%.1f%% (%d/%d) of relay bandwidth has an IPv6 OR address" %
>>       (ipv6_bw*100.0/total_bw, ipv6_bw, total_bw))
>>> one Relay at a FTTH ISP that offer 200+ MBit/s symmetric and only public IPv6 would gain more Consensus Weight than all Relays we would have lost due to that change together.
>> I think you're confusing ASs with IPv6 allocations and relays with
>> configured IPv6. They're very different things. And there's no guarantee
>> that a single home relay would push 75Mbps actual traffic. And there are
>> relay diversity issues to consider.
>> T
> I'm sorry but that data is rubbish because there is currently (afaik) no way to know if you can exit through a relay to IPv6 or not. E.g. IPredator, they don't advertise a Ipv6 OR port while you can fine exit through it to a IPv6 clearnet site.

Clients can discover if a relay exits to IPv6 using the IPv6 Exit policy.

IPredator has an IPv6 Exit Policy:
https://atlas.torproject.org/#details/BC630CBBB518BE7E9F4E09712AB0269E9DC7D626

Clients can discover if a relay accepts incoming connections over IPv6 if it has an IPv6 ORPort.

splitDNA has an IPv6 ORPort:
https://atlas.torproject.org/#details/1C90D3AEADFF3BCD079810632C8B85637924A58E

Since the question above was about paths through the tor network, I chose to focus on IPv6 ORPorts.

> So before trying to underline something with facts, we would need a way to verify them which is currently not the case. So it is impossible to say if this change would cause harm or would strength the network.

It would cause harm by restricting the paths that clients can choose; we need further research to work out how clients can securely select paths in a non-clique network.

> So having Tor automatically configure it's IPv6 OR Port would be already a big improvement and would move your data a little bit more in a realistic frame even though it is still very far from realistic.

I think automatic IPv6 ORPort configuration would be a great feature!
Now we just need to find people to write, review, and test the patch(es).

> BTW i guarantee you even 300 MBit/s that i will dedicate to Tor if this change will happen because i will run my node on a 1000/500 MBit/s line and have here a Dell PowerEdge T20 with Intel Xeon E3-1225 v3 which should be fine with even pushing a gigabit with 4 Tor instances

Another server on the Tor network would be great.

But tor gains its security by having clients choose paths at random, between multiple independent operators, with different setups, in different countries.

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------