Visão Geral
O Protocolo de Rede I2P (I2NP), que fica entre o I2CP e os vários protocolos de transporte do I2P, gerencia o roteamento e a mistura de mensagens entre roteadores, bem como a seleção dos transportes a serem usados ao se comunicar com um par quando há vários transportes comuns suportados.
Definição de I2NP
As mensagens I2NP (I2P Network Protocol) podem ser usadas para mensagens ponto-a-ponto, de roteador para roteador, com um único salto. Ao criptografar e encapsular mensagens dentro de outras mensagens, elas podem ser enviadas de forma segura através de múltiplos saltos até o destino final. A prioridade é usada apenas localmente na origem, ou seja, durante o enfileiramento para entrega de saída.
As prioridades listadas abaixo podem não estar atualizadas e estão sujeitas a alterações. A implementação da fila de prioridades pode variar.
Formato da Mensagem
A tabela a seguir especifica o cabeçalho tradicional de 16 bytes usado no NTCP. Os transportes SSU e NTCP2 utilizam cabeçalhos modificados.
| Field | Bytes |
|---|---|
| Type | 1 |
| Unique ID | 4 |
| Expiration | 8 |
| Payload Length | 2 |
| Checksum | 1 |
| Payload | 0 - 61.2KB |
O número máximo de fragmentos é 64, e a mensagem pode não ser perfeitamente alinhada, portanto, a mensagem deve caber nominalmente em 63 fragmentos.
O tamanho máximo de um fragmento inicial é de 956 bytes (assumindo o modo de entrega TUNNEL); o tamanho máximo de um fragmento subsequente é de 996 bytes. Portanto, o tamanho máximo é aproximadamente 956 + (62 * 996) = 62708 bytes, ou 61,2 KB.
Além disso, os transportes podem ter restrições adicionais. O limite do NTCP é de 16KB - 6 = 16378 bytes. O limite do SSU é de aproximadamente 32 KB. O limite do NTCP2 é de aproximadamente 64KB - 20 = 65516 bytes, o que é maior do que o que um túnel pode suportar.
Observe que esses não são os limites para datagramas vistos pelo cliente, pois o roteador pode agrupar um leaseset de resposta e/ou tags de sessão junto com a mensagem do cliente em uma mensagem garlic. O leaseset e as tags juntos podem adicionar cerca de 5,5 KB. Portanto, o limite atual de datagrama é de cerca de 10 KB. Esse limite será aumentado em uma versão futura.
Tipos de Mensagem
Quanto maior o número da prioridade, maior é a prioridade. A maioria do tráfego é composta por TunnelDataMessages (prioridade 400), portanto qualquer valor acima de 400 é essencialmente alta prioridade, e qualquer valor abaixo é baixa prioridade. Observe também que muitas das mensagens geralmente são roteadas através de túneis exploratórios, não túneis de cliente, e por isso podem não estar na mesma fila, a menos que os primeiros saltos aconteçam de estar no mesmo par.
Além disso, nem todos os tipos de mensagens são enviados sem criptografia. Por exemplo, ao testar um túnel, o roteador encapsula uma DeliveryStatusMessage, que é encapsulada em uma GarlicMessage, que por sua vez é encapsulada em uma 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 |
Consulte a página de especificação do I2NP para a especificação completa do protocolo. Consulte também a página de especificação de estruturas de dados comuns .
Trabalhos Futuros
Não está claro se o esquema de prioridade atual é geralmente eficaz, nem se as prioridades para as diversas mensagens devem ser ajustadas ainda mais. Este é um tema para pesquisas, análises e testes adicionais.