Esta página fue actualizada por última vez el 2020-07 y es precisa con la versión 0.9.46 del router I2P.

Vista general

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.

NOTA: Para encontrar las razones detrás del sistema de nombres de I2P, los argumentos habituales contra él y las posibles alternativas, vea la página de discusión sobre el sistema de nombres.

Componentes del sistema de nombres

No hay una autoridad central de nombres en I2P. Todos los nombres de servidor están en local.

El sistema de nombres es bastante simple, y la mayoria de él está implementado en aplicaciones externas al router pero empaquetadas con la distribución I2P. Los componentes son:

  1. El servicio de nombres local que hace búsquedas y también maneja los nombres de equipos Base32.
  2. El proxy HTTP que realiza consultas al router I2P y dirige al usuario a servicios de salto (jump, de direccionamiento distribuido) remotos para asistirle con las consultas fallidas.
  3. Formularios de añadido de servidores HTTP que permiten a los usuarios añadir servidores a su hosts.txt local.
  4. Servicios de salto (jump) HTTP que proporcionan sus propias búsquedas y redireccionamiento distribuido.
  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.

Servicios de nombres

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 una aplicación (i2ptunnel o el proxy HTTP) quiere acceder a un destino mediante el nombre, el router hace una búsqueda local muy simple para resolver ese nombre.

Servicio de nombres hosts.txt

El servicio de nombres hosts.txt hace una búsqueda lineal simple a través de ficheros de texto. Este servicio de nombres fue la norma hasta la versión 0.8.8 cuando fue reemplazado por el servicio de nombres blockfile (fichero de bloques). El formato de hosts.txt ha llegado a ser demasiado lento después de que el fichero creciera hasta las miles de entradas.

Realiza una búsqueda lineal a través de tres ficheros locales, en orden, para buscar nombres de equipos y convertirlos a claves de destinos de 516-bytes. Cada fichero está en un formato de fichero de configuración simple, con (nombre de equipo) hostname=base64, uno por línea. Los ficheros son:

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

Servicio de nombres 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.

Al crearse, el servicio de nombres importa entradas desde los tres ficheros usados por el servicio de nombres hosts.txt. El blockfile imita la anterior implementación al mantener tres mapeados que se buscan en-orden, llamados privatehosts.txt, userhosts.txt, y hosts.txt. También mantiene un mapeado de búsqueda-inversa para implementar búsquedas inversas rápidas.

Otras infraestructuras de servicio de nombres

La búsqueda distingue mayúsculas/minúsculas. Se usa la primera coincidencia, y no se detectan los conflictos. No se hace aplicación de las reglas de nombres en las búsquedas. Las búsquedas se guardan en caché durante unos pocos minutos. La resolución Base32 se describe debajo. Para una descripción completa de la API del servicio de nombres vea los Javadocs del servicio de nombres. Esta API fue expandida significativamente en la versión 0.8.7 para proporcionar adiciones y eliminaciones, almacenamiento de propiedades arbitrarias junto al el nombre del equipo, y otras características.

Alternativas y servicios de nombres experimentales

El servicio de nombres se especifica con la propiedad de configuración i2p.naming.impl=class. Otras implementaciones son posibles. Por ejemplo, hay una infraestructura experimental para búsquedas en tiempo-real (estilo DNS) sobre la red interior al router. Para más información vea la página de discusión sobre alternativas.

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'.

Tenemos solicitada la reserva del TLD (dominio de primer nivel) .i2p siguiendo los procedimientos especificados en la RFC 6761.

Si el router I2P falla al resolver el nombre del servidor, el proxy HTTP devuelve una página de error al usuario con enlaces a varios servicios de salto (jump, direccionamiento distribuido). Más detalles debajo.

Address Book

Suscripciones entrantes y fusionado

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.

Suscribirse al fichero hosts.txt de otros usuarios implica darles un cierto nivel de confianza. No querrá que ellos, por ejemplo, 'secuestren' un sitio nuevo introduciendo rápidamente su propia clave para el nuevo sitio antes de pasarle el nuevo servidor/clave a usted.

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:

Los operadores de estos servicios pueden tener diferentes políticas para listar servidores. La presencia en esta lista no implica su respaldo.

Reglas de nombres

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.

