i2p.www/www.i2p2/pages/naming_fr.html

{% extends "_layout_fr.html" %}
{% block title %}Nommage et carnet d'adresses{% endblock %}
{% block content %}
Traduction (en cours) d'avril 2011. <a href="naming.html">Version anglaise actuelle</a>
<h1>Nommage dans I2P</h1>
<h2 id="overview">Aperçu</h2>

<p>
I2P est distribué avec une bibliothèque générique de nommage et une implémentation de base conçue pour fonctionner à 
partir d'une correspondance nom/destination locale, ainsi qu'avec une application compagne appelée le 
<a href="#addressbook">carnet d'adresses</a>. 
I2P supporte également les <a href="#base32">noms d'hôtes Base32</a> identiques aux adresses .onion de Tor.</p>

<p>
Le carnet d'adresses est un système de nommage fondé sur un réseau de confiance, décentralisé et lisible par un être 
humain, qui ne déroge au principe d'unicité globale de ces systèmes de nommages lisibles par l'humain en n'exigeant 
qu'une unicité locale. Comme tous les messages dans I2P sont adressés à leur destination sur une base cryptographique, 
différentes personnes peuvent avoir l'entrée "Alice" dans leur carnet d'adresses local qui représente des destinations 
différentes. Les utilisateurs découvrir de nouveaux noms en important les carnets d'adresses publiés par les pairs de 
leur réseau de confiance, en ajoutant des entrées fournies par un tiers, ou (si quelques uns organisent une série de 
carnets d'adresses publiés en utilisant un système d'enregistrement "premier venu, premier servi") en choisissant de se 
servir de ces carnets d'adresses en tant que serveurs de noms, émulant ainsi le DNS traditionnel.
</p>

<p>
NOTE : pour en savoir plus sur les raisons de ce choix de nommage pour I2P, sur les arguments courants à son encontre, 
et sur alternatives possibles, voir la page <a href="naming_discussion.html">discussion sur le nommage</a>
page.
</p>


<h2 id="components">Composants du système de nammage</h2>
<p>
Il n'y a pas d'autorité de nommage centrale dans I2P. Tous les noms d'hôtes sont locaux.
</p>
<p>
Le système de nommage est assez simple et sa plus grande partie est implémentée dans des applications externes au 
routeur, mais incluses dans sa distribution.
Les composants :
</p>
<ol>
<li>L'<a href="#lookup">application cliente</a>, qui effectue les recherches locales dans le fichier hosts.txt et gère 
les <a href="#base32">noms d'hôtes Base32</a>.
<li>Le <a href="#httpproxy">mandataire HTTP</a>, qui confie les recherches au routeur et dirige l'utilisateur vers les 
services de saut distants en tant qu'assistance en cas recherches infructueuses.
<li>Des <a href="#add-services">formulaires d'ajout d'hôte</a> HTTP, qui permettent aux utilisateurs&hellip; d'ajouter 
des hôtes à leur hosts.txt local.
<li>Des <a href="#jump-services">services de sauts</a> HTTP, qui fournissent leur propres recherches et listes de 
redirections.
<li>L'application <a href="#addressbook">carnet d'adresses</a>, qui fusionne les listes externes d'hôtes trouvées par 
HTTP à la liste locale.
<li>L'application <a href="#susidns">SusiDNS</a>, simple interface web de configuration du carnet d'adresses et 
d'affichage les listes d'hôtes locales.
</ol>

<h2 id="lookup">Fichiers de nommage et recherches</h2>
<p>
All destinations in I2P are 516-byte keys.
(To be more precise, it is a 256-byte public key plus a 128-byte signing key
plus a null certificate, which in Base64 representation is 516 bytes.
<a href="naming_discussion.html#certificates">Certificates</a> are not used now,
if they are, the keys will be longer.
One possible use of certificates is for <a href="todo_fr.html#hashcash">proof of work</a>.)
</p><p>
If an application (i2ptunnel or the HTTP proxy) wishes to access
a destination by name, the router does a very simple local lookup
to resolve that name.
The client application (technically, the client side of I2CP in the I2P API)
does a linear search through three local files, in order, to
look up host names and convert them to a 516-byte destination key:
<ol>
<li>privatehosts.txt
<li>userhosts.txt
<li>hosts.txt
</ol>
<p>The lookup is case-insensitive.
The first match is used, and conflicts are not detected.
There is no enforcement of naming rules in lookups.
</p><p>
Lookups are cached for a few minutes.
There is an experimental facility for real-time lookups (a la DNS) over the network within the router,
although it is not enabled by default
(see "EepGet" under <a href="naming_discussion.html#alternatives">Alternatives on the discussion page</a>).
</p>

<h2 id="httpproxy">HTTP Proxy</h2>
<p>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 (eepsite) hostnames must end in the pseudo-Top Level Domain '.i2p'.
</p>

<p>
If the router fails to resolve the hostname, the HTTP proxy returns
an error page to the user with links to several "jump" services.
See below for details.
</p>

<h2 id="addressbook">Addressbook</h2>
<h3>Incoming Subscriptions and Merging</h3>
<p>
The addressbook 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.
</p><p>
Subscribing to another user's hosts.txt file involves
giving them a certain amount of trust.
You do not want them, for example, 'hijacking' a new site
by quickly entering in their own key for a new site before
passing the new host/key entry to you.
</p><p>
For this reason, the only subscription configured by
default is <code>http://www.i2p2.i2p/hosts.txt</code>,
which contains a copy of the hosts.txt included
in the I2P release.
Users must configure additional subscriptions in their
local addressbook application (via subscriptions.txt or <a href="#susidns">SusiDNS</a>).
</p><p>
Some other public addressbook subscription links:
</p>
<ul>
<li><a href="http://i2host.i2p/cgi-bin/i2hostetag">http://i2host.i2p/cgi-bin/i2hostetag</a>
<li><a href="http://stats.i2p/cgi-bin/newhosts.txt">http://stats.i2p/cgi-bin/newhosts.txt</a>
<li><a href="http://tino.i2p/hosts.txt">http://tino.i2p/hosts.txt</a>
</ul>
<p>
The operators of these services may have various policies for listing hosts.
Presence on this list does not imply endorsement.
</p>

