Hi, I'm using Tor in transparent mode, and I'm running into a rather inconvenient behavior.
VirtualAddrNetworkIPv6 refuses to parse unless the network address given is a /40 or broader. However, IPv6 ULA, which makes it very easy to give Tor its own subnet no-strings-attached, strictly grants a /48 prefix.
As a result, I am faced with a choice between deeply suboptimal options:
1.) Use VirtualAddrNetworkIPv4, as I've done in the past. This results in _fewer_ addresses being available to Tor than an IPv6 /48, which I feel illustrates the issues with requiring a /40 quite clearly.
2.) Squat on some portion of the IPv6 address space I don't actually own. This is entirely unpalatable
On Fri, Sep 16, 2016 at 5:13 AM, Alex Elsayed eternaleye@gmail.com wrote:
Hi, I'm using Tor in transparent mode, and I'm running into a rather inconvenient behavior.
VirtualAddrNetworkIPv6 refuses to parse unless the network address given is a /40 or broader. However, IPv6 ULA, which makes it very easy to give Tor its own subnet no-strings-attached, strictly grants a /48 prefix.
As a result, I am faced with a choice between deeply suboptimal options:
1.) Use VirtualAddrNetworkIPv4, as I've done in the past. This results in _fewer_ addresses being available to Tor than an IPv6 /48, which I feel illustrates the issues with requiring a /40 quite clearly.
2.) Squat on some portion of the IPv6 address space I don't actually own. This is entirely unpalatable
This impacts with onioncat as well. I'm curious as to any /40 rationale, though I suspect a historical brainfart typo.
On 17 Sep 2016, at 05:20, grarpamp grarpamp@gmail.com wrote:
On Fri, Sep 16, 2016 at 5:13 AM, Alex Elsayed eternaleye@gmail.com wrote:
Hi, I'm using Tor in transparent mode, and I'm running into a rather inconvenient behavior.
VirtualAddrNetworkIPv6 refuses to parse unless the network address given is a /40 or broader. However, IPv6 ULA, which makes it very easy to give Tor its own subnet no-strings-attached, strictly grants a /48 prefix.
As a result, I am faced with a choice between deeply suboptimal options:
1.) Use VirtualAddrNetworkIPv4, as I've done in the past. This results in _fewer_ addresses being available to Tor than an IPv6 /48, which I feel illustrates the issues with requiring a /40 quite clearly.
2.) Squat on some portion of the IPv6 address space I don't actually own. This is entirely unpalatable
This impacts with onioncat as well. I'm curious as to any /40 rationale, though I suspect a historical brainfart typo.
In fact, a min/max typo, which contributed to the IPv6 /40 mistake: https://trac.torproject.org/projects/tor/ticket/20151 (Feel free to log tickets at https://trac.torproject.org/projects/tor when these sorts of issues come up.)
In the interim, Alex, have you tried using [FC00::]/7 ? From the tor manual entry on VirtualAddrNetworkIPv6:
When providing proxy server service to a network of computers using a tool like dns-proxy-tor, change the IPv4 network to "10.192.0.0/10" or "172.16.0.0/12" and change the IPv6 network to "[FC00]/7".
(Yes, there is a typo in the last IPv6 address as well. https://trac.torproject.org/projects/tor/ticket/20153 )
Tim
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 Sat, 17 Sep 2016 07:46:05 +1000, teor wrote:
On 17 Sep 2016, at 05:20, grarpamp grarpamp@gmail.com wrote:
On Fri, Sep 16, 2016 at 5:13 AM, Alex Elsayed eternaleye@gmail.com wrote:
Hi, I'm using Tor in transparent mode, and I'm running into a rather inconvenient behavior.
VirtualAddrNetworkIPv6 refuses to parse unless the network address given is a /40 or broader. However, IPv6 ULA, which makes it very easy to give Tor its own subnet no-strings-attached, strictly grants a /48 prefix.
As a result, I am faced with a choice between deeply suboptimal options:
1.) Use VirtualAddrNetworkIPv4, as I've done in the past. This results in _fewer_ addresses being available to Tor than an IPv6 /48, which I feel illustrates the issues with requiring a /40 quite clearly.
2.) Squat on some portion of the IPv6 address space I don't actually own. This is entirely unpalatable
This impacts with onioncat as well. I'm curious as to any /40 rationale, though I suspect a historical brainfart typo.
In fact, a min/max typo, which contributed to the IPv6 /40 mistake: https://trac.torproject.org/projects/tor/ticket/20151 (Feel free to log tickets at https://trac.torproject.org/projects/tor when these sorts of issues come up.)
Ah, interesting; thanks for filing that! I'll be commenting on it with some nits on terminology (old code was max _prefix length_, the message and your change are min _subnet size_ - IMO, the old code was right-ish in its variable names, and the message simply reframed it to a less technical perspective).
In the interim, Alex, have you tried using [FC00::]/7 ? From the tor manual entry on VirtualAddrNetworkIPv6:
When providing proxy server service to a network of computers using a tool like dns-proxy-tor, change the IPv4 network to "10.192.0.0/10" or "172.16.0.0/12" and change the IPv6 network to "[FC00]/7".(Yes, there is a typo in the last IPv6 address as well. https://trac.torproject.org/projects/tor/ticket/20153 )
That's actually a separate complaint - Using [FC00]/7 _would_ be my option 2, and constitute squatting on sections of the address space I don't own. In particular:
- [FC00]/8 is _reserved by the IANA_, and beyond that, CJDNS is already squatting on it. :/ - [FD00]/8 is _in active, standards-blessed use_ - to be specific, it's what IPv6 ULA uses!
Using [FC00]/7 would actually cause me _practical_ problems as well, because I'm doing this on my OpenWRT router... which uses an IPv6 ULA for the LAN, with Network Prefix Translation to the WAN IPv6 network so that the local net doesn't renumber if upstream changes.
If I used [FC00]/7, Tor's manufactured addresses could overlap with my actual LAN!
On Fri, Sep 16, 2016 at 6:10 PM, Alex Elsayed eternaleye@gmail.com wrote:
(Yes, there is a typo in the last IPv6 address as well. https://trac.torproject.org/projects/tor/ticket/20153 )
Yes Tor is making some quite bad text representation issues so I added summary of them to this ticket.
- [FC00]/8 is _reserved by the IANA_, and beyond that, CJDNS is already
squatting on it. :/
As all their independant users are not really one 'AS number' like entity where the concept of 'local' policy would then apply to all, CJDNS does present some problems in this area. Possibly with interoperating with other IPv6 based overlay networks and adapters / tunnels. I hope they're aware of them. Unfortunately to fix I think they'd have to rearchitect, or at least renumber to squat elsewhere... both being rather unpalatable from their point of view. Specifically, if I recall, they're abusing the 'L' bit in the RFC, squatting the undefined 0. I don't think so but would have to double check if they're also stomping the 1. Obviously generating into a proper L=1 /48 is not practical. As with the .onion and .i2p DNS reservations, I'd highly suggest CJDNS apply to IANA for a special /whatever they could then generate into.
Yes in general networks shouldn't ride on top of space others are legitimately using per RFC, such as the ULA space. Even riding on some unallocated unicast space outside 2000::/3 that IANA is unlikely to ever allocate to the global IPv6 routing table of host networks would be preferred over that. That is, if you don't apply for a special purpose allocation.
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special... https://tools.ietf.org/html/rfc4193
On Sat, 17 Sep 2016 04:45:00 -0400, grarpamp wrote:
On Fri, Sep 16, 2016 at 6:10 PM, Alex Elsayed eternaleye@gmail.com wrote:
(Yes, there is a typo in the last IPv6 address as well. https://trac.torproject.org/projects/tor/ticket/20153 )
Yes Tor is making some quite bad text representation issues so I added summary of them to this ticket.
- [FC00]/8 is _reserved by the IANA_, and beyond that, CJDNS is already
squatting on it. :/
As all their independant users are not really one 'AS number' like entity where the concept of 'local' policy would then apply to all, CJDNS does present some problems in this area. Possibly with interoperating with other IPv6 based overlay networks and adapters / tunnels. I hope they're aware of them. Unfortunately to fix I think they'd have to rearchitect, or at least renumber to squat elsewhere... both being rather unpalatable from their point of view. Specifically, if I recall, they're abusing the 'L' bit in the RFC, squatting the undefined 0. I don't think so but would have to double check if they're also stomping the 1. Obviously generating into a proper L=1 /48 is not practical. As with the .onion and .i2p DNS reservations, I'd highly suggest CJDNS apply to IANA for a special /whatever they could then generate into.
Note that I used /8 rather than /7 when referring to CJDNS - that is, L=0 only, and not L=1.
Also such a "special /whatever" already exists, in the form of ORCHIDv2 (RFC 7343) - it was created for HIPv2, but _intentionally_ left open encoding room for other systems. They'd just need to ask the IANA to allocate them am OGA ID (Orchid Generation Algorithm).
(ORCHID: Overlay Routable Cryptographic Hash ID)
Also, .onion and .i2p are at the DNS level, not the IP level - part of the point of CJDNS is that the addresses are directly routable.
Of course, my opinion is that CJDNS does nothing that is not also done, and better, by HIPv2, which also uses direct-routable addresses.
Yes in general networks shouldn't ride on top of space others are legitimately using per RFC, such as the ULA space. Even riding on some unallocated unicast space outside 2000::/3 that IANA is unlikely to ever allocate to the global IPv6 routing table of host networks would be preferred over that. That is, if you don't apply for a special purpose allocation.
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-
space.xhtml
http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-
special-registry.xhtml
https://tools.ietf.org/html/rfc4193 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Alex Elsayed -
grarpamp -
teor