Skip to content

Conversation

@nagy
Copy link

@nagy nagy commented Jan 3, 2025

This address family is used in communication between virtual machines and their hosts. Advantages include that no virtual ethernet adapter and their respective address configuration and routing need to be setup. Rather, with this new link type, only a single yggdrasil interface can exist inside of the virtual machine.

It can also be used inside of containers. There, the advantage over existing link types like unix sockets include, that no mount point need to be shared with the host and container. This provides more isolation.

More information:

https://man7.org/linux/man-pages/man7/vsock.7.html

https://gist.github.com/nrdmn/7971be650919b112343b1cb2757a3fe6

This address family is used in communication between virtual machines
and their hosts. Advantages include that no virtual ethernet adapter
and their respective address configuration and routing need to be
setup. Rather, with this new link type, only a single yggdrasil
interface can exist inside of the virtual machine.

It can also be used inside of containers. There, the advantage over
existing link types like unix sockets include, that no mount point
need to be shared with the host and container. This provides more
isolation.

More information:

https://man7.org/linux/man-pages/man7/vsock.7.html

https://gist.github.com/nrdmn/7971be650919b112343b1cb2757a3fe6
@neilalexander
Copy link
Member

neilalexander commented Oct 6, 2025

At the moment I am reluctant to add more link types, as I'd actually rather remove quite a few of the link types in v0.6. I'm not really convinced that QUIC, WebSockets or SOCKS have overwhelmingly good reasons to stay either, given they mostly just encourage people to do silly things topology-wise.

@nagy
Copy link
Author

nagy commented Oct 7, 2025

Would you be open to external link types for example via a plugin system? For example if you would have an executable program in /usr/bin/yggdrasil-transport-<name> or more likely somewhere in the PATH then the configuration URL like vsock://local:1234 would be passed to it as a first argument to the program yggdrasil-transport-vsock, if it exists. The actual communication happens via stdio. This way we would not need to maintain this dependency in the main repository. People could install new transports via packages via their package managers and we could experiment with new transports in other languages.

, given they mostly just encourage people to do silly things topology-wise.

Of course you would know more about these topology problems than I do, but I want to say that people sometimes rely on these exotic transports to bypass firewalls.

@peigongdsd
Copy link

At the moment I am reluctant to add more link types, as I'd actually rather remove quite a few of the link types in v0.6. I'm not really convinced that QUIC, WebSockets or SOCKS have overwhelmingly good reasons to stay either, given they mostly just encourage people to do silly things topology-wise.

Most people do not even know what yggdrasil is. They have never heard of something called a "flat routing scheme". It is quite fair for those who are not so familiar with the mechanism of yggdrasil to take stupid moves, but features are always useful to those who know it, and need it. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants