[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tor-talk] IPv6 /48 for OnionCat
On 8/28/16, Mirimir <email@example.com> 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.
Then there's the sick stuff you could do with
> 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.
> 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 - firstname.lastname@example.org
To unsubscribe or change other settings go to