forked from I2P_Developers/i2p.www
I2NP and SSU updates and clarifications
This commit is contained in:
@ -1,7 +1,9 @@
|
||||
{% extends "_layout.html" %}
|
||||
{% block title %}I2NP Specification{% endblock %}
|
||||
{% block content %}
|
||||
Updated October 2011, current as of router version 0.8.10
|
||||
|
||||
Updated December 2011, current as of router version 0.8.11
|
||||
|
||||
<h1>I2P Network Protocol (I2NP) Specification</h1>
|
||||
<p>
|
||||
The I2P Network Protocol (I2NP),
|
||||
@ -22,17 +24,29 @@ common transports supported.
|
||||
</p>
|
||||
<h4>Contents</h4>
|
||||
<p>
|
||||
1 byte <a href="common_structures_spec#type_Integer">Integer</a> specifying the type of this message, followed by an 4 byte <a href="common_structures_spec#type_Integer">Integer</a> specifying the message-id. After that there is an expiration <a href="common_structures_spec#type_Date">Date</a>, followed by an 2 byte <a href="common_structures_spec#type_Integer">Integer</a> specifying the length of the message payload, followed by an <a href="common_structures_spec#type_Hash">Hash</a>, which is truncated to the first byte. After that the actual message data follows.
|
||||
1 byte <a href="common_structures_spec#type_Integer">Integer</a> specifying the type of this message,
|
||||
followed by a 4 byte <a href="common_structures_spec#type_Integer">Integer</a> specifying the message-id.
|
||||
After that there is an expiration <a href="common_structures_spec#type_Date">Date</a>,
|
||||
followed by a 2 byte <a href="common_structures_spec#type_Integer">Integer</a> specifying
|
||||
the length of the message payload, followed by a <a href="common_structures_spec#type_Hash">Hash</a>,
|
||||
which is truncated to the first byte. After that the actual message data follows.
|
||||
</p>
|
||||
<pre>
|
||||
{% filter escape %}
|
||||
Standard (16 bytes):
|
||||
|
||||
+----+----+----+----+----+----+----+----+
|
||||
|type| msg-id | expiration
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| size |chks|
|
||||
+----+----+----+----+----+----+----+----+
|
||||
|
||||
Short (SSU, 5 bytes):
|
||||
|
||||
+----+----+----+----+----+
|
||||
|type| msg-id |
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| expiration |
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| size |chks|
|
||||
+----+----+----+
|
||||
|type| short expiration |
|
||||
+----+----+----+----+----+
|
||||
|
||||
{% endfilter %}
|
||||
</pre>
|
||||
|
||||
@ -53,12 +67,16 @@ expiration :: Date
|
||||
8 bytes
|
||||
date this message will expire
|
||||
|
||||
short expiration :: Integer
|
||||
4 bytes
|
||||
date this message will expire (seconds since the epoch)
|
||||
|
||||
size :: Integer
|
||||
length -> 2 bytes
|
||||
|
||||
purpose -> length of the payload
|
||||
|
||||
chks :: Hash
|
||||
chks :: Integer
|
||||
length -> 1 byte
|
||||
|
||||
purpose -> checksum of the payload
|
||||
@ -70,6 +88,16 @@ data :: Data
|
||||
purpose -> actual message contents
|
||||
{% endfilter %}
|
||||
</pre>
|
||||
<h4>Notes</h4>
|
||||
<ul><li>
|
||||
When transmitted over <a href="udp.html">SSU</a>,
|
||||
the 16-byte standard header is not used.
|
||||
Only a 1-byte type and a 4-byte expiration in seconds is included.
|
||||
The message id and size are
|
||||
incorporated into various parts of the SSU data packet format.
|
||||
The checksum is not required since errors are caught in decryption.
|
||||
</li></ul>
|
||||
|
||||
|
||||
<h3 id="struct_BuildRequestRecord">BuildRequestRecord</h3>
|
||||
<h4>Description</h4>
|
||||
@ -809,6 +837,12 @@ data:
|
||||
{% endfilter %}
|
||||
</pre>
|
||||
|
||||
<h4>Notes</h4>
|
||||
<ul>
|
||||
<li>
|
||||
The payload is an I2NP message with a standard 16-byte header.
|
||||
</ul>
|
||||
|
||||
|
||||
<h3 id="msg_Data">Data</h3>
|
||||
<h4>Description</h4>
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
{% block title %}SSU Transport{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
Updated November 2011 for release 0.8.11
|
||||
Updated December 2011 for release 0.8.12
|
||||
|
||||
<h1>Secure Semireliable UDP (SSU)</h1>
|
||||
<p>
|
||||
@ -62,24 +62,35 @@ a packet and sends it off (careful not to exceed the MTU).
|
||||
|
||||
<h3><a name="mtu">MTU</a></h3>
|
||||
<p>
|
||||
The current implementation uses two MTU values: 608 and 1492.
|
||||
As of router version 0.8.12,
|
||||
two MTU values are used: 620 and 1488.
|
||||
The MTU value is adjusted based on the percentage of packets that are retransmitted.
|
||||
</p><p>
|
||||
596 gives us 588 IP bytes, 568 UDP bytes, and with an SSU data message,
|
||||
522 fragment bytes, which is enough to send a tunnel data message in 2
|
||||
packets. A tunnel data message sent over the wire is 1044 bytes, meaning
|
||||
we need 522 fragment bytes to fit it in 2 packets - add 46 for SSU, 20
|
||||
for UDP, and 8 for IP, giving us 596. Round up to mod 16, giving a total
|
||||
of 608.
|
||||
For both MTU values, it is desirable that (MTU % 16) == 12, so that
|
||||
the payload portion after the 28-byte IP/UDP header is a multiple of
|
||||
16 bytes, for encryption purposes.
|
||||
This calculation is for IPv4 only. While the protocol as specified supports IPv6
|
||||
addresses, IPv6 is not yet implemented.
|
||||
</p><p>
|
||||
For the small MTU value, it is desirable to pack a 2646-byte
|
||||
Variable Tunnel Build Message efficiently into multiple packets;
|
||||
with a 620-byte MTU, it fits into 5 packets with nicely.
|
||||
</p><p>
|
||||
Based on measurements, 1492 fits nearly all reasonably small I2NP messages
|
||||
(larger I2NP messages may be up to 1900 to 4500 bytes, which isn't going to fit
|
||||
into a live network MTU anyway).
|
||||
</p><p>
|
||||
The MTU values were 608 and 1492 for releases 0.8.9 - 0.8.11.
|
||||
The large MTU was 1350 prior to release 0.8.9.
|
||||
</p><p>
|
||||
The maximum receive packet size
|
||||
is 1571 bytes as of release 0.8.12.
|
||||
For releases 0.8.9 - 0.8.11 it was 1535 bytes.
|
||||
Prior to release 0.8.9 it was 2048 bytes.
|
||||
|
||||
</p>
|
||||
|
||||
<h3><ajname="max">Message Size Limits</a></h3>
|
||||
<h3><a name="max">Message Size Limits</a></h3>
|
||||
<p>
|
||||
While the maximum message size is nominally 32KB, the practical
|
||||
limit differs. The protocol limits the number of fragments to 7 bits, or 128.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
{% block title %}SSU Protocol Specification{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
Updated August 2011 for release 0.8.9
|
||||
Updated December 2011 for release 0.8.11
|
||||
|
||||
<p>
|
||||
<a href="udp.html">See the SSU page for an overview of the SSU transport</a>.
|
||||
@ -669,7 +669,8 @@ byte 1
|
||||
|
||||
<h4>Notes</h4>
|
||||
<ul><li>
|
||||
IP address is always 4 bytes in the current implementation.
|
||||
The current implementation adds a limited number of duplicate acks for
|
||||
messages previously acked, if space is available.
|
||||
</li><li>
|
||||
If the number of fragments is zero, this is an ack-only or keepalive message.
|
||||
</li><li>
|
||||
@ -681,6 +682,19 @@ Extended data is unimplemented and never present.
|
||||
</li><li>
|
||||
The current implementation does not pack multiple fragments into a single packet;
|
||||
the number of fragments is always 0 or 1.
|
||||
</li><li>
|
||||
Take care not to exceed the maximum MTU even if there is a large number of
|
||||
ACKs to send.
|
||||
</li><li>
|
||||
The protocol allows zero-length fragments but there's no reason to send them.
|
||||
</li><li>
|
||||
In SSU, the data uses a short 5-byte I2NP header followed by the payload
|
||||
of the I2NP message instead of the standard 16-byte I2NP header.
|
||||
The short I2NP header consists only of
|
||||
the one-byte I2NP type and 4-byte expiration in seconds.
|
||||
The I2NP message ID is used as the message ID for the fragment.
|
||||
The I2NP size is assembled from the fragment sizes.
|
||||
The I2NP checksum is not required as UDP message integrity is ensured by decryption.
|
||||
</li></ul>
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user