#23819: Support IPv6 link-local interface addresses -----------------------------+------------------------------------ Reporter: Zakhar | Owner: (none) Type: enhancement | Status: needs_revision Priority: Medium | Milestone: Tor: 0.3.3.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: ipv6 link-local | Actual Points: 1 Parent ID: | Points: 1 Reviewer: | Sponsor: -----------------------------+------------------------------------
Comment (by Zakhar): Although this is ruling out a stupid use case: {{{ $ ifconfig enp3s0 Link encap:Ethernet HWaddr cc:cc:cc:cc:cc:cc (...) adr inet6: fe80::329f:52e6:fa18:88e3/64 Scope:Lien $ ping6 -c2 -I enp3s0 ff02::1 PING ff02::1(ff02::1) from fe80::329f:52e6:fa18:88e3 enp3s0: 56 data bytes 64 bytes from fe80::329f:52e6:fa18:88e3: icmp_seq=1 ttl=64 time=0.085 ms 64 bytes from fe80::224:d4ff:feab:9253: icmp_seq=1 ttl=64 time=0.437 ms (DUP!) --- ff02::1 ping statistics --- 2 packets transmitted, 2 received, +1 duplicates, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.085/0.203/0.437/0.165 ms $ ip -6 neigh fe80::224:d4ff:feab:9253 dev enp3s0 lladdr 00:24:d4:ab:92:53 router DELAY $ curl -g -6 http://[fe80::224:d4ff:feab:9253%25enp3s0]/ -vv  Trying fe80::224:d4ff:feab:9253... Connected to fe80::224:d4ff:feab:9253 (fe80::224:d4ff:feab:9253) port 80 (#0) GET / HTTP/1.1 Host: fe80::224:d4ff:feab:9253 User-Agent: curl/7.47.0 Accept: */* < HTTP/1.1 200 OK < Server: nginx < Date: Thu, 02 Nov 2017 21:46:07 GMT < Content-Type: text/html; charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Expires: Thu, 02 Nov 2017 21:46:06 GMT < Cache-Control: no-cache < Cache-Control: must-revalidate,no-store < <!DOCTYPE HTML> <html> <head> (...) }}} What I am trying to show here, is that you '''CAN''' call your server (hence do TCP/IP) on an ipv6-link-local address, provided you add the interface specification. This is the same as ipv4 calling your server on 192.168.0.254 Should you try to route such an ipv4 through Tor, it would probably fail because the exit server, as a security policy might have blocked 192.168.0.0/16 ... but that can still work, as a test case, if the exit server is not blocking it for whatever insane reason. If Tor would allow the same '''normally-local-ipv6''' packet to be played by the exit server, that would be even worse, we would have to send the whole ipv6-link-local + interface to the exit server. This would also probably be even a bigger security issue than allowing ipv4-LAN-addresses on the exit node. So let's says this use case for ipv6 is ruled out for now. We '''can''' route a ''normally-LAN'' address through tor with ipv4 (with little chance it succeeds) but '''cannot''' do the same for ipv6. I guess we can live with that... and therefore to be clear shouldn't we change the ticket name to make it only about binding? Proposition: Support '''binding''' IPv6 link-local ~~interface~~ addresses With such a title, it would be clearer that the patch is only about binding/listener, and does not intend to do anything about routing those addresses via Tor. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23819#comment:10> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs