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

[root]

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. 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. 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.
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