{% extends "_layout.html" %} {% block title %}I2NP{% endblock %} {% block content %}
The I2P Network Protocol (I2NP), which is sandwiched between I2CP and the various I2P transport protocols, manages the routing and mixing of messages between routers, as well as the selection of what transports to use when communicating with a peer for which there are multiple common transports supported.
While I2NP has been quite stable since its inception in August of 2003, there have been minor modifications on occasion. Here is the I2NP Protocol Specification Version 0.9 (pdf) dated August 28, 2003. Beware - based on a quick comparison with the code, there are substantial differences between the implementation and the 2003 specification.
I2NP Definition
Note - The following information is extracted from the current (2008) code base, however it may be incomplete and/or inaccurate. Check the code to be sure.
I2NP (I2P Network Protocol) messages can be used for one-hop, router-to-router, point-to-point messages. By encrypting and wrapping messages in other messages, they can be sent in a secure way through multiple hops to the ultimate destination. Priority is only used locally at the origin, i.e. when queueing for outbound delivery. Both the NTCP and UDP transports implement priority transmission, but in somewhat different manners.
Message Format:
Field | Bytes |
Unique ID | 4 |
Expiration | 8 |
Payload Length | 2 |
Checksum | 1 |
Payload | 0 - 64K |
Message Types: The following is taken from the code, however not all these messages may be used. Higher-numbered priority is higher priority. The majority of traffic is TunnelDataMessages (priority 400), so anything above 400 is essentially high priority, and anything below is low priority. Note also that many of the messages are generally routed through exploratory tunnels, not client tunnels, and therefore may not be in the same queue unless the first hops happen to be on the same peer.
Also, not all message types are sent unencrypted. For example, when testing a tunnel, the router wraps a DeliveryStatusMessage, which is wrapped in a GarlicMessage, which is wrapped in a DataMessage.
Message | Type | Payload Length | Priority | Comments |
DatabaseLookupMessage | 2 | 400 | ||
DatabaseSearchReplyMessage | 3 | 300 | ||
DatabaseStoreMessage | 1 | 100/400 | Usually 100 (why?) | |
DataMessage | 20 | 400 | ||
DateMessage | 16 | Obsolete (was used by TCP), date messages now at the I2CP layer ? | ||
DeliveryStatusMessage | 10 | 12 | Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage | |
GarlicMessage | 11 | Generally wrapped in a DataMessage | ||
TunnelBuildMessage | 21 | 4224 | 300/500 | Usually 500 (why?) |
TunnelBuildReplyMessage | 22 | 4224 | 300 | |
TunnelCreateMessage | 6 | Obsolete - Old Tunnel Build Method | ||
TunnelCreateStatusMessage | 7 | Obsolete - Old Tunnel Build Method | ||
TunnelDataMessage | 18 | 400 | ||
TunnelGatewayMessage | 19 | 300/400 | ||
Others listed in 2003 spec | 4,5,8,9,12 | Unused |