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.

Para recibir datagramas respondibles (firmados) se usa el puerto UDP (Protocolo de Datagrama de Usuario) listado en la información del nodo compacto. Este se usa para consultas, excepto para anuncios. Le llamamos el "query port" (puerto de consulta). Es el valor "port" (puerto) del mensaje de extensión. Las consultas usan el protocolo I2CP (Protocolo de Cliente I2P) número 17.

Además de ese puerto UDP, usamos un segundo puerto de datagrama igual al puerto de consulta + 1. Esto se usa para recibir datagramas no firmados (raw (crudos)) para las respuestas, errores, y anuncios. Este puerto proporciona una eficiencia aumentada ya que las respuestas contienen las credenciales (`tokens`) enviadas en la consulta, y no necesitan ser firmadas. Llamamos a esto el "response port" (puerto de respuesta). Este es el valor "rport" del mensaje de extensión. Las respuestas y los anuncios usan el protocolo I2CP número 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.

Las direcciones fuente en I2P no pueden ser falsificadas, así que es posible usar un protocolo simplificado con 2 paquetes en lugar de 4, omitiendo la solicitud y la respuesta de conexión. En este caso, la solicitud de anuncio sería un datagrama respondible enviado al puerto de petición del tracker, y el tracker no requeriría un puerto de respuesta. Aunque esto es más eficiente, sería más difícil modificar un tracker existente para que soportara este modo. La URL para el tracker en modo-de-4-paquetes usaría el prefijo estandar "udp://". La URL para un tracker modificado en modo-de-2-paquetes requeriría un prefijo diferente si ambos modos están soportados en I2P.

Información adicional