kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

new I2NP version table

Browse Source
This commit is contained in:
zzz
2014-09-03 20:19:52 +00:00
parent d93c494de6
commit 463051b98b
1 changed files with 73 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
i2p2www/pages/site/docs/spec/i2np.html
View File

@@ -11,6 +11,77 @@ transports to use when communicating with a peer for which there are multiple
common transports supported.
</p>
<h2 id="versions">Protocol Versions</h2>
<p>
All routers must publish their I2NP protocol version in the "router.version" field in the RouterInfo properties.
This version field indicates their level of support for various I2NP protocol features,
and is not necessarily the actual router version.
</p><p>
If alternative (non-Java) routers
wish to publish any version information about the actual router implementation,
they must do so in another property.
Versions other than those listed below are allowed. Support will be
determined through a numeric comparison; for example, 0.9.13 implies support for 0.9.12 features.
Note that the "coreVersion" property is not used for determination of the I2NP protocol version.
</p><p>
A basic summary of the I2NP protocol versions is as follows. For details, see below.
<table border=1>
<tr>
<th>Version</th>
<th>Required I2NP Features</th>
</tr><tr>
<td align="center">0.9.16</td>
<td align="left">RI key certs / ECDSA and EdDSA sig types<br>
Note: RSA sig types also supported as of this version, but currently unused<br>
DLM lookup types (DLM flag bits 3-2) (proposed)
</td>
</tr><tr>
<td align="center">0.9.15</td>
<td align="left">Dest/LS key certs w/ EdDSA Ed25519 sig type (if floodfill)</td>
</tr><tr>
<td align="center">0.9.12</td>
<td align="left">Dest/LS key certs w/ ECDSA P-256, P-384, and P-521 sig types (if floodfill)<br>
Note: RSA sig types also supported as of this version, but currently unused<br>
Nonzero expiration allowed in RouterAddress
</td>
</tr><tr>
<td align="center">0.9.7</td>
<td align="left">Encrypted DSM/DSRM replies supported (DLM flag bit 1) (if floodfill)</td>
</tr><tr>
<td align="center">0.9.6</td>
<td align="left">Nonzero DLM flag bits 7-1 allowed</td>
</tr><tr>
<td align="center">0.9.3</td>
<td align="left">Requires zero expiration in RouterAddress</td>
</tr><tr>
<td align="center">0.9</td>
<td align="left">Supports up to 16 leases in a DSM LS store (6 previously)</td>
</tr><tr>
<td align="center">0.7.12</td>
<td align="left">VTBM and VTBRM message support</td>
</tr><tr>
<td align="center">0.7.10</td>
<td align="left">Floodfill supports encrypted DSM stores</td>
</tr><tr>
<td align="center">0.7.9 or lower</td>
<td align="left">All messages and features not listed above</td>
</tr><tr>
<td align="center">0.6.1.10</td>
<td align="left">TBM and TBRM messages introduced<br>
Minimum version compatible with current network
</td>
</tr>
</table>
</p><p>
Note that there are also transport-related features and compatibility issues;
see the NTCP and SSU transport documentation for details.
</p>
<h2 id="structures">Common structures</h2>
The following structures are elements of multiple I2NP messages.
They are not complete messages.
@@ -1115,7 +1186,8 @@ same format as `TunnelBuild` message, with `BuildResponseRecords`
<h4>Definition</h4>
<pre>
Same format as TunnelBuildMessage, except for the addition of an "num" field in front and $num number of Build Request Records instead of 8
Same format as TunnelBuildMessage, except for the addition of an "num" field in front
and $num number of Build Request Records instead of 8
num ::
1 byte `Integer`