Esta página fue actualizada por última vez el Enero de 2017 y es precisa con la versión 0.9.28 del router I2P.

Hay varios clientes bittorrent y trackers sobre I2P. Como el direccionamiento de I2P usa un Destino en lugar de IP y puerto, los cambios que se requieren en los softwares del tracker y del cliente para operar sobre I2P son menores. Estos cambios se especifican debajo. Observe con cuidado las directrices para compatibilidad con anteriores clientes y trackers I2P.

Esta página especifica detalles del protocolo comunes a todos los clientes y trackers. Los clientes y trackers específicos pueden implementar otras características únicas o protocolos.

Son bienvenidos puertos adicionales de software de cliente y tracker para I2P.

Anuncios

Los clientes generalmente incluyen un parámetro falso port=6881 en el anuncio, por compatibilidad con anteriores trackers. Los trackers pueden ignorar el parámetro port (puerto), y no deberían necesitarlo.

El parámetro IP es la base 64 de la Destinación del cliente, usando el alfabeto I2P Base 64 [A-Z][a-z][0-9]-~. Las Destinaciones son de 387+ bytes, con lo que la Base 64 es de 516+ bytes. Los clientes generalmente añaden ".i2p" a la Destinación Base 64 para mantener la compatibilidad con los trackers antiguos. Los trackers no deberían necesitar añadir ".i2p" al final.

Otros parámetros son los mismos que en el bittorrent estandar.

Los actuales destinos I2P para clientes son de 387 bytes o más (516 o más con codificación Base64). Un máximo razonable a asumir, por ahora, es 475 bytes. Como el tracker debe decodificar la Base64 para producir respuestas compactas (vea debajo), probablemente el tracker debe decodificar y rechazar la Base64 erróneas cuando esto se anuncie.

La respuesta tipo predeterminada es no-compacta. Los clientes pueden solicitar una respuesta compacta con el parámetro compact=1. Un tracker podría, pero no es un requisito, devolver una respuesta compacta cuando se le solicite.

A los desarrolladores de nuevos clientes I2P se les anima fuertemente a implementar anuncios sobre su propio túnel en lugar de sobre el proxy del cliente HTTP en el puerto 4444. Hacerlo así es tanto más eficiente como a su vez permite al tracker aplicar destinos (vea debajo).

No hay clientes o trackers I2P conocidos que actualmente soporten anuncios/respuestas UDP.

Respuestas de tracker no-compactas

La respuesta no-compacta es como la del bittorrent estándar, con una "ip" I2P.

Los trackers generalmente incluyen un clave de puerto falsa, o usan el puerto del anuncio, por compatibilidad con anteriores clientes. Los clientes deben ignorar el parámetro port (puerto), y no deben solicitarlo.

El valor de la clave ip es la base 64 del Destino del cliente, como se describe arriba. Los trackers generalmente añaden ".i2p" al final del Destino Base 64 si no estaba en el ip del anuncio, por compatibilidad con anteriores clientes. Los clientes no deben solicitar un sufijo ".i2p" en las respuestas.

Otras claves y valores de respuesta son los mismos que en el bittorrent estandar.

Respuestas de tracker compactas

En la respuesta compacta, el valor de la clave de diccionario de los "peers" (pares) es una única cadena de bytes, cuya longitud es un múltiplo de 32 bytes. Esta cadena contiene los Hashes SHA-256 de 32-bytes concatenados del binario Destinos de los pares. Este `hash` (identificador único) debe calcularse por el tracker, a menos que use aplicación en destino (vea debajo), en cuyo caso el identificador (`hash`) entregado en las cabeceras HTTP X-I2P-DestHash o X-I2P-DestB32 puede ser convertido a binario y almacenado. La clave de los pares (`peers`) puede estar ausente, o el valor de los pares puede tener longitud-cero.

Aunque el soporte para respuesta compacta es opcional para ambos, clientes y trackers, es altamente recomendable ya que reduce el tamaño nominal de respuesta alrededor de un 90%.

Aplicación en destino

Algunos clientes de torrent de I2P, aunque no todos, anuncian sus propios túneles. Los trackers pueden elegir el prevenir engaños exigiéndolos, y verificando la Destinación de los clientes usando las cabeceras añadidas por el túnel servidor HTTP I2PTunnel. Las cabeceras son X-I2P-DestHash, X-I2P-DestB64, y X-I2P-DestB32, que son diferentes formatos para la misma información. Estas cabeceras no pueden ser falseadas por el cliente. Un tracker exigiendo destinaciones no necesita el parámetro de anuncio de la ip para nada.

