Cette page a été mise à jour en May 2016 et est valide pour la version de routeur 0.9.26.

Aperçu

I2P est livré avec une librairie générique de nommage et une mise en œuvre de base conçue pour marcher à partir d'un nom local vers la cartographie de destination, ainsi qu'avec une application add-on appelée le carnet d'adresses. I2P permet aussi les noms d'hôtes en Base32 de façon similaire aux adresses Tor .onion .

Le carnet d'adresses est conduit par web de confiance sécurisé, distribué, et système de nommage lisible par humain, sacrifiant seulement l'appel pour tous les noms lisibles par humain qu'il soient globalement uniques en mandatant seulement l'unicité locale. Tandis que tous les messages dans I2P sont cryptographiquement adressés par leur destination, des gens différents peuvent avoir des entrées de carnet d'adresse locales pour "Alice" qui réfère aux destinations différentes. Les gens peuvent toujours découvrir de nouveaux noms en important les carnets d'adresses publiés de pairs indiqués dans leur web de confiance, ceci en ajoutant les entrées fournies par personne interposée, ou (si quelques personnes organisent une série de carnets d'adresses publiés utilisant un système d'enregistrement de type premier arrivé premier servi) les gens peuvent vouloir traiter ces carnets d'adresses comme des serveurs de nom, émulant un DNS traditionnel.

NOTE : pour le raisonnement derrière le système de nommage d'I2P, des arguments courants contre cela et des alternatives possibles, voyez la page discussion de nommage.

Composants système de nommage

Il n'y a aucune autorité centrale de nommage dans I2P. Tous les noms d'hôtes sont locaux.

Le système de nommage est assez simple et la plupart de cela est mis en œuvre dans des applications externes au routeur, mais empaquetées avec la distribution I2P. Les composants sont :

  1. Le service de nommage local qui assure les consultations et aussi traite les noms d'hôtes Base32.
  2. Le proxy HTTP qui demande au routeur des consultations et dirige l'utilisateur vers les services de saut distant pour aider concernant les consultations échouées.
  3. formulaires HTTP basés-hôte qui permettent aux utilisateurs d'ajouter des hôtes à leur hosts.txt local
  4. services de saut HTTP qui fournissent leurs propres consultations et la redirection.
  5. Le carnet d'adresses l'application qui mêle des listes d'hôtes externes, recouvrées via HTTP, avec la liste locale.
  6. L'application SusiDNS qui est qui est un simple frontal Web simple pour la configuration du carnet d'adresses et le visionnage des listes locales d'hôtes.

Services de nommage

Toutes les destinations dans I2P sont des clés 516 octets (ou longues). (Pour être plus précis, c'est une clé publique de 256 octets plus 128 octets signant la clé plus un certificat null, dans lequel la représentation Base64 est 516 octets. Des certificats sont maintenant utilisés, S'ils le sont, les clés seront plus longues. Une utilisation possible des certificats est pour la preuve de fonctionnement.)

Si une application (i2ptunnel ou la le proxy HTTP) souhaite avoir accès à une destination par son nom, le routeur fait une très simple consultation locale afin de résoudre ce nom.

Service de nommage Hosts.txt

Le service de nommage hosts.txt fait une simple recherche linéaire à travers des fichiers texte. Ce service de nommage était celui par défaut jusqu'à la version 0.8.8, à partir de laquelle il a été remplacé par le Service de Nommage Blockfile. Le format de hosts.txt était devenu trop lent après que le fichier aie grossi à plusieurs milliers d'entrées.

Il fait une recherche linéaire à travers trois fichiers locaux, dans l'ordre, afin de chercher des noms d'hôte et les convertir en des clés de destination 516-octets. Chaque fichier est un simple format de fichier de configuration, avec hostname=base64, un par ligne. Les fichiers sont :

  1. privatehosts.txt
  2. userhosts.txt
  3. hosts.txt

Service de nommage Blockfile

The service de nommage Blockfile stocke de multiples "carnets d'adresses" en un simple fichier base de données, nommé hostsdb.blockfile. Ce service de nommage est celui qui est pré-configuré depuis la release 0.8.8.

