On 8/28/16, Mirimir <[email protected]> wrote: > On 08/28/2016 02:00 AM, grarpamp wrote:
> OK. As I understand it, all that matters is using a /48 that won't be > provisioned by ISPs. In case it hits the public Internet. Right? If your users are the masses, yes. In a private install / userbase you could pick anything that doesn't collide in your stacks, and then anything that hasn't been allocated via rfc / registry, which is almost the entire /128. Use filters, not rely whatever isp do or iana docs say. > And I could configure onion services to route among multiple /48 > networks, yes? Well you would bind apps to the ipv6/128 on the tun interface, onioncat takes care of routing that /48 among tor's onions after the hosts routing table sends its packets to the tun. Basically yes. Then there's the sick stuff you could do with https://en.wikipedia.org/wiki/List_of_open-source_routing_platforms > What do you mean by "unreproducible"? Try verifying glob_id.txt. > Yes, I've discovered the importance of -U :) I restrict traffic by local > and remote OnionCat IPv6 addresses, both in ip6tables and for ip4ip6 > tunnels. But honestly, it hadn't occurred to me to use the > HiddenServiceAuthorizeClient option. Thanks :) There's that, but there's also potential of making onioncat daemons keying together so people can key at whatever layer works for them. ie: clearnet - ipsec, vpn tor / i2p - network instances ie: dirauths, bitcoin genesis onion / eep - hsauthcli / ? onioncat / garlicat - tbd ipv6 - ipsec, vpn application - x509 cert pinning > OK, so I get that -t is the SocksPort used for outbound connections. And > for inbound connections, I get that -l is the listening address and > port, and that -s is the virtual hidden service port. > > So for now, each instance would have its own pair of -t and -l/-s. But > I'm having a hard time imagining what multiplexing would look like. And > anyway, isn't it better to split stuff across multiple SocksPorts? Socks5 port is a bit different from onion p2p. I meant having single onioncat handling multiple /48's would give another abstract management option, in addition today multiple onioncats with one /48 each. >> https://lists.torproject.org/pipermail/tor-dev/2016-April/010847.html > > Yes :) > >> Do wish the mailing list and all its archives would come back. > > Me too. > > I've very intrigued by overlay networks. And I'm impressed with > OnionCat. It's simple, it's fast, and it's reliable. I've even managed a > LizardFS cluster on many VPS linked via OnionCat. All it took was > increasing timeouts 10x to accept 2000 ms rtt. -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