<h3>Naming Rules</h3>
<p>
While there are hopefully not any technical limitations within I2P on host names,
the addressbook 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.
</p><p>
Naming rules:</p>
<ul>
<li>Names are converted to lower case on import.
<li>Names are checked for conflict with existing names in the existing userhosts.txt and hosts.txt
(but not privatehosts.txt) after conversion to lower case.
<li>Must contain only [a-z] [0-9] '.' and '-' after conversion to lower case.
<li>Must not start with '.' or '-'.
<li>Must end with '.i2p'.
<li>67 characters maximum, including the '.i2p'.
<li>Must not contain '..'.
<li>Must not contain '.-' or '-.' (as of 0.6.1.33).
<li>Must not contain '--' except in 'xn--' for IDN.
<li>Base 32 hostnames (*.b32.i2p) are not allowed.
<li>Certain hostnames reserved for project use are not allowed
    (proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, *.proxy.i2p).
<li>Keys are checked for base64 validity.
<li>Keys are checked for conflict with existing keys in hosts.txt (but not privatehosts.txt).
<li>Minimum key length 516 bytes.
<li>Maximum key length 616 bytes (to account for certs up to 100 bytes).
</ul>
<p>
Any name received via subscription that passes all the checks is added to the local hosts.txt.		
</p><p>
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' addressbook.
Methods to deny subdomains to non-domain 'owners' (certificates?),
and the desirability and feasibility of these methods,
are topics for future discussion.
</p><p>
International Domain Names (IDN) also work in i2p (using punycode 'xn--' form).
To see IDN .i2p domain names rendered correctly in Firefox's location bar,
add 'network.IDN.whitelist.i2p (boolean) = true' in about:config.
</p><p>
As the addressbook 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.
</p>

<h3>Outgoing Subscriptions</h3>
<p>
Addressbook will publish the merged hosts.txt to a location
(traditionally hosts.txt in the local eepsite's home directory) to be accessed by others
for their subscriptions.
This step is optional and is disabled by default.
</p>

<h3>Hosting and HTTP Transport Issues</h3>
<p>
The addressbook 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.
</p>
<p>
However the entire hosts.txt is downloaded if it has changed.
See below for discussion on this issue.
</p>
<p>
Hosts serving a static hosts.txt or an equivalent CGI application
are strongly encouraged to deliver
a Content-Length header, and either an Etag or Last-Modified header.
Also ensure that the server delivers a '304 Not Modified' when appropriate.
This will dramatically reduce the network bandwidth, and
reduce chances of corruption.
</p>

<h2 id="add-services">Host Add Services</h2>
<p>
A host add service is a simple CGI application that takes a hostname and a Base64 key as parameters
and adds that to its local hosts.txt.
If other routers subscribe to that hosts.txt, the new hostname/key
will be propagated through the network.
</p><p>
It is recommended that host add services impose, at a minimum, the restrictions imposed by the 
addressbook application listed above.
Host add services may impose additional restrictions on hostnames and keys, for example:
</p>
<ul>
<li>A limit on number of 'subdomains'.
<li>Authorization for 'subdomains' through various methods.
<li>Hashcash or signed certificates.
<li>Editorial review of host names and/or content.
<li>Categorization of hosts by content.
<li>Reservation or rejection of certain host names.
<li>Restrictions on the number of names registered in a given time period.
<li>Delays between registration and publication.
<li>Requirement that the host be up for verification.
<li>Expiration and/or revocation.
<li>IDN spoof rejection.
</ul>

<h2 id="jump-services">Jump Services</h2>
<p>
A jump service is a simple CGI application that takes a hostname as a parameter
and returns a 301 redirect to the proper URL with a <code>?i2paddresshelper=key</code>
string appended.
The HTTP proxy will interpret the appended string and
use that key as the actual destination.
In addition, the proxy will cache that key so the
address helper is not necessary until restart.
</p>
<p>
Note that, like with subscriptions, using a jump service
implies a certain amount of trust, as a jump service could maliciously
redirect a user to an incorrect destination.
</p>
<p>
To provide the best service, a jump service should be subscribed to
several hosts.txt providers so that its local host list is current.
</p>

<h2 id="susidns">SusiDNS</h2>
<p>
SusiDNS is simply a web interface front-end to configuring addressbook subscriptions
and accessing the four addressbook files.
All the real work is done by the 'addressbook' application.
</p><p>
Currently, there is no enforcement of addressbook naming rules within SusiDNS,
so you can enter hostnames locally that would be rejected by
your own or others' addressbook subscriptions.
</p>

<h2 id="base32">Base 32 Names</h2>
<p>I2P supports Base32 hostnames similar to Tor's .onion addresses.
Base32 addresses are much shorter and easier to handle than the
full 516-character Base64 Destinations or addresshelpers.
Example: <code>ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p</code>
</p><p>
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.
Base32 is implemented in the HostsTxt 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.
</p><p>
Base32 addresses can be used in most places where hostnames or full destinations
are used, however there are some exceptions where they may fail if the
name does not immediately resolve. I2PTunnel will fail, for example, if
the name does not resolve to a destination.
</p>
{% endblock %}