Como varios clientes usan el proxy HTTP en lugar de sus propios túneles para los anuncios, la aplicación de destino (en el tracker) prevendrá su uso por aquellos clientes a menos que, o hasta que, aquellos clientes se reconviertan para anunciarse sobre sus propios túneles.

Desafortunadamente, al crecer la red, también lo hará la cantidad de maliciosidad, así que esperamos que en su momento todos los trackers apliquen los destinos. Ambos, desarrolladores de trackers y clientes deben anticiparlo.

Nombres de Servidor de Anuncio

Los nombres de servidor de URLs de anuncio en los archivos torrent siguen generalmente los estándares de nombres I2P. Además de los nombres de servidor de las libretas de direcciones y los nombre de servidor Base 32 ".b32.i2p", el Destino Base 64 completo (con [¿o sin?] sufijo ".i2p"] debe ser soportado. Los trackers no-abiertos deben reconocer sus propios nombres de servidor en cualquiera de estos formatos.

Para preservar el anonimato, los clientes por lo general deben ignorar URLs de anuncio no-I2P en los ficheros torrent.

Conexiones entre clientes

Las conexiones cliente-a-cliente usan el protocolo estándar sobre TCP. Actualmente no hay clientes I2P conocidos que soporten comunicación uTP (Protocol de Transporte utorrent).

I2P usa Destinos de 387+ bytes para direcciones, como se explicó arriba.

Si el cliente tiene sólo el identificador criptográfico (`hash`) del destino (como el de una respuesta compacta o el PEX (protocolo de Intercambio de Pares)), debe realizar una búsqueda codificándolo con Base 32, añadiendo el sufijo ".b32.i2p", y consultando en el Servicio de Nombres, que devolverá el Destino completo si está disponible.

Si el cliente tiene el Destino completo de un par (`peer`) que recibió en una respuesta no-compacta, debe usarlo directamente en el establecimiento de la conexión. No convierta un Destino de vuelta a un identificador criptográfico (`hash`) Base 32, esto es bastante ineficiente.

Prevención de redes-cruzadas.

Para preservar el anonimato, los clientes I2P bittorrent por lo general no soportan anuncios no-I2P, o conexiones de pares (`peers`). Los proxys al exterior (`outproxies`) HTTP de I2P con frecuencia bloquean anuncios. No hay proxys al exterior SOCKS conocidos que soporten tráfico bittorrent.

Para prevenir el uso por clientes no-I2P a través de un proxy hacia el interior (`inproxy`) HTTP, los trackers I2P a menudo bloquean accesos o anuncios que contengan una cabecera HTTP X-Forwarded-For. Los trackers deben rechazar anuncios de red estándar con IPs IPv4 o IPv6, y no entregarlos en las respuestas.

PEX

El PEX (protocolo de Intercambio de Pares) I2P está basado en ut_pex (utorrent PEX). Como no parece haber una especificación ut_pex formal disponible, puede ser necesario revisar el código fuente de libtorrent para obtener asistencia. Es un mensaje de extensión, identificado como "i2p_pex" en la extensión de toma de contacto (`handshake`). Contiene un diccionario b-codificado (`bencoded`) con hasta 3 claves, "added" (añadido), "added.f", y "dropped" (descartado). Los valores `added` y `dropped` son cada uno una única cadena de bytes, cuyo tamaño es un múltiplo de 32 bytes. Estas cadenas de bytes son los identificadores criptográficos ('hashes') SHA-256 concatenados del binario Destinos de los pares (`peers`). Este es el mismo formato que el de los valores de diccionario de los pares en el formato de respuesta compacta de I2P especificado arriba. Si está presente, el valor de added.f es el mismo que en ut_pex.

DHT

El soporte DHT (tabla de hash dinámica) está incluido en el cliente i2psnark desde la versión 0.9.2. Las diferencias preliminares con la BEP 5 (Propuesta de Mejora de Bittorrent 5) están descritas debajo, y están sujetas a cambios. Contacte con los desarrolladores de I2P si quiere desarrollar un cliente con soporte DHT.

Al contario que DHT (tabla de hash dinámica), I2P DHT no usa bit alguno en las opciones de toma de contacto (`handshake`), o en el mensaje PORT (puerto). Se anuncia con un mensaje de extensión, identificado como "i2p_dht" en la extensión handshake. Contiene un diccionario b-codificado (`bencoded`) con dos claves, "port" y "rport" (puerto de respuesta), ambos enteros.

