After more than two years of development, the Yggdrasil 0.5 reference implementation has been released. It enables the deployment of a separate, decentralized, private IPv6 network on top of the regular global network, using end-to-end encryption to protect privacy. Any existing IPv6-enabled applications can run on the Yggdrasil network. The implementation is written in Go and licensed under the LGPLv3 license. Supported platforms Linux, OpenWRT, Windows, macOS, FreeBSD, OpenBSD, VyOS and Ubiquiti EdgeRouter.
Yggdrasil is developing a new routing concept to create a global decentralized network, nodes in which can connect directly to each other in mesh network mode (for example, via Wi-Fi or Bluetooth), or interact over existing IPv6 or IPv4 networks (network on top of network) . A distinctive feature of Yggdrasil is its self-organization of work, which does not require explicit routing configuration - information about routes is calculated based on the location of a node in the network relative to other nodes. Devices are addressed via a regular IPv6 address, which does not change if a node moves (Yggdrasil uses the unused address range 0200::/7).
The entire Yggdrasil network is not viewed as a collection of disparate subnetworks, but as a single structured spanning tree with one “root” and each node having one parent and one or more children. Such a tree structure allows you to build a route to the destination node, relative to the source node, using the “locator” mechanism, which determines the optimal path to the node from the root. Tree information is distributed among nodes and is not stored centrally.
To protect against traffic analysis on the network, end-to-end encryption is used (transit nodes cannot determine the content), but anonymity is not guaranteed - when connecting via the Internet, peers with whom direct interaction is carried out can determine the real IP address, so for anonymity it is recommended to connect nodes via Tor or I2P.
Although the project is still in alpha development, it is already stable enough for daily use, but does not guarantee backward compatibility between releases. The community maintains a set of services for Yggdrasil, including a hosting platform. Linux-containers for hosting their websites, the YaCy search engine, the Matrix communications server, an IRC server, DNS, a VoIP system, a BitTorrent tracker, a map of connection points, an IPFS gateway, and proxies for accessing the Tor, I2P, and clearnet networks.
In the new version:
- Added the ability to authenticate connections to peers using a password. The password is specified via the “password=” parameter, for example, “tls://abcd:12345?password=123456abcdef”.
- Added the ability to use the UDP-based QUIC protocol to interact with peers. To use QUIC, you must specify the quic:// URI scheme in the Listen and Peers directives, but QUIC support is not yet as well tested as TCP and TLS.
- Added the PrivateKeyPath option, which allows you to store the private key in PEM format, separately from the main configuration file. To export the key to a separate file, you can use the “-exportkey” option.
- A new routing scheme has been implemented, which is not backward compatible with previous versions (nodes with Yggdrasil 0.5 cannot communicate with hosts based on Yggdrasil 0.4), but solves most of the problems with stability and scalability that were present in the 0.4 branch, and also significantly reduces memory consumption and reduces traffic in the absence of network activity.
The new implementation uses a probabilistic Bloom Filter structure to track links and nodes. The distributed hash table (DHT) is no longer used to exchange routing information and bind public keys in a tree network.
To maintain local consistency and reduce dependency on routes to root nodes, nodes now separately communicate information about each link, which is tracked in CRDT structures. Instead of source routing, greedy routing is used (requests are sent to the nearest neighbor).
The formats used for connection negotiation and multicast have been redesigned for better extensibility. The connection processing code has been reworked to more reliably track the status of peers. Provides separate tracking of intervals between reconnections for each configured peer.
To detect failures, instead of periodically sending separate keepalive requests, messages confirming the receipt of traffic are used, which allow you to get rid of traffic during network inactivity (which, for example, reduces power consumption on mobile devices due to the exclusion of traffic in idle mode).
Source: opennet.ru
