IPv6 to IPv4 tor exit relays would fix many daily tor-problems
I have access to a fast internet connection. This connection only have ipv6 IP and i can access the IPv4 network over the ISPs 6to4 bridge. So there are already many users using one single IPv4 address at this ISP. Sadly its technical as far as i understood at the moment not possible to run a IPv6-only exit node. If i could run such, the people on the world that could access IPv6-adresses also would be able to connect to my IPv6 exit node. Then they can finally access over IPv4 all the webpages that normally block tor users, bother them with captchas, ... Such tor-users could also finally access freenode irc again. I would like to give such service-blocked tor users again access to all websites of the internet by providing such a 6to4-tor exit node. Is there any progress at this?
On 29 Jun 2017, at 23:55, Fof582 <fof582@protonmail.com> wrote:
I have access to a fast internet connection. This connection only have ipv6 IP and i can access the IPv4 network over the ISPs 6to4 bridge.
So there are already many users using one single IPv4 address at this ISP.
It is not a good idea to run a Tor Exit on a shared IP address: many websites block Tor Exits.
Sadly its technical as far as i understood at the moment not possible to run a IPv6-only exit node.
It is not possible to run any Tor relay on an IPv6-only connection. This includes Exit nodes and Bridges. For Bridges, we need to fix this bug: https://trac.torproject.org/projects/tor/ticket/4847 For public relays (including Exits), we need more research to be done. We don't know how to give users good anonymity when some relays can't connect to other relays. This would happen if we allowed IPv4-only relays and IPv6-only relays in the same network.
If i could run such, the people on the world that could access IPv6-adresses also would be able to connect to my IPv6 exit node.
That's not how Tor works: Clients can access a Tor Entry node through IPv4 or IPv6. (IPv4 is the default, IPv6 needs a config option, because there aren't enough IPv6 entry nodes yet. But recent versions of Tor Browser ship with some IPv6 default bridges that are used automatically.) Then they build a circuit to a Tor Exit Node through IPv4. Then they access the Internet through IPv4 or IPv6.
Then they can finally access over IPv4 all the webpages that normally block tor users, bother them with captchas, ... Such tor-users could also finally access freenode irc again.
I would like to give such service-blocked tor users again access to all websites of the internet by providing such a 6to4-tor exit node.
Many Exit operators already enable IPv6Exit. Most Tor clients automatically Exit through IPv6 when it is available. (It is the default in recent versions of Tor.)
Is there any progress at this?
Yes! See above. 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 ------------------------------------------------------------------------
We don't know how to give users good anonymity when some relays can't connect to other relays. This would happen if we allowed IPv4-only relays and IPv6-only relays in the same network.
With "IPv6 only" relays available in the consensus the answer may be... when their count is the same as when IPv4 relays were at the same count, what was being stated and roughly understood about tor's anonymity back then? And is it much different from today. And given respective traffic loadings, etc.
grarpamp <grarpamp@gmail.com> wrote:
We don't know how to give users good anonymity when some relays can't connect to other relays. This would happen if we allowed IPv4-only relays and IPv6-only relays in the same network.
With "IPv6 only" relays available in the consensus the answer may be... when their count is the same as when IPv4 relays were at the same count, what was being stated and roughly understood about tor's anonymity back then? And is it much different from today. And given respective traffic loadings, etc.
Also, is there a problem with having IPv6-only exit service where a relay is accessable via IPv4 for clients and other relays? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
On 30 Jun 2017, at 16:55, Scott Bennett <bennett@sdf.org> wrote:
grarpamp <grarpamp@gmail.com> wrote:
We don't know how to give users good anonymity when some relays can't connect to other relays. This would happen if we allowed IPv4-only relays and IPv6-only relays in the same network.
With "IPv6 only" relays available in the consensus the answer may be... when their count is the same as when IPv4 relays were at the same count, what was being stated and roughly understood about tor's anonymity back then? And is it much different from today. And given respective traffic loadings, etc.
Tor client anonymity relies on every relay being able to connect to every other relay (a "clique network"). Starting the network on IPv4 met this requirement. As did adding some dual-stack relays, because every dual-stack relay could connect to every other relay over IPv4. But adding IPv6-only relays breaks the clique requirement. We need researchers to help us work out how to add IPv6-only relays (or any other relays that don't clique) and keep clients safe at the same time. Once we know how to do this, we can add code to make IPv6-only relays work, and add them to the consensus, and tell clients to use them.
Also, is there a problem with having IPv6-only exit service where a relay is accessable via IPv4 for clients and other relays?
Most tor clients send a DNS name, and flags that say whether they allow IPv4 and IPv6, and which one they prefer. They rely on the Exit to resolve the IP address and connect to the site. On the current network, an IPv6-only Exit won't get the Exit flag, and therefore won't get much client traffic. And it probably shouldn't, until almost all internet sites are on IPv6. Otherwise clients will ask it to connect to IPv4-only sites, and it will fail them. 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 ------------------------------------------------------------------------
On 06/29/2017 08:41 PM, teor wrote:
On 30 Jun 2017, at 16:55, Scott Bennett <bennett@sdf.org> wrote:
<SNIP>
Also, is there a problem with having IPv6-only exit service where a relay is accessable via IPv4 for clients and other relays?
Most tor clients send a DNS name, and flags that say whether they allow IPv4 and IPv6, and which one they prefer. They rely on the Exit to resolve the IP address and connect to the site.
On the current network, an IPv6-only Exit won't get the Exit flag, and therefore won't get much client traffic.
OK, so exits need both IPv4 and IPv6.
And it probably shouldn't, until almost all internet sites are on IPv6. Otherwise clients will ask it to connect to IPv4-only sites, and it will fail them.
This confuses me a little. From another subthread: On 06/29/2017 02:02 PM, teor wrote: <SNIP>
Many Exit operators already enable IPv6Exit. Most Tor clients automatically Exit through IPv6 when it is available. (It is the default in recent versions of Tor.)
What happens for Tor clients without local IPv6 stacks, when they use a dual-stack exit to hit a dual-stack site? An IPv4 connection, right? If the client is on a dual-stack machine, it would default to IPv6, right? So Tor circuits would be doing IPv6 over IPv4, yes?
On 30 Jun 2017, at 19:26, Mirimir <mirimir@riseup.net> wrote:
On 06/29/2017 08:41 PM, teor wrote:
On 30 Jun 2017, at 16:55, Scott Bennett <bennett@sdf.org> wrote:
<SNIP>
Also, is there a problem with having IPv6-only exit service where a relay is accessable via IPv4 for clients and other relays?
Most tor clients send a DNS name, and flags that say whether they allow IPv4 and IPv6, and which one they prefer. They rely on the Exit to resolve the IP address and connect to the site.
On the current network, an IPv6-only Exit won't get the Exit flag, and therefore won't get much client traffic.
OK, so exits need both IPv4 and IPv6.
Or just IPv4 works fine, too.
And it probably shouldn't, until almost all internet sites are on IPv6. Otherwise clients will ask it to connect to IPv4-only sites, and it will fail them.
This confuses me a little. From another subthread:
On 06/29/2017 02:02 PM, teor wrote:
<SNIP>
Many Exit operators already enable IPv6Exit. Most Tor clients automatically Exit through IPv6 when it is available. (It is the default in recent versions of Tor.)
What happens for Tor clients without local IPv6 stacks, when they use a dual-stack exit to hit a dual-stack site? An IPv4 connection, right?
The Tor protocol is cells over circuits. Those circuits are built over SSL connections, which use whatever IP versions are available to the client, relays, and remote site / onion service. Each connection's IP version can be different across the circuit. For client to entry, this is mostly IPv4. For relays, this is always IPv4. For exit to internet site, this is IPv6 if available, and IPv4 otherwise. For service entry to onion service, this is mostly IPv4.
If the client is on a dual-stack machine, it would default to IPv6, right? So Tor circuits would be doing IPv6 over IPv4, yes?
No, there's no IP encapsulation inside Tor circuits, only cells. 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 ------------------------------------------------------------------------
On 06/30/2017 01:43 PM, teor wrote:
On 30 Jun 2017, at 19:26, Mirimir <mirimir@riseup.net> wrote:
On 06/29/2017 08:41 PM, teor wrote:
On 30 Jun 2017, at 16:55, Scott Bennett <bennett@sdf.org> wrote:
<SNIP>
Also, is there a problem with having IPv6-only exit service where a relay is accessable via IPv4 for clients and other relays?
Most tor clients send a DNS name, and flags that say whether they allow IPv4 and IPv6, and which one they prefer. They rely on the Exit to resolve the IP address and connect to the site.
On the current network, an IPv6-only Exit won't get the Exit flag, and therefore won't get much client traffic.
OK, so exits need both IPv4 and IPv6.
Or just IPv4 works fine, too.
:)
And it probably shouldn't, until almost all internet sites are on IPv6. Otherwise clients will ask it to connect to IPv4-only sites, and it will fail them.
This confuses me a little. From another subthread:
On 06/29/2017 02:02 PM, teor wrote:
<SNIP>
Many Exit operators already enable IPv6Exit. Most Tor clients automatically Exit through IPv6 when it is available. (It is the default in recent versions of Tor.)
What happens for Tor clients without local IPv6 stacks, when they use a dual-stack exit to hit a dual-stack site? An IPv4 connection, right?
The Tor protocol is cells over circuits.
Those circuits are built over SSL connections, which use whatever IP versions are available to the client, relays, and remote site / onion service. Each connection's IP version can be different across the circuit.
For client to entry, this is mostly IPv4. For relays, this is always IPv4. For exit to internet site, this is IPv6 if available, and IPv4 otherwise.
So a client with only IPv4 stack, using a dual-stack exit, can hit IPv6-only Internet sites. Right? That's very cool! Because then, Tor not only offers privacy and anonymity advantages, but also allows users without IPv6 connectivity to reach IPv6-only Internet sites. That will be increasingly important as IPv6-only sites become common.
For service entry to onion service, this is mostly IPv4.
So IPv6-only machines can host onion services, as long as they use a dual-stack guard. Also very cool.
If the client is on a dual-stack machine, it would default to IPv6, right? So Tor circuits would be doing IPv6 over IPv4, yes?
No, there's no IP encapsulation inside Tor circuits, only cells.
Yes, of course. But Tor can be rather like an IPv4-IPv6 adapter.
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 Fri, Jun 30, 2017 at 3:41 AM, teor <teor2345@gmail.com> wrote:
Tor client anonymity relies on every relay being able to connect to every other relay (a "clique network").
Depends on what you're up against. Assumed ability to connect to and traffic through entire consensus isn't the same as the anonymity set of... available path permutations, locations, traffic density, operators, etc. It's a constraint imposed upon the consensus due to insufficient metadata flags / tags about each relays capabilities such that clients can build the type of circuits they want, even possibly setting pathing and request cell preferences for IPv6 only (maybe they just have KAME turtle love and don't care about v4 at all).
Most tor clients send a DNS name, and flags that say whether they allow IPv4 and IPv6, and which one they prefer. They rely on the Exit to resolve the IP address and connect to the site. On the current network, an IPv6-only Exit won"t get the Exit flag, and therefore won"t get much client traffic. And it probably shouldn"t, until almost all internet sites are on IPv6. Otherwise clients will ask it to connect to IPv4-only sites, and it will fail them.
But thats exactly the case in a "tor exit that can only be reached by ipv6, but reach itself ipv4 and ipv6". Can such a exit be run at the moment? IPv6 can be used on such a exit for in+out-traffic, IPv4 can be used to reach out everything - its just behind a NAT. IPv4-only sites can be reached from the exit. The only case is that the exit itself can only be reached over IPv6 because of IPv4-NAT.
On 5 Jul 2017, at 10:27, Fof582 <fof582@protonmail.com> wrote:
Most tor clients send a DNS name, and flags that say whether they allow IPv4 and IPv6, and which one they prefer. They rely on the Exit to resolve the IP address and connect to the site.
On the current network, an IPv6-only Exit won"t get the Exit flag, and therefore won"t get much client traffic. And it probably shouldn"t, until almost all internet sites are on IPv6. Otherwise clients will ask it to connect to IPv4-only sites, and it will fail them.
But thats exactly the case in a "tor exit that can only be reached by ipv6, but reach itself ipv4 and ipv6". Can such a exit be run at the moment? IPv6 can be used on such a exit for in+out-traffic, IPv4 can be used to reach out everything - its just behind a NAT. IPv4-only sites can be reached from the exit. The only case is that the exit itself can only be reached over IPv6 because of IPv4-NAT.
No, Exits need bidirectional connectivity over IPv4, because clients need to build circuits to them via IPv4-only middle relays. (Otherwise the Exit would have to connect our to the middle relay before the path would work, which breaks the clique requirement.) A similar requirement applies to all public relays, and will continue to apply, until some researchers show how to preserve client anonymity in a non-clique network. IPv6-only bridges are a special case, because they only connect out. And they look like clients to the rest of the network. We just need to fix the Tor code that makes them work: https://trac.torproject.org/projects/tor/ticket/4847 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 ------------------------------------------------------------------------
participants (5)
-
Fof582 -
grarpamp -
Mirimir -
Scott Bennett -
teor