Skip navigation links


This package defines the low-level messages sent between routers, called the Invisible Internet Network Protocol (I2NP).

See: Description

Package Description

This package defines the low-level messages sent between routers, called the Invisible Internet Network Protocol (I2NP).

Not for use by apps, clients or plugins.

The Invisible Internet Network Protocol (I2NP) is only a part of how an application can send messages over the network. The Invisible Internet Client Protocol (I2CP) defines how client applications written in any language can communicate with the network routers. In addition, various transport protocols define the specifics of how data is passed from one router to another over the network. I2NP does not specify or require any particular transport layer, allowing transport protocols to work over TCP, Polling HTTP, SMTP+POP3/IMAP, UDP, among anything else that can pass data. I2NP merely requires that they:

Transports themselves can implement advanced features, such as steganography, constant rate delivery, dummy message delivery, and may even run on top of existing networks, such as mixminion, kazaa, gnunet, and freenet. Transports can even be written to run over I2P itself, accessing it as a client and mixing the message through other routers.

Sandwiched between I2CP and the various I2P transport protocols, I2NP manages the routing and mixing of messages between routers, as well as the selection of what

Destination Sends a Message

Following is a common usage for I2NP Messages. For other usages, including tunnel building, see the I2NP specification or the tunnel build document.

Whenever a Destination wants to send a message to to another Destination, it provides its local router with both the Destination structure and the raw bytes of the message to be sent. The router then determines where to send it, delivers it through outbound tunnels, instructing the end point to pass it along to the appropriate inbound tunnel, where it is passed along again to that tunnel's end point and made available to the target for reception. To understand fully, each step in the process must be explained in detail.

There are several important points of note in this scenario. First, the source router determines how many messages to send, how many outbound tunnels to send them out, how many inbound tunnels to send them to, and how many cloves should include DeliveryStatusMessage responses. The algorithm deciding these choices depends both on the router implementation as well as the Destination's session configuration options specified to balance the bandwidth, latency, reliability, and anonymity constraints. Also, instead of using outbound tunnels to get the message to the inbound tunnel's gateway, the router may decide to source router the message instead. If the message id for a clove has already been processed or its expiration has passed, the clove is dropped.

Skip navigation links