Reglas de nombres:

  • Los nombres se convierten a minúsculas al importarlos.
  • Se comprueban los conflictos entre los nombres y los nombres existentes en userhosts.txt y hosts.txt (pero no privatehosts.txt) tras su conversión a minúsculas.
  • Sólo deben contener [a-z] [0-9] '.' y '-' tras su conversión a minúsculas.
  • No deben comenzar con '.' o '-'.
  • Debe terminar en «.i2p».
  • Máximo 67 caracteres, incluyendo el '.i2p'.
  • No puede contener «..».
  • No deben contener '.-' o '-.' (a partir de la 0.6.1.33).
  • No deben contener '--' excepto en 'xn--' para IDN.
  • Los nombres de equipo Base32 (*.b32.i2p) están reservados para el uso de base 32 y por tanto no está permitida su importación.
  • Ciertos nombres de servidor reservados para uso del proyecto no están autorizados (proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, *.console.i2p, y otros)
  • Se comprueba la validez base64 de las claves.
  • Se comprueba si las claves tienen conflictos con claves existentes en hosts.txt (pero no privatehosts.txt).
  • La longitud mínima de clave es 516 bytes.
  • La longitud máxima de clave es 616 bytes (para contar con certificados de hasta 100 bytes).

Cualquier nombre recibido vía suscripción que pase todas las comprobaciones, se añade a través del servicio de nombres local.

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.

Los Nombres de Dominio Internacionales (IDN) también funcionan con I2P (usando la forma punycode 'xn--'). Para ver nombres de dominio .i2p IDN correctamente formados en la barra de direcciones de Firefox, añada 'network.IDN.whitelist.i2p (boolean) = true' en 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.

Formato de suscripción (feed) avanzado

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.

Suscripciones salientes

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.

Sin embargo, si ha cambiado se descarga el hosts.txt completo. Mire debajo las discusiones sobre este asunto.

Se recomienda que los servidores que sirven un archivo host.txt o una aplicación CGI equivalente, lleven una cabecera con el tqmaño del contenido, Content-Length header, y una Etag o la última cabecera modificada, Last-Modified header. Además asegúrese de que el servidor muestra el aviso '304 Not Modified' cuando sea apropiado. Esto reducirá dramáticamente el ancho de banda usado, y reducirá las posibilidades de corrupción.

Servicio de gestión de dominios

Un servicio de gestión de dominios es una aplicación CGI simple que toma un nombre de dominio y una clave Base64 como parámetros y loa añade a su hosts.txt local. SI otros ruters se suscriben a ese host.txt, el nuevo nombre de domino/clave serán propagados a través de la red.

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:

  • Un 'límite' en el número de 'subdominios'.
  • Autorización para los 'subdominios' a través de varios métodos.
  • Hashcash o certificados firmados.
  • Revisión editorial de los nombres de dominio y/o su contenido.
  • Clasificación de los dominios según su contenido.
  • Reserva o rechazo de ciertos dominios.
  • Restricciones en el número de dominios registrados en un determinado periodo de tiempo.
  • Intervalos entre los registros y las publicaciones.
  • Exigir que el servidor esté funcionando para su verificaión.
  • Expiración y/o revocación.
  • Denegación de IDN spoof.

Servicios de salto (jump)

Un servicio de salto (jump), es una simple aplicación CGI que toma un nombre de servidor como parámetro y devuelve un redireccionamiento 301 hacia la URL adecuada con una cadena de texto ?i2paddresshelper=clave anexa. El proxy HTTP interpretará la cadena de texto anexa y usará esa clave como el destino I2P de facto. Además, el proxy guardará en caché esa clave de forma que el ayudante de direccionamiento (address helper) no sea necesario hasta reiniciar.

Dese cuenta que, al igual que con las suscripciones, usar un servicio de salto (jum p, direccionamiento distribuido) implica una cierta dosis de confianza, ya que un servicio de salto podría redirigir maliciosamente a un usuario a un destino I2P incorrecto.

Para proporcionar el mejor servicio, un servicio de salto (jump, direccionamiento distribuido) debe estar suscrito a varios proveedores de ficheros hosts.txt para que su lista local de servidores esté al día.

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.

Dominios Base32

I2P soporta nombres de dominios Base32 similares a las direcciones .onion de Tor. Las direcciones Base32 son mucho más fáciles de manejar y mucho más cortas que los addresshelpers o las Destinaciones Base64 de 516 caracteres. Ejemplo: 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.

Las direcciones Base32 pueden ser usadas en la mayoría de sitios donde se puedan usar los nombres de dominios o la Destinación completa, aunque hay algunas excepciones donde podría fallar sin el dominio no se resuelve inmediatamente, Por ejemplo, I2PTunnel fallará si el domino no resuelve una destinación.