Yggdrasil

Carding 4 Carders

Professional
Messages
2,731
Reputation
13
Reaction score
1,367
Points
113
The release of the reference implementation of the Yggdrasil 0.4 protocol has been published, which allows you to deploy a separate decentralized private IPv6 network on top of a regular global network, which uses end-to-end encryption to protect your privacy. You can use any existing IPv6-enabled applications to work over the Yggdrasil network. The implementation is written in Go and distributed under the LGPLv3 license. Linux, Windows, macOS, FreeBSD, OpenBSD, and Ubiquiti EdgeRouter platforms are supported.

Yggdrasil develops a new routing concept for creating a global decentralized network, where nodes can connect directly to each other in a 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 self-organization of work, without the need for explicit routing settings . Information about routes is calculated based on the location of a node in the network relative to other nodes. Devices are addressed using a regular IPv6 address, which does not change when a node is moved (Yggdrasil uses the unused address range 0200:: / 7).

The entire Yggdrasil network is considered not as a union of disparate subnets, but as a single structured spanning tree, which has one "root", and each node has one parent, as well as one or more descendants. 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.

Information about the tree is distributed among nodes and is not stored centrally. To exchange routing data, a distributed hash table (DHT) is used, with which a node can extract all information about the route to another node. By itself, the network provides only end-to-end encryption (transit nodes cannot determine the content), but not anonymity (when connecting via the Internet, peers with direct interaction can determine the real IP address, so for anonymity, it is suggested to connect nodes via Tor or I2P).

It is noted that despite the project being at the alpha development stage, it is already stable enough for daily use, but it does not guarantee backward compatibility between releases. For Yggdrasil 0.4, the community supports a set of services, including a platform for hosting Linux containers for hosting their sites, the YaCy search engine, the Matrix communication server, an IRC server, DNS, a VoIP system, a BitTorrent tracker, a map of connection points, an IPFS gateway, and a proxy for accessing Tor, I2P, and clearnet networks.

In the new version:

* Implemented a new routing scheme that is not compatible with previous Yggdrasil releases.

• When establishing TLS connections to nodes, public key pinning is used. If there was no binding during the connection, the received key will be assigned to the connection. If the binding was set but the key does not match it, the connection will be rejected. TLS with key binding is defined as the recommended method for connecting to peers.

* Completely redesigned and rewritten the routing and session management code to increase throughput and reliability, especially for nodes that frequently change peers. In cryptographic sessions, periodic key rotation is implemented. Added support for Source routing, which can be used to redirect user IPv6 traffic. Redesigned the Distributed hash Table (DHT) architecture and added support for DHT-based routing. The implementation of routing algorithms is placed in a separate library.

• IPv6 IP addresses are now generated from ed25519 public keys, rather than their X25519 hash, which will cause all internal IP addresses to change after switching to the Yggdrasil 0.4 release.

* Additional settings are provided for searching for Multicast peers.

+++

After more than two years of development, the release of the reference implementation of the Yggdrasil 0.5 protocol has been published, which allows you to deploy a separate decentralized private IPv6 network on top of a regular global network, which uses end-to-end encryption to protect your privacy. The Yggdrasil network can use any existing IPv6-enabled applications. The implementation is written in Go and distributed under the LGPLv3 license. Linux, OpenWRT, Windows, macOS, FreeBSD, OpenBSD, VyOS, and Ubiquiti EdgeRouter platforms are supported.

Yggdrasil develops a new routing concept for creating a global decentralized network, where nodes can connect directly to each other in a 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 the self-organization of work, which does not require explicit configuration of routing - information about routes is calculated based on the location of a node in the network relative to other nodes. Devices are addressed using a regular IPv6 address, which does not change when a node is moved (Yggdrasil uses the unused address range 0200:: / 7).

The entire Yggdrasil network is considered not as a union of disparate subnets, but as a single structured spanning tree, which has one "root", and each node has one parent and one or more descendants. 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. Information about the tree is distributed among nodes and is not stored centrally.

To protect against traffic analysis, the network uses end - to-end encryption (transit nodes cannot determine the content), but anonymity is not guaranteed.When connecting via the Internet, peers with direct interaction can determine the real IP address, so for anonymity, it is suggested to connect nodes via Tor or I2P.

Although the project is in alpha development, it is already stable enough for daily use, but it does not guarantee backward compatibility between releases. For Yggdrasil, the community supports a set of services, including a platform for hosting Linux containers for hosting their sites, the YaCy search engine, the Matrix communication server, an IRC server, DNS, a VoIP system, a BitTorrent tracker, a map of connection points, an IPFS gateway, and a proxy for accessing Tor, I2P, and clearnet networks.

In the new version:

* Added the ability to authenticate the connection to peers using a password. The password is set using the "password=" parameter, for example, "tls://a.b.c.d:12345?password=123456abcdef".

* Added the ability to use the QUIC protocol based on UDP to interact with peers. To use QUIC, 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 to store the private key in PEM format, separate from the main configuration file. To export the key to a separate file, you can use the "-exportkey " option.

* Implemented a new routing scheme that is not backward compatible with previous versions (nodes with Yggdrasil 0.5 cannot interact with hosts based on Yggdrasil 0.4), but solves most of the stability and scalability problems that were present in the 0.4 branch, as well as significantly reducing memory consumption and traffic in the absence of network activity.

The new implementation uses the Bloom Filter probabilistic structure to track links and nodes. The Distributed Hash Table (DHT) is no longer used for exchanging routing data and binding public keys in a tree network.

To maintain local consistency and reduce dependency on routes to root nodes, nodes now transmit information about each link separately, which is tracked in CRDT structures. Instead of routing from the source, greedy routing is used (requests are routed to the nearest neighboring node).

The formats used in connection negotiation and multicast have been redesigned for better extensibility. The link processing code has been redesigned to better track the state of peers. Separate tracking of the intervals between repeated connections for each configured peer is provided.

To detect failures, instead of periodically sending separate keepalive requests, traffic confirmation messages are used, which allow you to get rid of traffic when the network is inactive (which, for example, reduces power consumption on mobile devices due to the exclusion of traffic in idle mode).
 
Top