On 2022-06-15, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> My gut reaction is that this is creating what I presume to be
> point-to-point tunnels and using source & destination IP addresses
> therein. Maybe it's lightweight tunnels that don't have dedicated
> interfaces and choose encryption based on source & destination IP addresses.

So there is only one Yggdrasil network interface on a computer: tun0 or ygg0 or
whatever you want to call it.

https://yggdrasil-network.github.io/about.html discusses this a bit.

Each Yggdrasil node has "peers" with which it has established direct
connectivity. This activity can be established opportunistically (as with
broadcasts over a LAN) or with defined peers (as with using it as an overlay
over the Internet). You can optionally exert control over who can peer with you
based on the peer's public key.

So once you have some route to the global Yggdrasil network, the Yggdrasil
daemon knows how to reach any of the thousands of addresses on it. This is
where the magic happens, but it's all within the daemon; to the kernel, it just
sends packets down tun0 and that's it.

Other than cjdns, which was sort of a predecessor technology, the closest
similar program I am aware of is tinc https://tinc-vpn.org/ . But there, you
have to explicitly set up each node to know about the others.

John

On 2022-06-15, John Goerzen <jgoerzen@complete.org> wrote:
> As an aside, I love it for laptops. Yggdrasil+mosh is the perfect remote
> terminal; close the laptop at home, open it up at a coffee shop or whatever, and
> the laptop still has the same Yggdrasil IP, has discovered that it needs to
> relay via the Internet instead of the LAN to its mosh/ssh destination at my home
> network, and the session just keeps going; all that's different is higher ping
> times. Go back home and it goes, "oh hey, now I can talk to you directly again,
> let's do that" and ping times go back down.

I actually use ZeroTier myself for that right now. Only trouble I've
had with ZeroTier is behind really restrictive firewalls (only
happened in a historic hotel I stayed in, but I had more going on
around me at that point than would encourage me to get onto the
computer much 😄 .) In these cases you could probably have your Ygg
node listen on 443 which should break through even most restrictive
firewalls, which I don't think ZT can do. ZT assigns private IPs on a
private network, both v4 and v6, and these IPs stay stable per
instance of the daemon running. So ZT on a home server has a stable ZT
IP for that network and unless you are on the network, you cannot
connect to that IP.

Ygg gives you the global network which is certainy more fun than just
a private network, but I've started using ZT for NNCP and even for
streaming security cameras using RDP. I also run a ZT network for my
family in their houses so I can remote troubleshoot things on their
networks without having to go over. I can also run ZT on my Android
phone and I know it has iOS support though I don't have any iOS
devices myself.

If anyone is looking for a private network solution I do recommend
ZeroTier. Sorry for a bit of a non-sequitur.

On 6/15/22 11:08 AM, Grant Taylor wrote:
> I have a lot of questions, many of which I suspect will be answered when
> i read about Yggdrasil Network at the link you provided.

Sadly, none of my technical questions were answered by reading pages on
the Yggdrasil Network website [1].

I never did find what I would consider to be a description of how things
work from a networking / application point of view. I was also very
surprised to not find any documentation on what settings to put into the
configuration file.

I actually got better technical information in this thread than I did
from the Yggdrasil Network website.

[1] https://yggdrasil-network.github.io/

--
Grant. . . .
unix || die

On 6/15/22 3:14 PM, John Goerzen wrote:
> Feel free to ask me also, by email or whatever newsgroup would be
> appropriate

What addresses does Yggdrasil Network use? It looked to me like they
were using IPv6 addresses that aren't currently routed globally. I
think I saw a few different /16 xx:xx::/xx networks listed in
documentation. But I didn't see anything that actually clearly sated
what Yggdrasil Network uses.

Nor did I find anything that actually talked about how the addresses are
used.

I naively assume that standard destination based routing is used such
that the kernel sends traffic for various destinations into the tun0 /
ygg0 / etc. network interface and the Yggdrasil Network daemon handles
the rest.

But I didn't find anything to support this assumption, much less any
description of how such would be done.

I'm used to things like Tor that state -- effectively -- use a SOCKS
server at $CONFIGURED_ADDRESS on $CONFIGURED_PORT -- with more details
about how to do said configuration.

I wonder about the ability to have standard DNS names resolve to
Yggdrasil Network addresses. But, I didn't find enough information to
either confirm nor refute this.

My opinion is that the Yggdrasil Network's website is lacking a
significant amount of technical documentation.

--
Grant. . . .
unix || die

Den 2022-05-21 skrev Retro Guy <retro.guy@rocksolidbbs.com>:
> Grant Taylor wrote:
>
>> On 5/20/22 9:50 PM, Retro Guy wrote:
>>> Yes, that's true. I2P makes it much easier.
>
>> Would you please elaborate on what I2P does that's different?
>
> There are two features in I2P that help with this. One is that you
> can tie a client key (generated by the client) to a server tunnel.
> You can whitelist key(s) for this tunnel, and only allow specific
> clients to connect.
>

Sorry for coming in so late, but I want to point out that Tor does
support client keys with for onions. You can generate keys and
configure Tor to only allow connections from clients with specific
keys.

It is a useful feature that can definitely increase security should
your onion address leak for some reason so I thought it worth
mentioning.

There are instruction available from the Tor project at
https://community.torproject.org/onion-services/advanced/client-auth/.

Best regards,
Andreas Kempe

Andreas Kempe wrote:

> Den 2022-05-21 skrev Retro Guy <retro.guy@rocksolidbbs.com>:
>> Grant Taylor wrote:
>>
>>> On 5/20/22 9:50 PM, Retro Guy wrote:
>>>> Yes, that's true. I2P makes it much easier.
>>
>>> Would you please elaborate on what I2P does that's different?
>>
>> There are two features in I2P that help with this. One is that you
>> can tie a client key (generated by the client) to a server tunnel.
>> You can whitelist key(s) for this tunnel, and only allow specific
>> clients to connect.
>>

> Sorry for coming in so late, but I want to point out that Tor does
> support client keys with for onions. You can generate keys and
> configure Tor to only allow connections from clients with specific
> keys.

> It is a useful feature that can definitely increase security should
> your onion address leak for some reason so I thought it worth
> mentioning.

> There are instruction available from the Tor project at
> https://community.torproject.org/onion-services/advanced/client-auth/.

Thank you for this info and link. I was not aware this is possible with tor.

--
Retro Guy

Grant Taylor wrote:

> What addresses does Yggdrasil Network use? It looked to me like they
> were using IPv6 addresses that aren't currently routed globally. I
> think I saw a few different /16 xx:xx::/xx networks listed in
> documentation. But I didn't see anything that actually clearly sated
> what Yggdrasil Network uses.

| Will Yggdrasil conflict with my network routing?
|
| Yggdrasil uses the 0200::/7 range, which is a range deprecated by the
| IETF. It has been deprecated since 2004, pending changes to an RFC which
| simply never materialised all these years later. It was decided to use
| this range instead of fc00::/7 (which is more typically allocated to
| private networks) in order to prevent conflicts with existing ULA ranges.
<https://yggdrasil-network.github.io/faq.html>

> I naively assume that standard destination based routing is used such
> that the kernel sends traffic for various destinations into the tun0 /
> ygg0 / etc. network interface and the Yggdrasil Network daemon handles
> the rest.

Looks like that.

> My opinion is that the Yggdrasil Network's website is lacking a
> significant amount of technical documentation.

Most probably that's "in the code", currently, and nobody wrote it down
yet. :)

-thh