Un blockfile est simplement un stockage sur disque de multiples cartes-triées (multiple sorted maps) (paires de valeurs de clés), implémentées en tant que "skiplists". Le format de fichier blockfile est spécifié sur la page Blockfile. Il fournit la rapide consultation d'une Destination dans un format compact. Tandis que l'overhead du blockfile est substantielle, les destinations sont stockées en binaire plutôt qu'en Base 64 comme elles le sont dans le format de hosts.txt. De plus, le blockfile apporte la capacité de stockage de métadonnées arbitraires (telles que date ajoutée, source, et commentaires) pour chaque entrée afin d'implémenter des fonctionnalités avancées de carnet d'adresses. L'exigence de stockage de ce blockfile est une modeste augmentation en comparaison du format hosts.txt, et le blockfile fournit approximativement une réduction de 10x en temps de consultation.

Lors de la création, le service de nommage importe des entrées des trois fichiers utilisés par le service de nommage hosts.txt. Le blockfile imite la mise en œuvre précédente en maintenant trois cartes qui sont fouillées dans l'ordre, nommées privatehosts.txt, userhosts.txt et hosts.txt. Il entretient aussi une carte de consultation inverse afin de pouvoir mettre en œuvre rapidement des consultations inverses.

D'autres facilités de service de nommage

La consultation est insensible à la casse. La premier correspondance est utilisée, et les conflits ne sont pas détectés. Il n'y a aucune exécution de règles de nommage dans les consultations. Les consultations sont cachées durant quelques minutes. La résolution des Base 32 est décrite ici. Pour lire une description complète de l'API service de nommage voyez la Naming Service Javadocs. Cette API a été significativement étendue à partir de la release 0.8.7 afin de fournir ajouts et retraits, stockage de propriétés arbitraires avec le hostname, et d'autres fonctions.

Services de nommage alternatifs et expérimentaux

Le service de nommage est spécifié avec la propriété de configuration i2p.naming.impl=class. D'autres implémentations sont possibles. Par example, il y a une facilité expérimentale pour les "real-time lookups" (à la DNS) par dessus le réseau dans le routeur. Pour davantage d'information voyez les alternatives sur la page de discussion.

Le proxy HTTP fait une consultation via le routeur pour tous les noms d'hôtes se finissant par '.i2p '. Autrement, il fait suivre la requête vers un outproxy HTTP configuré. Ainsi, en pratique, tout les les noms d'hôte (eepsite) HTTP doivent se terminer avec le pseudo en domaine de niveau pseudo-supérieur '.i2p'.

Nous nous sommes appliqués à réserver le TLD .i2p en suivant les procédures indiquées dans le RFC 6761.

Si le routeur échoue à résoudre le nom d'hôte, le proxy HTTP retourne à l'utilisateur une page d'erreur avec des liens vers plusieurs services de "saut". Voir ci-dessous pour des détails.

Carnet d'adresses

Abonnements entrants et fusion

L'application carnet d'adresses récupère périodiquement les fichiers hosts.txt d'autres utilisateurs et les mêle avec le hosts.txt local, après plusieurs contrôles. Les conflits de nommage sont résolus sur une base premier-arrivé premier-servi.

S'abonner au fichier hosts.txt d'un autre utilisateur implique leur donner une certaine quantité de confiance. Vous ne voulez pas, par exemple, qu'ils 'détournent' un nouveau site en entrant rapidement dans leur propre clé pour un nouveau site avant de vous passer la nouvelle clé.

Pour cette raison, le seul abonnement configuré par défaut est http://i2p-projekt.i2p/hosts.txt (http://udhdrtrcetjm5sxzskjyr5ztpeszydbh4dpl3pl4utgqqw2v4jna.b32.i2p/hosts.txt), qui contient une copie du fichiers hosts.txt inclu dans la version d'I2P. Les utilisateurs doivent configurer des abonnements additionnels dans leur application locale de carnet d'adresses (via subscriptions.txt ou SusiDNS).

Quelques autres liens d'abonnement à des carnets d'adresses publics :

Les opérateurs de ces services peuvent avoir des politiques diverses pour inscrire des hôtes. La présence dans cette liste n'implique pas approbation.

