La dernière mise à jour de cette page été effectuée en 2020-07 et est exacte pour la version 0.9.46 du routeur.

Vue d’ensemble

I2P ships with a generic naming library and a base implementation designed to work off a local name to destination mapping, as well as an add-on application called the address book. I2P also supports Base32 hostnames similar to Tor's .onion addresses.

The address book is a web-of-trust driven secure, distributed, and human readable naming system, sacrificing only the call for all human readable names to be globally unique by mandating only local uniqueness. While all messages in I2P are cryptographically addressed by their destination, different people can have local address book entries for "Alice" which refer to different destinations. People can still discover new names by importing published address books of peers specified in their web of trust, by adding in the entries provided through a third party, or (if some people organize a series of published address books using a first come first serve registration system) people can choose to treat these address books as name servers, emulating traditional DNS.

NOTE : Pour comprendre le raisonnement qui sous-tend le système de nommage d’I2P, les arguments contre ce dernier et les solutions de remplacement possibles, consultez la page discussion sur le 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 noms local qui assure les consultations et gère aussi les noms d’hôtes Base32.
  2. Le mandataire HTTP qui demande au routeur des consultations et dirige l’utilisateur vers des services de saut distants afin de pallier les échecs de consultation.
  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 redirection.
  5. The address book application which merges external host lists, retrieved via HTTP, with the local list.
  6. The SusiDNS application which is a simple web front-end for address book configuration and viewing of the local host lists.

Services de noms

All destinations in I2P are 516-byte (or longer) keys. (To be more precise, it is a 256-byte public key plus a 128-byte signing key plus a 3-or-more byte certificate, which in Base64 representation is 516 or more bytes. Non-null Certificates are in use now for signature type indication. Therefore, certificates in recently-generated destinations are more than 3 bytes.

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

Service de noms hosts.txt

Le service de noms hosts.txt effectue une simple recherche linéaire de fichiers texte. Ce système de noms était celui par défaut jusqu’à la version 0.8.8. Il fut alors remplacé par le système de noms Blockfile. Le format hosts.txt était devenu trop lent après que le fichier a 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 noms Blockfile

The Blockfile Naming Service stores multiple "address books" in a single database file named hostsdb.blockfile. This Naming Service is the default since release 0.8.8.

A blockfile is simply on-disk storage of multiple sorted maps (key-value pairs), implemented as skiplists. The blockfile format is specified on the Blockfile page. It provides fast Destination lookup in a compact format. While the blockfile overhead is substantial, the destinations are stored in binary rather than in Base 64 as in the hosts.txt format. In addition, the blockfile provides the capability of arbitrary metadata storage (such as added date, source, and comments) for each entry to implement advanced address book features. The blockfile storage requirement is a modest increase over the hosts.txt format, and the blockfile provides approximately 10x reduction in lookup times.

Lors de la création, le service de noms importe des entrées des trois fichiers utilisés par le service de noms hosts.txt. Le blockfile imite la mise en œuvre précédente en maintenant trois cartes qui sont consultées en ordre, nommées privatehosts.txt, userhosts.txt et hosts.txt. Il maintient aussi une carte de consultation inversée pour mettre en œuvre des consultations inversés rapides.

Autres services de noms

La consultation est insensible à la casse. La première correspondance est utilisée et les conflits ne sont pas détectés. Aucune règle de nommage n’est observée lors de consultations. Les consultations sont mises en cache durant quelques minutes. La résolution Base32 est décrite ci-dessous. Pour obtenir une description complète de l’API de service de noms, consulter la documentation Jave sur les services de noms. Cette API a été significativement augmentée dans la version 0.8.7 pour offrir des ajouts et retraits, un stockage de propriétés arbitraires avec le nom d’hôte et d’autres fonctions.

Services de noms de substitution et expérimentaux

Le service de noms est indiqué par la propriété de configuration i2p.naming.impl=class. D’autres mises en œuvre sont possibles. Par exemple, il y a une possibilité expérimentale pour les consultations en temps réel (de type DNS) par le réseau et dans le routeur. Pour de plus amples informations, consulter les autres possibilités sur la page de discussion.

The HTTP proxy does a lookup via the router for all hostnames ending in '.i2p'. Otherwise, it forwards the request to a configured HTTP outproxy. Thus, in practice, all HTTP (I2P Site) hostnames must end in the pseudo-Top Level Domain '.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 n’arrive pas à résoudre le nom d’hôte, le mandataire HTTP retourne à l’utilisateur une page d’erreur avec des liens vers plusieurs services de « saut ». Voir ci-dessous pour plus de précisions.

Address Book

Abonnements entrants et fusion

The address book application periodically retrieves other users' hosts.txt files and merges them with the local hosts.txt, after several checks. Naming conflicts are resolved on a first-come first-served basis.

S’abonner au fichier hosts.txt d’un autre utilisateur implique de lui accorder une certaine confiance. Vous ne voulez pas, par exemple, qu’ils « détournent » un nouveau site en saisissant rapidement leur propre clé pour un nouveau site avant de vous passer la nouvelle entrée d’hôte, de clé.

For this reason, the only subscription configured by default is http://i2p-projekt.i2p/hosts.txt (http://udhdrtrcetjm5sxzskjyr5ztpeszydbh4dpl3pl4utgqqw2v4jna.b32.i2p/hosts.txt), which contains a copy of the hosts.txt included in the I2P release. Users must configure additional subscriptions in their local address book application (via subscriptions.txt or SusiDNS).

Some other public address book subscription links:

Les opérateurs de ces services peuvent avoir différentes politiques de listage des hôtes. La présence dans cette liste n’implique pas une approbation.

Règles de nommage

While there are hopefully not any technical limitations within I2P on host names, the address book enforces several restrictions on host names imported from subscriptions. It does this for basic typographical sanity and compatibility with browsers, and for security. The rules are essentially the same as those in RFC2396 Section 3.2.2. Any hostnames violating these rules may not be propagated to other routers.

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 au maximum, le '.i2p' compris.
  • 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 Base32 et ne peuvent donc pas ê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)
  • La validité Base64 des clés est vérifiée.
  • 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).