The UDP (datagram) port listed in the compact node info is used to receive repliable (signed) datagrams. This is used for queries, except for announces. We call this the "query port". This is the "port" value from the extension message. Queries use I2CP protocol number 17.

In addition to that UDP port, we use a second datagram port equal to the query port + 1. This is used to receive unsigned (raw) datagrams for replies, errors, and announces. This port provides increased efficiency since replies contain tokens sent in the query, and need not be signed. We call this the "response port". This is the "rport" value from the extension message. It must be 1 + the query port. Responses and announces use I2CP protocol number 18.

La información compacta del par (`peer`) son 32 bytes (identificador criptográfico (`hash`) SHA256 de 32 bytes) en lugar de 4 bytes de IP + 2 bytes de puerto. No hay puerto del par. En una respuesta, la clave "values" (valores) es una lista de cadenas, conteniendo cada una la información compacta de un único par.

La información de nodo compacto son 54 bytes (20 bytes de hash SHA1 + 32 bytes de hash SHA256 + 2 bytes de puerto) en lugar de 20 bytes de hash SHA1 + 4 bytes de IP + 2 bytes de puerto. En una respuesta, la clave "nodes" (nodos) es una única cadena de bytes con la información concatenada de nodo compacto.

Requisito de identificador (`ID`) de nodo seguro: Para hacer más difíciles diferentes ataques DHT (tabla de hash distribuida) los primeros 4 bytes del identificador de nodo (`ID`) deben coincidir con los primeros 4 bytes del identificador criptográfico (`hash`) del destino, y los siguientes 2 bytes del identificador de nodo deben coincidir con los siguientes 2 bytes del resultado de la operación OR-exclusivo del hash del destino con el puerto.

En un fichero torrent, la clave "nodos" del diccionario de un torrent sin tracker ha de ser determinada. Podría ser una lista de cadenas binarias de 32 bytes (hashes SHA256) en lugar de una lista de listas que contengan una cadena de servidor y un valor entero de puerto. Alternativas: Una única cadena de bytes con hashes concatenados, o una lista de cadenas por si solas.

Trackers de datagramas (UDP)

Aún no está disponible para clientes y trackers (rastreadores bittorrent) el soporte para trackers UDP. Las diferencias preliminares con la (propuesta de mejora de bittorrent) BEP 15 están descritas debajo, y son susceptibles de cambiar. Contacte con los desarrolladores de I2P si desea desarrollar un cliente o un tracker que soporte anuncios sobre datagramas.

Un tracker UDP escucha en 2 puertos. El "puerto de petición" es el puerto publicitado, y se usa para recibir datagramas respondibles (firmados), únicamente para la solicitud de conexión. El "puerto de respuesta" se usa para recibir datagramas sin firmar (raw, en crudo), y es el puerto fuente para todas las respuestas. El puerto de respuesta es arbitrario. Un cliente envía y recibe exclusivamente en un único puerto. Únicamente recibe datagramas sin firmar (raw). Los datagramas raw proporcionan una mayor eficiencia para las respuestas, ya que contienen credenciales enviadas en la petición, y no necesitan estar firmados.

En la solicitud de anuncio, la IP de 4-bytes es reemplazada por un hash de 32-bytes, y el puerto todavía está presente, aunque puede ser ignorado por el tracker. En la respuesta de anuncio, cada IP de 4-bytes y puerto de 2-bytes, es reemplazado por un hash (información compacta del par) de 32-bytes, sin presentar ningún puerto. El cliente envía la solicitud de anuncio, y la solicitud de scrape (rascado, estadísticas del torrent) al puerto fuente del paquete de respuesta de anuncio. La petición de conexión, la respuesta de conexión, la petición de scrape, la respuesta de scrape, y la respuesta de error, son los mismos que en la (proposición de mejora de bittorrent) BEP 15.

Source addresses in I2P cannot be spoofed, so it is possible to use a simplified protocol with 2 packets instead of 4, omitting the connect request and response. In this case, the announce request would be a repliable datagram sent to the tracker's query port, and the tracker would not require a response port. While this is more efficient, it would be more difficult to modify an existing tracker to support this mode. The URL for the 4-packet-mode tracker would use standard "udp://" prefix. The URL for a modified 2-packet-mode tracker would require a different prefix if both modes are supported in I2P.

Información adicional