Règles de nommage

Tandis qu'il n'y a par chance pas de limitations techniques dans I2P sur les noms hôtes le carnet d'adresses fait respecter plusieurs restrictions de noms hôtes importés depuis des abonnements. Il fait ceci pour la santé typographique basique et la compatibilité avec les navigateurs, et pour la sécurité. Les règles sont essentiellement les mêmes que celles dans la RFC2396 section 3.2.2. Quelconque nom d'hôte violant ces règles ne peut pas être propagé à d'autres routeurs.

Règles de nommage:

  • Les noms sont convertis en minuscule lors de l'importation.
  • Les noms sont vérifiés contre le conflit avec des noms existants dans userhosts.txt existant et hosts.txt (mais pas privatehosts.txt) après conversion en minuscule.
  • Doivent contenir seulement [a-z] [0-9] '.' et '-' après conversion en minuscules.
  • Ne doivent pas commencer avec '.' ni '-'.
  • Doivent terminer par 'i2p'.
  • 67 caractères maximum, incluant le '.i2p'.
  • Ne doivent pas contenir '..'.
  • Ne doivent pas contenir '..' ou '-.' (depuis la 0.6.1.33).
  • Ne doivent pas contenir '--' excepté dans 'xn--' pour IDN.
  • Les noms d'hôte Base32 (*.b32.i2p) sont réservés pour un usage en base 32 et par conséquent ne sont pas autorisés à être importés.
  • Certains noms d'hôtes réservés pour l'usage du projet ne sont pas autorisés (proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, *.console.i2p, et autres)
  • Les clés sont vérifiées concernant la validité base64.
  • Les clés sont vérifiées contre le conflit avec des clés existantes dans hosts.txt (mais pas privatehosts.txt).
  • Longueur minimum de clé : 516 octets.
  • Longueur maximum de clé : 616 octets (pour tenir compte des certs jusqu'à 100 octets).

N'importe quel nom, reçu via abonnement, qui passe tous les contrôles est ajouté via le service de nommage local.

Notez que les symboles '.' dans un nom hôte n'ont aucune signification et ne dénotent pas de hiérarchie de nommage ni de confiance. Si le nom 'host.i2p' existe déjà, il n'y a rien pour empêcher quelqu'un d'ajouter un nom 'a.host.i2p' à son hosts.txt, et ce nom pourra être importé par les carnets d'adresses d'autres personnes. Des méthodes pour refuser des sous-domaines aux 'propriétaires' de non-domaines (des certificats ?) et la désirabilité et la faisabilité de ces méthodes sont sujets de discussions futures.

Les noms de domaine internationaux (IDN) marchent aussi dans i2p (utilisant le punycode de forme 'xn--'). Pour voir les noms de domaine IDN .i2p rendus correctement dans la barre d'adresse de Firefox, ajoutez 'network.IDN.whitelist.i2p (boolean) = true' dans about:config.

Comme l'application carnet d'adresses n'utilise pas du tout privatehosts.txt, en pratique ce fichier est le seul endroit où il est approprié de placer des alias privés ou "pet names" pour des sites déjà présents dans hosts.txt.

Advanced Subscription Feed Format

As of release 0.9.26, subscription sites and clients may support an advanced hosts.txt feed protocol that includes metadata including signatures. This format is backwards-compatible with the standard hosts.txt hostname=base64destination format. See Proposal 112 for details.

Abonnements sortants

Addressbook publiera les hosts.txt fusionnés à un emplacement (traditionnellement hosts.txt dans le répertoire home de l'eepsite's local) afin qu'il soit accessible par d'autres pour leurs abonnements. Cette étape est facultative et est désactivée par défaut.

Hosting and HTTP Transport Issues

L'application carnet d'adresses, ensemble avec eepget, sauve l'Etag et-ou l'informations de dernière-modication rendues par le serveur Web de l'abonnement. Ceci réduit grandement la bande passante exigée, car le serveur Web va retourner un '304 non modifié' sur la prochaine récupération si rien n'a changé.

Cependant hosts.txt est téléchargé en entier si il a changé. Voir ci-dessous pour la discussion sur cette question.

Les hôtes servant un hosts.txt statique ou une application CGI équivalente sont fortement encouragés à livrer un en-tête de longueur de contenu, et soit une Etag ou une en-tête de derniere modification. Assurez aussi que le serveur livre 'un '304 non modifié' quand c'est nécessaire. Ceci réduira radicalement la bande passante de réseau et réduira les risques de corruption.

Services d'ajout d'hôtes

Un service d'ajout d'hôte est une simple application CGI qui prend un nom d'hôte et une clé en Base64 comme paramètres et ajoute cela à son hosts.txt local. Si d'autres routeurs s'abonnent à ce hosts.txt, le nouveau nom d'hôte ou clé seront propagés à travers le réseau.

Il est recommandé que les services de nom d'hôte imposent, au minimum, les restrictions imposées par la l'application carnet d'adresses inscrite ci-dessus. Les services d'ajout d'hôtes peuvent imposer des restrictions supplémentaires de nom d'hôtes et de clés, par exemple :

  • Une limite concernant le nombre de 'sous-domaines'.
  • Autorisation de 'sous-domaines' à travers diverses méthodes.
  • Certificats signés ou hashcash.
  • Examen éditorial des noms d'hôte et/ou du contenu.
  • Catégorisation par contenu des noms d'hôtes.
  • Réservation ou rejet de certains noms hôtes.
  • Restrictions sur le nombre de noms enregistrés durant une période donnée.
  • Retards entre enregistrement et publication.
  • Exiger que l'hôte soit en ligne afin d'être vérifié.
  • Expiration et/ou révocation.
  • Rejet d'usurpation IDN

Services de saut

Un service de saut est une simple application CGI qui prend un nom d'hôte comme paramètre et retourne une redirection 301 redirigeant vers l'URL appropriée avec une chaîne ?i2paddresshelper=key ajoutée. Le proxy HTTP va interpréter la chaîne ajoutée et utiliser cette clé en tant que destination réelle. De plus, le proxy va mettre cette clé en cache afin que le carnet d'adresses ne soit plus nécessaire jusqu'au redémarrage.

Notez que, comme avec les abonnements, utiliser un service de saut implique une certaine quantité de confiance, car le un service de saut pourrait de façon malveillante rediriger un utilisateur vers une destination incorrecte.

Pour fournir le meilleur service, un service de saut devrait être abonné à plusieurs fournisseurs hosts.txt afin que sa liste d'hôtes locaux soit actuelle.

SusiDNS

SusiDNS est simplement une interface Web frontale pour configurer les abonnements de carnet d'adresses et accéder aux quatre fichiers de carnet d'adresses. Tout le travail réel est fait par l'application 'carnet d'adresses'.

Actuellement, il y a peu d'exécutions des règles de nommage de carnet d'adresses dans SusiDNS, donc un utilisateur peut entrer des noms d'hôtes localement qui seraient rejetés par les règles d'abonnement de carnet d'adresses.

Noms Base32

I2P supporte les noms d'hôte en Base32 semblables aux adresses .onion de Tor. Les adresses Base32 sont beaucoup plus courtes et plus faciles à manipuler que les destinations Base64 pleines à 516 caractères ou les aides d'adresse. Exemple : ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p

In Tor, the address is 16 characters (80 bits), or half of the SHA-1 hash. I2P uses 52 characters (256 bits) to represent the full SHA-256 hash. The form is {52 chars}.b32.i2p. Tor has recently published a proposal to convert to an identical format of {52 chars}.onion for their hidden services. Base32 is implemented in the naming service, which queries the router over I2CP to lookup the LeaseSet to get the full Destination. Base32 lookups will only be successful when the Destination is up and publishing a LeaseSet. Because resolution may require a network database lookup, it may take significantly longer than a local address book lookup.

Les adresses Base32 peuvent être utilisées dans la plupart des endroits où noms d'hôte ou des destinations pleines sont utilisées, cependant il y a quelques exceptions où elles peuvent échouer si le nom n'est pas résolu immédiatement . I2PTunnel échouera, par exemple, si le nom ne résout pas à une destination.