- Yggdrasil est un réseau qui expérimente une alternative décentralisée aux protocoles de routage structurés, en utilisant une méthode de routage compact pensée pour les réseaux maillés à grande échelle
- L’implémentation actuelle est un routeur logiciel en espace utilisateur léger et facile à configurer, qui relie un routage IPv6 chiffré de bout en bout entre les participants
- L’appairage des nœuds peut être constitué de connexions TCP/TLS sur un LAN, des liaisons point à point ou sur Internet, et le peering lui-même peut fonctionner sur IPv4 ou IPv6
- Il se caractérise par la prise en charge de topologies à grande échelle, la reprise après pannes et événements de mobilité, un chiffrement de bout en bout toujours actif, un fonctionnement P2P sans point central et la prise en charge de plusieurs systèmes d’exploitation
- Le projet est encore au stade alpha, donc des ruptures de compatibilité restent possibles, mais il est globalement stable pour un usage quotidien et certains utilisateurs le soumettent déjà à des tests intensifs
Le problème réseau que Yggdrasil cherche à résoudre
- Yggdrasil est une nouvelle approche expérimentale de routage compact
- Il vise à devenir une alternative décentralisée et tournée vers l’avenir aux protocoles de routage structurés couramment utilisés sur Internet
- Il est conçu comme une technologie capable de rendre possibles à l’avenir des réseaux maillés de grande taille
-
Caractéristiques de conception du réseau
- Scalabilité : prise en charge de topologies vastes et complexes, y compris à l’échelle d’Internet
- Auto-réparation : réaction rapide aux pannes de connexion et aux événements de mobilité
- Chiffrement : le trafic qui traverse le réseau utilise toujours un chiffrement complet de bout en bout
- P2P : fonctionnement ad hoc sans point central intégré
- Multiplateforme : prise en charge de Linux, macOS, Windows, iOS, Android, etc.
Méthode d’implémentation et participation au réseau
- L’implémentation actuelle est un routeur logiciel en espace utilisateur léger
- Elle est facile à configurer et prend en charge diverses plateformes
- Elle relie un routage IPv6 chiffré de bout en bout entre tous les participants du réseau
- Le peering entre nœuds peut être configuré via des connexions TCP/TLS
- Il peut être utilisé sur un réseau local, des liaisons point à point ou sur Internet
- Yggdrasil Network fournit un routage IPv6 entre les nœuds, mais les connexions de peering elles-mêmes peuvent être établies sur des réseaux IPv4 ou IPv6
- Le projet est encore au stade alpha
- Des ruptures de compatibilité peuvent donc survenir à l’avenir
- Malgré cela, il est globalement stable pour un usage quotidien
- Certains utilisateurs le poussent déjà fortement dans divers usages afin de le tester sous contrainte
-
Démarrer et contribuer
- Vous pouvez rejoindre le réseau depuis votre ordinateur personnel ou votre routeur grâce à l’installation et à la configuration
- Vous pouvez explorer les services internes du réseau exploité par les utilisateurs
- Vous pouvez participer au projet via la page développeurs et GitHub
- Les bugs et problèmes peuvent être signalés dans les GitHub Issues
1 commentaires
Avis sur Hacker News
La première chose que j’ai cherchée sur le site web et sur GitHub, c’était une spécification de protocole permettant de l’implémenter indépendamment de l’implémentation de référence ; or, pour quelque chose présenté comme un schéma/protocole, aucune spécification n’était liée nulle part.
En fouillant moi-même, j’ai trouvé [1] dans une branche annexe d’un autre projet GitHub, et je tire mon chapeau à son auteur. On y trouve assez bien tout le nécessaire : identité cryptographique, formats de messages, protocole de transport, sémantique du peering et des streams, mise à jour de l’arbre couvrant et choix de la racine, DHT, logique de transfert, sessions, etc.
Cela dit, il reste des TODO, par exemple sur la validation/signature des mises à jour de racine, et l’algorithme de résolution des égalités dans le choix du prochain saut est ambigu. De plus, tous les paquets doivent être livrés de manière fiable et dans l’ordre, et il faut pouvoir les fragmenter en paquets plus petits pour respecter la MTU ; la couche de transport semble donc fortement couplée à TCP.
[1] https://github.com/yggdrasil-network/yggdrasil-specs/blob/ys...
En v0.4, la DHT a pas mal changé, et en v0.5 nous l’avons complètement supprimée. Comme c’est un projet de recherche, il y a de fortes chances que ça continue d’évoluer jusqu’à ce que nous arrivions à une conception plus satisfaisante ; à ce moment-là, je consacrerai clairement plus de temps à la documentation.
Le besoin de liens ordonnés et fiables tient surtout, à ce stade, à la facilité de développement, mais c’est clairement quelque chose qui peut être corrigé.
Si je comprends bien, yggdrasil et cjdns sont des réseaux P2P virtuels construits par-dessus l’Internet existant, et fournissent un service de routage classique de couche 3.
Il faut donc toujours des FAI, le backbone Internet, etc. Existe-t-il des projets visant à créer un réseau P2P mondial remplaçant la couche IP, capable de fonctionner sans routeurs Verizon ou Cisco ?
Je connais quelques technologies de réseau maillé pour de petits réseaux isolés, mais je ne vois pas vraiment de solution grand public capable de prendre en charge des milliers de nœuds ou plus.
Voir le premier paragraphe de https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepape.... Malheureusement, cette approche de routage s’est révélée peu scalable en pratique. Yggdrasil utilise un autre algorithme de routage, donc il y a peut-être une possibilité.
Cette approche a beaucoup d’avantages, notamment le fait de faciliter l’adoption. Aujourd’hui, pour les applications legacy, on fait tourner le réseau téléphonique au-dessus d’IP. Si Yggdrasil réussit, je pense qu’on finira par faire tourner IP au-dessus de lui pour les systèmes legacy.
Ce n’est pas juste un problème parmi d’autres, mais une limite fondamentale de conception. Internet (ARPAnet) a lui aussi commencé comme un réseau maillé, et les notions de trunks, de backbone et de routage sont apparues pour résoudre ces problèmes de passage à l’échelle.
Ou bien parles-tu d’une couche IP au-dessus d’un réseau distinct, et non au-dessus d’« Internet » ? Dans ce cas, je serais curieux de savoir comment tu comptes relier les gens entre eux. À mesure que l’échelle augmente, le routage maillé rend le mesh inefficace, et on finit tôt ou tard par réinventer son « propre Internet ». Sauf qu’on n’a pas les ressources pour connecter réellement le monde entier, donc ce ne sera pas mondial.
À l’époque, c’était surtout une réponse idéaliste/anarchiste au jugement contre Pirate Bay en 2009-2010. Si je me souviens bien, cjdns est arrivé peu après et a absorbé la majeure partie du groupe.
Qui aurait pu deviner qu’une bande de hackers mécontents et de pirates de logiciels ne tiendrait pas longtemps en construisant un Internet encore plus bancal ?
[0] https://en.m.wikipedia.org/wiki/Athens_Wireless_Metropolitan...
Liens associés :
Yggdrasil Network - https://news.ycombinator.com/item?id=41669625 - septembre 2024, 3 commentaires
Yggdrasil P2P mesh E2EE IPv6 network - https://news.ycombinator.com/item?id=30156551 - janvier 2022, 77 commentaires
Yggdrasil – Early-stage implementation of an end-to-end encrypted IPv6 network - https://news.ycombinator.com/item?id=27577201 - juin 2021, 102 commentaires
Show HN: Yggdrasil Network – compact mesh routing experiment for mesh networks - https://news.ycombinator.com/item?id=18863554 - janvier 2019, 15 commentaires
Announcing Yggdrasil Network v0.3 - https://news.ycombinator.com/item?id=18751991 - décembre 2018, 3 commentaires
Yggdrasil: End-To-end Encrypted IPv6 Networking - https://news.ycombinator.com/item?id=18666245 - décembre 2018, 1 commentaire
Si vous avez besoin d’un vrai réseau IP P2P maillé capable de traverser les pare-feu/NAT, utilisez Tailscale/Headscale.
Si vous voulez un réseau de connexions P2P où les adresses sont définies par des clés de chiffrement, il existe un projet assez récent qui fait ça plutôt bien : https://www.iroh.computer
Il traverse les pare-feu/NAT et établit des connexions QUIC. Il existe déjà deux preuves de concept utilisables :
https://github.com/n0-computer/sendme
https://github.com/n0-computer/dumbpipe
Y a-t-il des avantages ? Si l’objectif est simplement de faire tourner un VPN privé léger pour un usage personnel, Tailscale est excellent ; et si l’on veut héberger soi-même le réseau, Headscale existe aussi et présente beaucoup d’avantages.
Il y a 3 ou 4 ans, j’y croyais pas mal, mais aujourd’hui cela ressemble un peu à un projet laissé à l’abandon. Je me demande s’il y a des gens qui l’utilisent vraiment et quelles sont leurs impressions.
Fin de l’année dernière, nous avons publié la version 0.5 avec une nouvelle conception du protocole, et il y a environ un mois nous avons publié la 0.5.9, qui a nettement amélioré la latence du réseau grâce à une modification du coût des liens.
Je l’utilise comme un VPN pour relier mon téléphone et mon réseau domestique, tous deux peering en privé avec un VPS.
C’est un peu plus complexe qu’une connexion directe à la maison, mais la configuration a été plus simple que de gérer une IP dynamique, du port forwarding et l’échange de clés WireGuard.
Le peering multicast fonctionne correctement, donc quand je suis chez moi je peux aussi accéder directement à mon serveur domestique avec la même IP Ygg. Le problème, c’est qu’il faut utiliser l’IP. L’application iOS ne permet pas de configurer un serveur DNS personnalisé pour la connexion VPN Ygg.
Pour cet usage, Headscale est en fait une meilleure solution, mais le fait qu’il suffise d’ajouter un seul peering pour obtenir un Internet alternatif est assez amusant.
J’utilise maintenant yggdrasil sur tous mes appareils, ce qui me permet de me connecter entre eux en ssh même lorsqu’ils sont derrière un NAT.
Sur Android, avec termux et l’application Android yggdrasil, je peux accéder en déplacement à des fichiers sur mon ordinateur à la maison sans avoir à les stocker quelque part dans le cloud.
Le développement est assez actif, et dans la dernière version l’algorithme de routage a été amélioré pour privilégier les sauts ayant la latence la plus faible, ce qui s’est ressenti à l’usage.
Si vous vous attendez à de gros hubs communautaires dans le réseau, vous risquez d’être déçu, mais vous pouvez aussi en créer un vous-même. Beaucoup de gens l’utilisent selon leurs propres besoins, et le projet est loin d’être abandonné.
Je pensais que c’était une distribution Linux.
https://en.m.wikipedia.org/wiki/Yggdrasil_Linux/GNU/X
Dans ce domaine, il y a aussi le Reticulum Network Stack : https://reticulum.network/
La FAQ dit : « Yggdrasil est-il anonyme ? Non, l’objectif du projet Yggdrasil n’est pas de fournir l’anonymat. »
Je comprends que le problème soit difficile, et qu’il y ait des enjeux à résoudre au-delà d’une simple question technique, mais honnêtement, pour moi, c’est éliminatoire dès le départ. Si l’on parle d’une véritable évolution d’Internet, elle devrait selon moi inclure un anonymat effectif.
Sans cela, je ne vois pas vraiment quel problème de l’Internet actuel, encore non résolu avec la configuration existante, cela règle concrètement.
Les réseaux anonymes ont généralement un coût et un overhead très élevés, parce qu’ils créent délibérément des chemins longs et indirects pour dissimuler les échanges. Quand on voit les performances et la fiabilité globalement faibles des circuits Tor, on comprend pourquoi on ne voudrait pas que tout Internet fonctionne de cette façon.
Rien n’empêche de faire tourner le réseau Yggdrasil puis d’exploiter un réseau I2P à l’intérieur. Ainsi, les communications qui n’ont pas besoin d’anonymat subissent moins de pertes de performance, et l’on peut créer des pairs anonymes sans passer par le clearnet.
L’idée de dériver l’adresse de la clé publique est vraiment bonne, mais cette approche pose problème. Comme Yggdrasil utilise actuellement des adresses IPv6, leur longueur est très limitée et il est possible de trouver des collisions.
Il existe bien une solution de contournement consistant à chercher par force brute une clé avec davantage de bits initiaux. D’après ce que j’ai compris, le plan à long terme est d’ajouter un protocole personnalisé sans limite de longueur d’adresse.
En revanche, provoquer une collision avec un ensemble d’adresses déjà utilisées paraît toujours irréaliste. Dans le contexte de Yggdrasil, dans quelle mesure le premier cas serait-il vraiment un problème ?
Cela dit, pour l’instant, cela signifie que presque toutes les applications existantes compatibles IPv6 fonctionnent sur Yggdrasil sans modification, ce qui est une bonne propriété pour un testnet.
Il est écrit : « Yggdrasil is a new experimental compact routing scheme », mais ce n’est plus si nouveau maintenant, non ? Cela fait au moins 6 ans.