Aperçu
Le protocole réseau I2P (I2NP), qui se situe entre I2CP et les différents protocoles de transport I2P, gère le routage et le mélange des messages entre les routeurs, ainsi que la sélection des transports à utiliser lors de la communication avec un pair pour lequel plusieurs transports communs sont pris en charge.
Définition d’I2NP
Les messages I2NP (I2P Network Protocol) peuvent être utilisés pour des messages point à point d’un seul saut, d’un routeur à un autre. En chiffrant et en encapsulant des messages dans d’autres messages, ils peuvent être envoyés de manière sécurisée à travers plusieurs sauts jusqu’à leur destination finale. La priorité n’est utilisée qu’au niveau local à l’origine, c’est-à-dire lors de la mise en file d’attente pour la remise sortante.
Les priorités énumérées ci-dessous peuvent ne pas être à jour et sont sujettes à modification. La mise en œuvre de la file d’attente par priorité peut varier.
Format du message
Le tableau suivant spécifie l’en-tête traditionnel de 16 octets utilisé dans NTCP. Les transports SSU et NTCP2 utilisent des en-têtes modifiés.
| Field | Bytes |
|---|---|
| Type | 1 |
| Unique ID | 4 |
| Expiration | 8 |
| Payload Length | 2 |
| Checksum | 1 |
| Payload | 0 - 61.2KB |
Le nombre maximal de fragments est de 64, et le message peut ne pas être parfaitement aligné, donc le message doit idéalement tenir dans 63 fragments.
La taille maximale d’un fragment initial est de 956 octets (en supposant le mode de livraison TUNNEL) ; la taille maximale d’un fragment suivant est de 996 octets. Par conséquent, la taille maximale est d’environ 956 + (62 × 996) = 62708 octets, soit 61,2 Ko.
De plus, les protocoles de transport peuvent avoir des restrictions supplémentaires. La limite NTCP est de 16 Ko - 6 = 16378 octets. La limite SSU est d’environ 32 Ko. La limite NTCP2 est d’environ 64 Ko - 20 = 65516 octets, ce qui est supérieur à ce qu’un tunnel peut supporter.
Notez que ce ne sont pas les limites pour les datagrammes perçus par le client, car le routeur peut regrouper un jeu de baux de réponse et/ou des étiquettes de session avec le message du client dans un message aux multiples couches (garlic message). Le jeu de baux et les étiquettes peuvent ensemble ajouter environ 5,5 Ko. Par conséquent, la limite actuelle pour les datagrammes est d’environ 10 Ko. Cette limite sera augmentée dans une prochaine version.
Types de messages
Une priorité numérotée plus élevée correspond à une priorité plus élevée. La majorité du trafic est constituée de TunnelDataMessages (priorité 400), donc tout ce qui est au-dessus de 400 est essentiellement une priorité élevée, et tout ce qui est en dessous est une priorité faible. Notez également que bon nombre de messages sont généralement acheminés via des tunnels exploratoires, et non des tunnels clients, et peuvent donc ne pas se trouver dans la même file d’attente, sauf si les premiers sauts se trouvent par hasard sur le même pair.
En outre, tous les types de messages ne sont pas envoyés non chiffrés. Par exemple, lors du test d’un tunnel, le routeur encapsule un DeliveryStatusMessage, qui est lui-même encapsulé dans un GarlicMessage, lequel est encapsulé dans 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 |
Voir la page de spécification I2NP pour la spécification complète du protocole. Voir également la page de spécification des structures de données communes .
Travaux futurs
Il n’est pas clair si le schéma de priorité actuel est généralement efficace, ni si les priorités pour les différents messages devraient être davantage ajustées. Il s’agit d’un sujet nécessitant des recherches, des analyses et des tests supplémentaires.