[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tor-talk] IPv6 /48 for OnionCat

On 8/28/16, Mirimir <mirimir@riseup.net> 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

> 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 - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to