Resumen
El Protocolo de Red I2P (I2NP), que se encuentra entre I2CP y los diversos protocolos de transporte de I2P, gestiona el enrutamiento y mezclado de mensajes entre routers, así como la selección de qué transportes utilizar al comunicarse con un par cuando hay múltiples transportes comunes soportados.
Definición de I2NP
Los mensajes I2NP (I2P Network Protocol) pueden usarse para mensajes de un solo salto, de router a router, punto a punto. Al cifrar y encapsular mensajes dentro de otros mensajes, pueden enviarse de forma segura a través de múltiples saltos hasta el destino final. La prioridad solo se utiliza localmente en el origen, es decir, al encolar para entrega saliente.
Las prioridades enumeradas a continuación pueden no estar actualizadas y están sujetas a cambios. La implementación de la cola de prioridades puede variar.
Formato del mensaje
La siguiente tabla especifica el encabezado tradicional de 16 bytes utilizado en NTCP. Los transportes SSU y NTCP2 utilizan encabezados modificados.
| Field | Bytes |
|---|---|
| Type | 1 |
| Unique ID | 4 |
| Expiration | 8 |
| Payload Length | 2 |
| Checksum | 1 |
| Payload | 0 - 61.2KB |
El número máximo de fragmentos es 64, y es posible que el mensaje no esté perfectamente alineado, por lo que el mensaje debe caber nominalmente en 63 fragmentos.
El tamaño máximo de un fragmento inicial es de 956 bytes (suponiendo el modo de entrega TUNNEL); el tamaño máximo de un fragmento subsiguiente es de 996 bytes. Por lo tanto, el tamaño máximo es aproximadamente 956 + (62 * 996) = 62708 bytes, o 61,2 KB.
Además, los transportes pueden tener restricciones adicionales. El límite de NTCP es de 16 KB - 6 = 16378 bytes. El límite de SSU es aproximadamente 32 KB. El límite de NTCP2 es aproximadamente 64 KB - 20 = 65516 bytes, que es superior a lo que un túnel puede soportar.
Tenga en cuenta que estos no son los límites para los datagramas que ve el cliente, ya que el router puede agrupar un leaseset de respuesta y/o etiquetas de sesión junto con el mensaje del cliente en un mensaje de ajo (garlic message). El leaseset y las etiquetas juntos pueden sumar aproximadamente 5,5 KB. Por lo tanto, el límite actual de datagrama es de unos 10 KB. Este límite se aumentará en una versión futura.
Tipos de mensajes
Un número mayor de prioridad indica una prioridad más alta. La mayoría del tráfico corresponde a TunnelDataMessages (prioridad 400), por lo que cualquier valor por encima de 400 es esencialmente alta prioridad, y cualquier valor por debajo es baja prioridad. Tenga en cuenta también que muchos de los mensajes generalmente se enrutan a través de túneles exploratorios, no túneles de cliente, y por lo tanto pueden no estar en la misma cola a menos que los primeros saltos ocurran en el mismo par.
Además, no todos los tipos de mensajes se envían sin cifrar. Por ejemplo, al probar un túnel, el router encapsula un DeliveryStatusMessage, que a su vez se encapsula en un GarlicMessage, el cual se encapsula en un DataMessage.
| Message | Type | Payload Length | Priority | Comments |
|---|---|---|---|---|
| DatabaseLookupMessage | 2 | 500 | May vary | |
| DatabaseSearchReplyMessage | 3 | Typ. 161 | 300 | Size is 65 + 32*(number of hashes) where typically, the hashes for three floodfill routers are returned. |
| DatabaseStoreMessage | 1 | Varies | 460 | Priority may vary. Size is 898 bytes for a typical 2-lease leaseSet. RouterInfo structures are compressed, and size varies; however there is a continuing effort to reduce the amount of data published in a RouterInfo. |
| DataMessage | 20 | 4 - 62080 | 425 | Priority may vary on a per-destination basis |
| DeliveryStatusMessage | 10 | 12 | Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage | |
| GarlicMessage | 11 | Generally wrapped in a DataMessage - but when unwrapped, given a priority of 100 by the forwarding router | ||
| TunnelBuildMessage | 21 | 4224 | 500 | |
| TunnelBuildReplyMessage | 22 | 4224 | 300 | |
| TunnelDataMessage | 18 | 1028 | 400 | The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways was reduced to 200 as of release 0.6.1.33. Outbound gateway messages (i.e. those originated locally) remains at 400. |
| TunnelGatewayMessage | 19 | 300/400 | ||
| VariableTunnelBuildMessage | 23 | 1057 - 4225 | 500 | Shorter TunnelBuildMessage as of 0.7.12 |
| VariableTunnelBuildReplyMessage | 24 | 1057 - 4225 | 300 | Shorter TunnelBuildReplyMessage as of 0.7.12 |
| Others (Types 0, 4-9, 12) | 0, 4-9, 12 | Obsolete, Unused |
Consulta la página de Especificación I2NP para obtener la especificación completa del protocolo. Consulta también la página de Especificación de Estructuras de Datos Comunes .
Trabajo Futuro
No está claro si el esquema de prioridades actual es generalmente efectivo, ni si las prioridades para los diversos mensajes deberían ajustarse más. Este es un tema para investigación, análisis y pruebas adicionales.