Tout nom reçu par abonnement qui subit avec succès toutes les vérifications est ajouté par le système local de noms.

Note that the '.' symbols in a host name are of no significance, and do not denote any actual naming or trust hierarchy. If the name 'host.i2p' already exists, there is nothing to prevent anybody from adding a name 'a.host.i2p' to their hosts.txt, and this name can be imported by others' address book. Methods to deny subdomains to non-domain 'owners' (certificates?), and the desirability and feasibility of these methods, are topics for future discussion.

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.

As the address book application does not use privatehosts.txt at all, in practice this file is the only place where it is appropriate to place private aliases or "pet names" for sites already in hosts.txt.

Format évolué de flux d’abonnement

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 the specification for details.

Abonnements sortants

Address Book will publish the merged hosts.txt to a location (traditionally hosts.txt in the local I2P Site's home directory) to be accessed by others for their subscriptions. This step is optional and is disabled by default.

Hosting and HTTP Transport Issues

The address book application, together with eepget, saves the Etag and/or Last-Modified information returned by the web server of the subscription. This greatly reduces the bandwidth required, as the web server will return a '304 Not Modified' on the next fetch if nothing has changed.

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 fixe ou une application CGI équivalente sont fortement encouragés à livrer un en-tête de longueur de contenu et soit une balise Etag, soit un en-tête de dernière modification. Cela garantit aussi que le serveur livre un « 304 not modified » (304 non modifié) si nécessaire. La bande passante du réseau sera considérablement réduite et les risques de corruption seront aussi réduits.

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.

It is recommended that host add services impose, at a minimum, the restrictions imposed by the address book application listed above. Host add services may impose additional restrictions on hostnames and keys, for example:

  • Une limite concernant le nombre de 'sous-domaines'.
  • Autorisation de 'sous-domaines' à travers diverses méthodes.
  • Certificats signés ou hashcash.
  • Révision des noms d’hôte ou du contenu.
  • Catégorisation par contenu des noms d’hôtes.
  • Réservation ou refus 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 ou révocation.
  • Refus 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 vers l’URL appropriée en ajoutant une chaîne ?i2paddresshelper=key. Le mandataire HTTP interprétera la chaîne ajoutée et utilisera cette clé comme destination effective. De plus, le mandataire mettra cette clé en cache afin que l’aide d’adresse ne soit plus nécessaire jusqu’au redémarrage.

Notez que, comme avec les abonnements, utiliser un service de saut implique une certaine confiance, car 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 is simply a web interface front-end to configuring address book subscriptions and accessing the four address book files. All the real work is done by the 'address book' application.

Currently, there is little enforcement of address book naming rules within SusiDNS, so a user may enter hostnames locally that would be rejected by the address book subscription rules.

Noms Base32

I2P prend en charge 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 complètes Base64 à 516 caractères ou que 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 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.