Hi, Since October 2017, a majority of directory authorities check relay IPv6 ORPorts. If your relay is configured with an IPv6 ORPort: ORPort [IPv6]:Port and it is not reachable over IPv6, it will be excluded from the consensus. This can happen if the address is wrong, or the IPv6 routing is wrong. If your relay isn't in the consensus, it will log warnings. Or, you can check Relay Search at: https://atlas.torproject.org If your relay is not Running, you can check the votes for your relay here: https://consensus-health.torproject.org/consensus-health.html If all the authorities don't vote for your relay, it has a tor or IPv4 problem. If a few do vote Running, it probably has an IPv6 problem. (If you want to be sure, check which authorities support ReachableIPv6 in the consensus health Known Flags table.) If you have an IPv6 problem, check the address, and check the routing. Here's what I do to check IPv6 on my relays when I set them up: From the relay: ping6 ipv6.google.com From another IPv6 machine: ping6 ipv6.google.com ping6 (the relay's IPv6 address) telnet (the relay's IPv6 ORPort) We're working on having better support for IPv6 across Relay Search and consensus health. T
Is there anywhere we could follow the IPv6 support progress? -- Johan Fleury PGP Key ID : 0x5D404386805E56E6
On 13 Dec 2017, at 15:31, Johan Fleury <jfleury@arcaik.net> wrote:
Is there anywhere we could follow the IPv6 support progress?
Here's a quick summary: We are focused on authorities and relays in 0.3.3. Later, we will work on clients and onion services. We chose this order because some client features won't work well until we have more IPv6 relays. I am trying to keep this wiki page up to date: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features Release announcements will also highlight major IPv6 features in Tor, Relay Search, and other projects. If you have a lot of time, follow along on tor-dev or the bug tracker. T
Thanks for all the work you did and keep doing! IPv6 is really important to me so I'm really pleased to see that you can move toward its full support in Tor :) -- Johan Fleury PGP Key ID : 0x5D404386805E56E6
+1, thanks for working on IPv6! Just curious and didn't see an answer on the roadmap -- do bandwidth authority measurements ever happen over IPv6?
On 13 Dec 2017, at 17:09, tor <tor@anondroid.com> wrote:
+1, thanks for working on IPv6!
Just curious and didn't see an answer on the roadmap -- do bandwidth authority measurements ever happen over IPv6?
This is up to the individual operators, but I can tell you the defaults. There's a few different places we could use IPv6, I'll answer from the client (bandwidth scanner) end: Client to entry: IPv6 is an option that is not on by default Entry to exit: relays do not connect to each other over IPv6, this is coming in 0.3.3 or 0.3.4 if we get the work done Exit to server: tor clients use IPv6 when available in recent Tor versions the operator would need to configure a server on an IPv6 or dual-stack DNS address T
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/11/2017 11:20 PM, teor wrote:
We're working on having better support for IPv6 across Relay Search and consensus health.
At my 2 relays (1AF72E8906 and D11D1187776) I have both ipv4 and ipv6 activated. The load is about 1.5 TByte/day. 300 GByte/day do come in over the ipv6 interface but will leave the relays over ipv4. May I asked why thjis imbalance does occur? - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWjOfaxccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTg4tAP9ekq6ucNWCEPfW5YLJdR+xC0yu CZmFgzdRESzDoq9/IwD/cM79QsRX2JBZ8HzGqb7gkwPDNpxv2LZAcj4aZMDg50c= =lAXq -----END PGP SIGNATURE-----
On 15 Dec 2017, at 21:09, Toralf Förster <toralf.foerster@gmx.de> wrote:
On 12/11/2017 11:20 PM, teor wrote:
We're working on having better support for IPv6 across Relay Search and consensus health.
At my 2 relays (1AF72E8906 and D11D1187776) I have both ipv4 and ipv6 activated. The load is about 1.5 TByte/day. 300 GByte/day do come in over the ipv6 interface but will leave the relays over ipv4.
What do you mean by "come in over"? Traffic from the internet to your relay? Are your relays Exits?
May I asked why thjis imbalance does occur?
The short answer: Tor is a cell-oriented protocol, it works regardless of the IP version or specific transport used. The long answer: Relays only connect to each other over IPv4. Relays accept connections from clients over IPv6 when configured with: ORPort [IPv6]:Port Tor clients have to be manually configured to use IPv6, but some software (like iOS OnionBrowser) configures IPv6 automatically for the user using OS-specific APIs. Exits make connections to internet servers over IPv6 when configured with: IPv6Exit 1 Recent Tor clients tell Exits that they will accept and prefer IPv6 for connections to servers with dual-stack DNS. So a typical circuit looks like: Client (IPv4 or IPv6) Entry (IPv4) Middle (IPv4) Exit (IPv4 or IPv6) Internet Web clients typically make small requests, and get larger responses. So if you're seeing more incoming IPv6, then it's probably because your relays are Exits. Otherwise, if you're seeing more outgoing, it's probably because your relays are Guards and Directory Mirrors. T
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/15/2017 11:46 AM, teor wrote:
On 15 Dec 2017, at 21:09, Toralf Förster <toralf.foerster@gmx.de> wrote:
On 12/11/2017 11:20 PM, teor wrote:
We're working on having better support for IPv6 across Relay Search and consensus health.
At my 2 relays (1AF72E8906 and D11D1187776) I have both ipv4 and ipv6 activated. The load is about 1.5 TByte/day. 300 GByte/day do come in over the ipv6 interface but will leave the relays over ipv4.
What do you mean by "come in over"? Traffic from the internet to your relay?
My ISP jsut gave me statustics about ipV4 and ipV6 traffic splitted as IN and OUT values
Are your relays Exits?
yes
Web clients typically make small requests, and get larger responses. So if you're seeing more incoming IPv6, then it's probably because your relays are Exits. That's likely the reason, right.
- -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWjOq5hccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTizUAP44yNnK35wuP6t+y7qyX4aqAvwn yBoTxToCzEKIPqiWWgD/SfLc2426rKSuYIUXa8w5cjpQxGe5ifNTp2mT1D7ukLo= =aU4x -----END PGP SIGNATURE-----
participants (4)
-
Johan Fleury -
teor -
tor -
Toralf Förster