Hi,
I am trying to configure a relay for the first time but I am behind a cgnat for IPv4. I have a public and open IPv6 though. However, ORPort doesn't accept [ipv6]:443 and it doesn't automatically bind to :::443 either.
This is running LEDE tor 0.2.8.9-1.
I couldn't find if worth to run over IPv6 or not.
Thanks,
On 21 Nov. 2016, at 23:09, Flavio Leitner fbl@sysclose.org wrote:
Hi,
I am trying to configure a relay for the first time but I am behind a cgnat for IPv4.
Sorry, Tor relays need an IPv4 address to join the network.
https://lists.torproject.org/pipermail/tor-relays/2015-November/008093.html
I have a public and open IPv6 though. However, ORPort doesn't accept [ipv6]:443
Do you see this warning?
[warn] Configured non-bridge only to listen on an IPv6 address.
You could try setting up an IPv6-only bridge.
and it doesn't automatically bind to :::443 either.
If a relay doesn't know its IPv6 address, it can't tell the rest of the Tor network. So there's no point binding to all IPv6 addresses.
https://lists.torproject.org/pipermail/tor-relays/2016-November/010938.html
This is running LEDE tor 0.2.8.9-1.
I couldn't find if worth to run over IPv6 or not.
No, IPv6-only relays won't work. Tor relays need to be able to connect to every other relay, and (at least for the foreseeable future) all relays have an IPv4 address.
T
Unfortunately, only a small portion of the world is IPV6 capable: https://www.google.com/intl/en/ipv6/statistics.html
IPV6 isn't backwards compatible, so literally every hop, skip, and jump on the Internet would need to be upgraded to support it. Many ISPs find it much easier and cheaper to just re-use the older IPV4 addresses.
On Nov 21, 2016 6:30 AM, "teor" teor2345@gmail.com wrote:
On 21 Nov. 2016, at 23:09, Flavio Leitner fbl@sysclose.org wrote:
Hi,
I am trying to configure a relay for the first time but I am behind a cgnat for IPv4.
Sorry, Tor relays need an IPv4 address to join the network.
https://lists.torproject.org/pipermail/tor-relays/2015- November/008093.html
I have a public and open IPv6 though. However, ORPort doesn't accept [ipv6]:443
Do you see this warning?
[warn] Configured non-bridge only to listen on an IPv6 address.
You could try setting up an IPv6-only bridge.
and it doesn't automatically bind to :::443 either.
If a relay doesn't know its IPv6 address, it can't tell the rest of the Tor network. So there's no point binding to all IPv6 addresses.
https://lists.torproject.org/pipermail/tor-relays/2016- November/010938.html
This is running LEDE tor 0.2.8.9-1.
I couldn't find if worth to run over IPv6 or not.
No, IPv6-only relays won't work. Tor relays need to be able to connect to every other relay, and (at least for the foreseeable future) all relays have an IPv4 address.
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
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 21.11.2016 14:39, Tristan wrote:
IPV6 isn't backwards compatible, so literally every hop, skip, and jump on the Internet would need to be upgraded to support it. Many ISPs find it much easier and cheaper to just re-use the older IPV4 addresses.
IPv4 addresses are running out, and using IPv6 is not rocket science. The more customers actively ask for it, the more ISPs will comply. Mine certainly does, and I even choose ADSL routers accordingly. I configure all computers that are capable for IPv6, both servers and clients.
My Tor nodes are IPv6 capable, so if the Tor authors find a way to run Tor over IPv6, I will be happy to help with testing things. The necessary ports are already reachable.
-Ralph
On 22 Nov. 2016, at 02:26, Ralph Seichter tor-relays-ml@horus-it.de wrote:
On 21.11.2016 14:39, Tristan wrote:
IPV6 isn't backwards compatible, so literally every hop, skip, and jump on the Internet would need to be upgraded to support it. Many ISPs find it much easier and cheaper to just re-use the older IPV4 addresses.
IPv4 addresses are running out, and using IPv6 is not rocket science.
The IPv4 requirement on Tor relays exists to preserve Tor client anonymity.
Relays require an IPv4 address, because every relay in the Tor network needs to be able to connect to every other relay. If some relays can't reach other relays, then clients won't be able to select paths at random.
Finding a way around this restriction needs further research into anonymity in non-clique networks. This is the hard part of the problem.
The more customers actively ask for it, the more ISPs will comply. Mine certainly does, and I even choose ADSL routers accordingly. I configure all computers that are capable for IPv6, both servers and clients.
My Tor nodes are IPv6 capable, so if the Tor authors find a way to run Tor over IPv6, I will be happy to help with testing things. The necessary ports are already reachable.
Tor is IPv6 capable, and has been for years.
Relays (and bridges) that have both an IPv4 and IPv6 address can support dual-stack and IPv6-only clients.
Do you advertise an IPv6 ORPort on your relays and bridges?
Exits can support client access to dual-stack and IPv6-only websites.
Do you set IPv6Exit on your exits?
T
On 21.11.2016 16:39, teor wrote:
Relays require an IPv4 address, because every relay in the Tor network needs to be able to connect to every other relay. If some relays can't reach other relays, then clients won't be able to select paths at random.
When I wrote that "using IPv6 is not rocket science" I meant this as a general comment related to the "oh, I'll just stick with IPv4 and hope for the best" attitude that many ISPs and users still show. I am aware that in a Tor context, reaching a critical mass of IPv6 capable nodes in order to provide a large enough pool to ensure anonymity is not trivial.
I meant to say that if the Tor authors need more IPv6 participants, I am happy to help.
Tor is IPv6 capable, and has been for years.
My nodes appear to see precious little IPv6 based traffic, though.
Do you advertise an IPv6 ORPort on your relays and bridges?
Yes. Netstat shows that Tor binds to both IPv4 and IPv6 addresses.
Do you set IPv6Exit on your exits?
$ grep -i IPv6 torrc ClientUseIPv6 1 ClientPreferIPv6DirPort 1 ClientPreferIPv6ORPort 1 IPv6Exit 1
Not sure if there is anything else I can use to signal that I support and prefer IPv6 via Tor settings?
-Ralph
On 22 Nov. 2016, at 03:18, Ralph Seichter tor-relays-ml@horus-it.de wrote:
On 21.11.2016 16:39, teor wrote:
Relays require an IPv4 address, because every relay in the Tor network needs to be able to connect to every other relay. If some relays can't reach other relays, then clients won't be able to select paths at random.
When I wrote that "using IPv6 is not rocket science" I meant this as a general comment related to the "oh, I'll just stick with IPv4 and hope for the best" attitude that many ISPs and users still show. I am aware that in a Tor context, reaching a critical mass of IPv6 capable nodes in order to provide a large enough pool to ensure anonymity is not trivial.
I meant to say that if the Tor authors need more IPv6 participants, I am happy to help.
Tor is IPv6 capable, and has been for years.
My nodes appear to see precious little IPv6 based traffic, though.
Do you advertise an IPv6 ORPort on your relays and bridges?
Yes. Netstat shows that Tor binds to both IPv4 and IPv6 addresses.
Do you have an ORPort with an IPv6 address in your torrc?
Does your relay's descriptor advertise a globally routable IPv6 ORPort address?
Do you set IPv6Exit on your exits?
$ grep -i IPv6 torrc ClientUseIPv6 1
This option allows your relay to use both IPv4 and IPv6. But relays prefer IPv4, and all directory mirrors and authorities have IPv4, so it doesn't have much effect on relays.
ClientPreferIPv6DirPort 1
This option was introduced and deprecated in the 0.2.8 alpha series, it has no effect.
ClientPreferIPv6ORPort 1
This will cause your relay to prefer IPv6 ORPorts for its own traffic, but clients will ask your relay to use IPv4.
IPv6Exit 1
This allows clients to connect to IPv6 sites via your Exit.
Not sure if there is anything else I can use to signal that I support and prefer IPv6 via Tor settings?
Help us test dual-stack client support in the 0.2.9 alpha series, by running a Tor alpha client with:
ClientUseIPv6 1 ClientPreferIPv6ORPort 1
OR
Help us test IPv6-only client support in the 0.2.9 alpha series, by running a Tor alpha client with:
ClientUseIPv4 0 UseMicrodescriptors 0
Here is the tor-dev thread with the details: https://lists.torproject.org/pipermail/tor-dev/2016-October/011597.html
Or you can download the latest alpha release and build from source: https://blog.torproject.org/blog/tor-0295-alpha-released-numerous-bugfixes
T
On 22 Nov. 2016, at 14:07, diffusae punasipuli@t-online.de wrote:
Hi!
On 22.11.2016 03:33, teor wrote:
0.2.9 alpha
Is it safe to use 0.2.9 alpha on relays
We think it is safe to use 0.2.9.5-alpha on relays. But we could do with more help testing it.
0.2.9.4-alpha and earlier had a bug which would serve stale consensuses to clients.
or will it be better to test the IPv6 client support by running Tor alpha client in a desktop environment?
It is better to test client support by running a client.
T
On Tue, Nov 22, 2016 at 04:07:56AM +0100, diffusae wrote:
Is it safe to use 0.2.9 alpha on relays or will it be better to test the IPv6 client support by running Tor alpha client in a desktop environment?
In general, more testing of 0.2.9 would be great. Just make sure you stay up to date as new releases come out, and that you pay some attention to it so you have a chance to notice bugs (and then report them).
If all the relays stay away from 0.2.9 until we call it stable, then it will definitely not be stable for relays. :)
--Roger
On 22.11.16 03:33, teor wrote:
Netstat shows that Tor binds to both IPv4 and IPv6 addresses.
Do you have an ORPort with an IPv6 address in your torrc?
Yes, for every IPv6-capable Tor node (one ISP I currently still work with unfortunately does not yet offer IPv6 support).
Does your relay's descriptor advertise a globally routable IPv6 ORPort address?
Yes. Atlas shows both IPv4 and IPv6 as "OR Addresses".
ClientPreferIPv6DirPort 1
This option was introduced and deprecated in the 0.2.8 alpha series, it has no effect.
That's unexpected. https://www.torproject.org/docs/tor-manual.html.en still lists this option. I went through this manual page for anything IPv6-related I could find.
Here is the tor-dev thread with the details: https://lists.torproject.org/pipermail/tor-dev/2016-October/011597.html
I will look into it, thanks.
-Ralph
On 23 Nov. 2016, at 02:54, Ralph Seichter tor-relays-ml@horus-it.de wrote:
On 22.11.16 03:33, teor wrote:
...
ClientPreferIPv6DirPort 1
This option was introduced and deprecated in the 0.2.8 alpha series, it has no effect.
That's unexpected. https://www.torproject.org/docs/tor-manual.html.en still lists this option. I went through this manual page for anything IPv6-related I could find.
Here is the ticket to deprecate that option: https://trac.torproject.org/projects/tor/ticket/19704
It's just waiting for someone to write the code and change the manual.
T
If I didn't understand right, a relay can use IPv6 but it will **not** bootstrap unless it is assigned an IPv4 address.
Does that summarize the discussion ?
Cheers Lluís
teor:
On 23 Nov. 2016, at 02:54, Ralph Seichter tor-relays-ml@horus-it.de wrote:
On 22.11.16 03:33, teor wrote:
...
ClientPreferIPv6DirPort 1
This option was introduced and deprecated in the 0.2.8 alpha series, it has no effect.
That's unexpected. https://www.torproject.org/docs/tor-manual.html.en still lists this option. I went through this manual page for anything IPv6-related I could find.
Here is the ticket to deprecate that option: https://trac.torproject.org/projects/tor/ticket/19704
It's just waiting for someone to write the code and change the manual.
T
On 26 Nov. 2016, at 21:14, Lluís 2015.msl@gmail.com wrote:
If I didn't understand right, a relay can use IPv6 but it will **not** bootstrap unless it is assigned an IPv4 address.
Does that summarize the discussion ?
Yes.
A relay *must* have an IPv4 address to publish a descriptor. A relay can also publish an IPv6 address it its descriptor.
Tim
Cheers Lluís
teor:
On 23 Nov. 2016, at 02:54, Ralph Seichter tor-relays-ml@horus-it.de wrote:
On 22.11.16 03:33, teor wrote:
...
ClientPreferIPv6DirPort 1
This option was introduced and deprecated in the 0.2.8 alpha series, it has no effect.
That's unexpected. https://www.torproject.org/docs/tor-manual.html.en still lists this option. I went through this manual page for anything IPv6-related I could find.
Here is the ticket to deprecate that option: https://trac.torproject.org/projects/tor/ticket/19704
It's just waiting for someone to write the code and change the manual.
T
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
T
It is end 2016 we should change from must have IPv4 to must have IPv6 and can have IPv4. 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. 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. Clients that are IPv4 only can use Dual-Stack relays so they won't have a problem.
On 26.11.2016 11:26, teor wrote:
On 26 Nov. 2016, at 21:14, Lluís 2015.msl@gmail.com wrote:
If I didn't understand right, a relay can use IPv6 but it will **not** bootstrap unless it is assigned an IPv4 address.
Does that summarize the discussion ?
Yes.
A relay *must* have an IPv4 address to publish a descriptor. A relay can also publish an IPv6 address it its descriptor.
Tim
Cheers Lluís
teor:
On 23 Nov. 2016, at 02:54, Ralph Seichter tor-relays-ml@horus-it.de wrote:
On 22.11.16 03:33, teor wrote:
... ClientPreferIPv6DirPort 1
This option was introduced and deprecated in the 0.2.8 alpha series, it has no effect.
That's unexpected. https://www.torproject.org/docs/tor-manual.html.en still lists this option. I went through this manual page for anything IPv6-related I could find.
Here is the ticket to deprecate that option: https://trac.torproject.org/projects/tor/ticket/19704
It's just waiting for someone to write the code and change the manual.
T
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
T
If that happens, many people won't be able to run a middle relay at home. Nobody in my neighborhood has an IPV6 address, and none of the WiFi spots in town have one either.
IPV6 just isn't used wisely enough. If any change happens, it should be *can* have just IPV6, and *can* have IPV4.
On Nov 27, 2016 11:59 AM, "root" tor@afo-tm.org wrote:
It is end 2016 we should change from must have IPv4 to must have IPv6 and can have IPv4. 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. 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. Clients that are IPv4 only can use Dual-Stack relays so they won't have a problem.
On 26.11.2016 11:26, teor wrote:
On 26 Nov. 2016, at 21:14, Lluís 2015.msl@gmail.com wrote:
If I didn't understand right, a relay can use IPv6 but it will **not** bootstrap unless it is assigned an IPv4 address.
Does that summarize the discussion ?
Yes.
A relay *must* have an IPv4 address to publish a descriptor. A relay can also publish an IPv6 address it its descriptor.
Tim
Cheers
Lluís
teor:
On 23 Nov. 2016, at 02:54, Ralph Seichter tor-relays-ml@horus-it.de
wrote:
On 22.11.16 03:33, teor wrote:
...
> ClientPreferIPv6DirPort 1 > This option was introduced and deprecated in the 0.2.8 alpha series, it has no effect.
That's unexpected. https://www.torproject.org/docs/tor-manual.html.en still lists this option. I went through this manual page for anything IPv6-related I could find.
Here is the ticket to deprecate that option: https://trac.torproject.org/projects/tor/ticket/19704
It's just waiting for someone to write the code and change the manual.
T
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
T
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I can't find any ISP in the Consensus that doesn't have IPv6 and more than 0,1% Consensus Weight, also 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.
On 27.11.2016 19:06, Tristan wrote:
If that happens, many people won't be able to run a middle relay at home. Nobody in my neighborhood has an IPV6 address, and none of the WiFi spots in town have one either.
IPV6 just isn't used wisely enough. If any change happens, it should be *can* have just IPV6, and *can* have IPV4.
On Nov 27, 2016 11:59 AM, "root" <tor@afo-tm.org mailto:tor@afo-tm.org> wrote:
It is end 2016 we should change from must have IPv4 to must have IPv6 and can have IPv4. 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. 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. Clients that are IPv4 only can use Dual-Stack relays so they won't have a problem. On 26.11.2016 11:26, teor wrote: On 26 Nov. 2016, at 21:14, Lluís <2015.msl@gmail.com <mailto:2015.msl@gmail.com>> wrote: If I didn't understand right, a relay can use IPv6 but it will **not** bootstrap unless it is assigned an IPv4 address. Does that summarize the discussion ? Yes. A relay *must* have an IPv4 address to publish a descriptor. A relay can also publish an IPv6 address it its descriptor. Tim Cheers Lluís teor: On 23 Nov. 2016, at 02:54, Ralph Seichter <tor-relays-ml@horus-it.de <mailto:tor-relays-ml@horus-it.de>> wrote: On 22.11.16 03:33, teor wrote: ... ClientPreferIPv6DirPort 1 This option was introduced and deprecated in the 0.2.8 alpha series, it has no effect. That's unexpected. https://www.torproject.org/docs/tor-manual.html.en <https://www.torproject.org/docs/tor-manual.html.en> still lists this option. I went through this manual page for anything IPv6-related I could find. Here is the ticket to deprecate that option: https://trac.torproject.org/projects/tor/ticket/19704 <https://trac.torproject.org/projects/tor/ticket/19704> It's just waiting for someone to write the code and change the manual. T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays> T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
(I've rearranged your threads for clarity, please bottom-post in future.)
On Nov 27, 2016 11:59 AM, "root" <tor@afo-tm.org mailto:tor@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@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
On Mon, 28 Nov 2016 10:01:03 +1100 teor teor2345@gmail.com wrote:
(I've rearranged your threads for clarity, please bottom-post in future.)
On Nov 27, 2016 11:59 AM, "root" <tor@afo-tm.org mailto:tor@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.
Could have been higher, if it weren't so cumbersome to configure.
If you honestly want Tor IPv6 adoption to go up, you should stop treating it as a second-class citizen in Tor, i.e. firstly remove the need to have a static literal IPv6 in the config. Not a single other network daemon requires that. And many home IPv6 allocations are dynamic, so users with those can't feasibly set that up even if they wanted.
What was it, "it's tricky to autodetect which IPv6 to use"? No it's really not. Even starting with a simple "ip route get 2001:db8::", then looking at what "src" you get and if it's a proper global one (in 2000::/3), and try to retrieve something from the Tor project over v6 to confirm that it actually works. Done.
On 29 Nov. 2016, at 18:44, Roman Mamedov rm@romanrm.net wrote:
On Mon, 28 Nov 2016 10:01:03 +1100 teor teor2345@gmail.com wrote:
(I've rearranged your threads for clarity, please bottom-post in future.)
On Nov 27, 2016 11:59 AM, "root" <tor@afo-tm.org mailto:tor@afo-tm.org> wrote:
It is end 2016 we should change from must have IPv4 to must have IPv6 and can have IPv4.
https://trac.torproject.org/projects/tor/ticket/5788
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.
Could have been higher, if it weren't so cumbersome to configure.
If you honestly want Tor IPv6 adoption to go up, you should stop treating it as a second-class citizen in Tor, i.e. firstly remove the need to have a static literal IPv6 in the config. Not a single other network daemon requires that. And many home IPv6 allocations are dynamic, so users with those can't feasibly set that up even if they wanted.
What was it, "it's tricky to autodetect which IPv6 to use"? No it's really not. Even starting with a simple "ip route get 2001:db8::", then looking at what "src" you get and if it's a proper global one (in 2000::/3),
It might surprise you, but I agree with most of what you've said so far.
In fact, several developers have spent the last few years laying the groundwork for IPv6 autodetection.
There's already a function in Tor that retrieves a list of local IPv4 and IPv6 addresses: https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1773
It's cross-platform, has a fallback strategy to retrieve the default interface address, and works quite well.
But there's more work to be done:
https://trac.torproject.org/projects/tor/ticket/5940
and try to retrieve something from the Tor project over v6 to confirm that it actually works. Done.
If we're talking clients, that's terribly bad for anonymity, because it would allow the Tor Project to collect the addresses of every IPv6 Tor user.
If we're talking relays, that's terribly bad for reliability, because it would make the Tor Project (website?) a single point of failure.
Here's how we actually do it for IPv4:
Relays retrieve their directory documents over IPv4, and a directory mirror tells them their (apparent, public) IPv4 address in the headers.
Here's why that won't work for IPv6:
There are no IPv6 DirPorts. (That is, you can set one up, but no client or relay will use it, because there is no way for relays to advertise an IPv6 DirPort.)
Here's a solution to that issue:
HTTP headers are also unauthenticated, so we want to switch to using NETINFO cells to discover IPv4 addresses. When we do this, it will work for IPv6 as well as IPv4.
Here's an issue caused by headers being unauthenticated:
https://trac.torproject.org/projects/tor/ticket/16205 https://trac.torproject.org/projects/tor/ticket/17605
Here's a general issue with autodetection:
On 28 Nov. 2016, at 10:01, teor teor2345@gmail.com wrote:
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.
https://trac.torproject.org/projects/tor/ticket/13112
We just fixed an issue like this with the IPv4 DirPort reachability test. I'd rather not re-introduce a similar issue for IPv6 ORPort reachability:
https://trac.torproject.org/projects/tor/ticket/18050
- 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
It can be hard for a relay to self-test its IPv6 ORPort, because it has to build a path with an IPv6 relay at the next-to-last hop. (When self-testing, the originating relay connects to its own ORPort via a few other relays.)
https://trac.torproject.org/projects/tor/ticket/4565
This is doable, but we'd need to write code to make this happen. And we'd need to test that current tor versions actually use IPv6 when asked, rather than using an existing IPv4 connection to the same relay.
https://trac.torproject.org/projects/tor/ticket/6939
Another issue with autodetection is which address should be chosen if there are multiple valid IP addresses. As far as I know, this is much more common with IPv6 than IPv4. Tor doesn't have code that discovers the IP address of the default route, instead, we use the OS order. (Well, most versions do. There was a bug in some recent versions that reordered addresses from the OS order.)
This seems sufficient, but we still get relay operators who are concerned that tor has chosen the wrong IPv4 address among multiple possible addresses on their machine.
For example: https://trac.torproject.org/projects/tor/ticket/17765 https://trac.torproject.org/projects/tor/ticket/17782 https://trac.torproject.org/projects/tor/ticket/17787
Here are some more open issues and questions:
IPv6-only bridges don't seem to work for clients: https://trac.torproject.org/projects/tor/ticket/4847
How do we properly support tor clients on IPv6? https://trac.torproject.org/projects/tor/ticket/17811
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.)
https://trac.torproject.org/projects/tor/ticket/17217 https://trac.torproject.org/projects/tor/ticket/17835
We'd need some version of this code to actually know whether the local IPv6 address worked. Otherwise, it's probably too risky to use it.
There's also a bug where IPv6-only clients can't use microdescriptors: https://trac.torproject.org/projects/tor/ticket/19608
And various path selection bugs around IPv6: https://trac.torproject.org/projects/tor/ticket/15518 https://trac.torproject.org/projects/tor/ticket/7193 https://trac.torproject.org/projects/tor/ticket/7478 https://trac.torproject.org/projects/tor/ticket/17849
I would love to have the time to write the code for better IPv6 support in tor. I would love to review patches for better IPv6 support in tor.
I'm not opposed to it at all.
I'm just saying that it might be a bit more complicated than you think to get it working well.
T
On 28 Nov. 2016, at 10:01, teor teor2345@gmail.com wrote:
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).
I'm sorry, I was wrong, IPv6-only bridge relays don't work for clients: https://trac.torproject.org/projects/tor/ticket/4847
I'd happily review a patch for this issue.
And just as happily review a chutney integration test for an IPv6-only bridge, to make sure we don't re-introduce the bug.
T
On Sun, Nov 27, 2016 at 6:01 PM, teor teor2345@gmail.com wrote:
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().
I want to add something to these figures: (modified code at end)
7.5% (535/7171) of relays have an IPv6 OR address 16.8% (7800233/46493235) of relay bandwidth has an IPv6 OR address
16.9% (343/2034) of guard relays have an IPv6 OR address 23.3% (7364620/31664680) of guard relay bandwidth has an IPv6 OR address
9.8% (89/908) of exit relays have an IPv6 OR address 18.2% (1954308/10754720) of exit relay bandwidth has an IPv6 OR address
This is better than I expected -- I thought IPv6-capable exit relays in particular would be few and far between. Still, I worry that we might hit a ceiling on IPv6 adoption by exits, because exit-friendly connectivity tends to come from places where keeping up with the bleeding edge in network gear isn't the top priority, like libraries and universities. Despite how many network researchers we have here, CMU (and therefore my exit node) doesn't have IPv6; campus IT tells me that it's on their list but there are several higher-priority hardware upgrades that need to happen first, and the ETA has been "three to five years from now" for my entire time here.
zw
#! /usr/bin/python3 import stem.descriptor.remote from stem import Flag
consensus = stem.descriptor.remote.DescriptorDownloader().get_consensus() total_count = total_bw = 0 total_guard_count = total_guard_bw = 0 total_exit_count = total_exit_bw = 0 ipv6_count = ipv6_bw = 0 ipv6_guard_count = ipv6_guard_bw = 0 ipv6_exit_count = ipv6_exit_bw = 0
for relay in consensus: is_guard = Flag.GUARD in relay.flags is_exit = Flag.EXIT in relay.flags for address in relay.or_addresses: if address[2]: # is_ipv6 has_ipv6 = True break else: has_ipv6 = False
if has_ipv6: ipv6_count += 1 ipv6_bw += relay.bandwidth if is_guard: ipv6_guard_count += 1 ipv6_guard_bw += relay.bandwidth if is_exit: ipv6_exit_count += 1 ipv6_exit_bw += relay.bandwidth
total_count += 1 total_bw += relay.bandwidth if is_exit: total_exit_count += 1 total_exit_bw += relay.bandwidth # Relays with both EXIT and GUARD are, IIUC, used only as exits. elif is_guard: total_guard_count += 1 total_guard_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)) print() print("%.1f%% (%d/%d) of guard relays have an IPv6 OR address" % (ipv6_guard_count*100.0/total_guard_count, ipv6_guard_count, total_guard_count)) print("%.1f%% (%d/%d) of guard relay bandwidth has an IPv6 OR address" % (ipv6_guard_bw*100.0/total_guard_bw, ipv6_guard_bw, total_guard_bw)) print() print("%.1f%% (%d/%d) of exit relays have an IPv6 OR address" % (ipv6_exit_count*100.0/total_exit_count, ipv6_exit_count, total_exit_count)) print("%.1f%% (%d/%d) of exit relay bandwidth has an IPv6 OR address" % (ipv6_exit_bw*100.0/total_exit_bw, ipv6_exit_bw, total_exit_bw))
On 30 Nov. 2016, at 02:18, Zack Weinberg zackw@cmu.edu wrote:
On Sun, Nov 27, 2016 at 6:01 PM, teor teor2345@gmail.com wrote:
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().
I want to add something to these figures: (modified code at end)
7.5% (535/7171) of relays have an IPv6 OR address 16.8% (7800233/46493235) of relay bandwidth has an IPv6 OR address
16.9% (343/2034) of guard relays have an IPv6 OR address 23.3% (7364620/31664680) of guard relay bandwidth has an IPv6 OR address
9.8% (89/908) of exit relays have an IPv6 OR address 18.2% (1954308/10754720) of exit relay bandwidth has an IPv6 OR address
Thanks!
This is better than I expected -- I thought IPv6-capable exit relays in particular would be few and far between.
IPv6 tends to experience less network filtering at both the client to tor and Exit to site stages. It would be great for Tor users if Tor used it more.
And if only 18.2% of exit relay bandwidth has an IPv6 address, and clients try 3 exits before giving up, this means there's still a 45.4% chance that an IPv6-only site accesses via DNS will fail.
(IPv6 addresses are fine - the client chooses an IPv6-capable relay.)
Still, I worry that we might hit a ceiling on IPv6 adoption by exits, because exit-friendly connectivity tends to come from places where keeping up with the bleeding edge in network gear isn't the top priority, like libraries and universities. Despite how many network researchers we have here, CMU (and therefore my exit node)
Exit nodes are chosen at random - they certainly aren't chosen by proximity to the client.
doesn't have IPv6; campus IT tells me that it's on their list but there are several higher-priority hardware upgrades that need to happen first, and the ETA has been "three to five years from now" for my entire time here.
That's unfortunate. It's also hard to get IPv6 when choosing between datacenter providers - there are many criteria, such as price and bandwidth (and location, and diversity) that matter, and it's hard to find somewhere that satisfies all of them.
zw
#! /usr/bin/python3 import stem.descriptor.remote from stem import Flag
consensus = stem.descriptor.remote.DescriptorDownloader().get_consensus() total_count = total_bw = 0 total_guard_count = total_guard_bw = 0 total_exit_count = total_exit_bw = 0 ipv6_count = ipv6_bw = 0 ipv6_guard_count = ipv6_guard_bw = 0 ipv6_exit_count = ipv6_exit_bw = 0
for relay in consensus: is_guard = Flag.GUARD in relay.flags is_exit = Flag.EXIT in relay.flags for address in relay.or_addresses: if address[2]: # is_ipv6 has_ipv6 = True break else: has_ipv6 = False
if has_ipv6: ipv6_count += 1 ipv6_bw += relay.bandwidth
Better do this here, too:
# Relays with both EXIT and GUARD are, IIUC, used only as exits.
(And yes, this is true, as long as Exits are scarce.)
if is_guard: ipv6_guard_count += 1 ipv6_guard_bw += relay.bandwidth if is_exit: ipv6_exit_count += 1 ipv6_exit_bw += relay.bandwidthtotal_count += 1 total_bw += relay.bandwidth if is_exit: total_exit_count += 1 total_exit_bw += relay.bandwidth # Relays with both EXIT and GUARD are, IIUC, used only as exits. elif is_guard: total_guard_count += 1 total_guard_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)) print() print("%.1f%% (%d/%d) of guard relays have an IPv6 OR address" % (ipv6_guard_count*100.0/total_guard_count, ipv6_guard_count, total_guard_count)) print("%.1f%% (%d/%d) of guard relay bandwidth has an IPv6 OR address" % (ipv6_guard_bw*100.0/total_guard_bw, ipv6_guard_bw, total_guard_bw)) print() print("%.1f%% (%d/%d) of exit relays have an IPv6 OR address" % (ipv6_exit_count*100.0/total_exit_count, ipv6_exit_count, total_exit_count)) print("%.1f%% (%d/%d) of exit relay bandwidth has an IPv6 OR address" % (ipv6_exit_bw*100.0/total_exit_bw, ipv6_exit_bw, total_exit_bw))
T
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@afo-tm.org mailto:tor@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@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
On 19 Dec. 2016, at 05:56, root tor@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@afo-tm.org mailto:tor@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@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/BC630CBBB518BE7E9F4E09712AB0269E9DC7D6...
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/1C90D3AEADFF3BCD079810632C8B85637924A5...
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
tor-relays@lists.torproject.org
-
diffusae -
Flavio Leitner -
Lluís -
Ralph Seichter -
Roger Dingledine -
Roman Mamedov -
root -
teor -
Tristan -
Zack Weinberg