i2p.www/www.i2p2/pages/i2np.html

{% extends "_layout.html" %}
{% block title %}I2NP{% endblock %}
{% block content %}
<h2>I2P Network Protocol (I2NP)</h2>
<p>
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.
</p>

<p>While I2NP has been quite stable since its inception in
August of 2003, there have been minor modifications on occasion.
Here is the
<a href="/_static/pdf/I2NP_spec.pdf">I2NP Protocol Specification Version 0.9</a>
(pdf) dated August 28, 2003.
That document also references the
<a href="/_static/pdf/datastructures.pdf">Common Data Structures Specification Version 0.9</a>.
Beware -
based on a quick comparison with the code, there are substantial differences
between the implementation and the 2003 specifications.
</p>

<h3>I2NP Definition</h3>
<p>
<i>Note</i> - 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.
<p>
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.
<p>
Both the NTCP and UDP transports implement priority transmission,
but in quite different manners.
UDP has complex code with queues for each priority, however it treats
messages with priorities 400-499, for example, the same.
(The priority queues are 100, 200, 300, 400, 500, and 1000)
These are global queues for all peers.
NTCP has a trivial linear search for the highest priority within
each buffer for a particular peer.
This is much less effective.
<p>
It isn't clear whether the current priority scheme is generally effective,
and whether the priorities for various messages should be adjusted further.
This is a topic for further research, analysis and testing.


<h3>Message Format</h3>
<p>

<table border=1>
<tr><td>Field<td>Bytes
<tr><td>Unique ID<td>4
<tr><td>Expiration<td>8
<tr><td>Payload Length<td>2
<tr><td>Checksum<td>1
<tr><td>Payload<td>0 - 64K
</table>

<p>
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.
<p>
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.
<p>


<table border=1>
<tr><td>Message<td>Type<td>Payload Length<td>Priority<td>Comments
<tr><td>
DatabaseLookupMessage
<td align=right>2
<td>&nbsp;
<td align=right>100/400
<td>400 normally; 100 if from HarvesterJob and sent directly;
400 for a router lookup
<tr><td>
DatabaseSearchReplyMessage
<td align=right>3
<td align=right>Typ. 161
<td align=right>300
<td>Size is 65 + 32*(number of hashes) where typically, the hashes for
three floodfill routers are returned.
<tr><td>
DatabaseStoreMessage
<td align=right>1
<td align=right>Varies
<td align=right>100/400
<td>Usually 100 (why?)
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
as we appproach release 1.0.
<tr><td>
DataMessage
<td align=right>20
<td align=right>4 - 65540
<td align=right>400
<tr><td>
DateMessage
<td align=right>16
<td>&nbsp;
<td>&nbsp;
<td>Obsolete (was used by TCP), date messages now at the <a href="i2cp.html">I2CP</a> layer ?
<tr><td>
DeliveryStatusMessage
<td align=right>10
<td align=right>12
<td>&nbsp;
<td>Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage
<tr><td>
<a href="techintro.html#op.garlic">GarlicMessage</a>
<td align=right>11
<td>&nbsp;
<td>&nbsp;
<td>Generally wrapped in a DataMessage -
but when unwrapped, given a priority of 100 by the forwarding router
<tr><td>
<a href="tunnel-alt-creation.html#tunnelCreate.requestRecord">TunnelBuildMessage</a>
<td align=right>21
<td align=right>4224
<td align=right>300/500
<td>Usually 500 (why?)
<tr><td>
<a href="tunnel-alt-creation.html#tunnelCreate.replyRecord">TunnelBuildReplyMessage</a>
<td align=right>22
<td align=right>4224
<td align=right>300
<tr><td>
TunnelCreateMessage
<td align=right>6
<td>&nbsp;
<td>&nbsp;
<td>Obsolete - <a href="tunnel.html#tunnel.request">Old Tunnel Build Method</a>
<tr><td>
TunnelCreateStatusMessage
<td align=right>7
<td>&nbsp;
<td>&nbsp;
<td>Obsolete - <a href="tunnel.html#tunnel.request">Old Tunnel Build Method</a>
<tr><td>
TunnelDataMessage
<td align=right>18
<td align=right>1028
<td align=right>400
<td>The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways will
    be reduced to 200 as of release 0.6.1.33.
    Outbound gateway messages (i.e. those originated locally) will remain at 400.
<tr><td>
TunnelGatewayMessage
<td align=right>19
<td>&nbsp;
<td align=right>300/400
<tr><td>
Others listed in 2003 spec
<td>4,5,8,9,12
<td>&nbsp;
<td>&nbsp;
<td>Unused
</table>

{% endblock %}