diff --git a/i2p2www/pages/site/docs/spec/i2np.html b/i2p2www/pages/site/docs/spec/i2np.html index ceae52c928f5e35e5c386a408379f16b2368aa88..64dfaf5fc76a1b77bca589b3a7845b2fded88c3f 100644 --- a/i2p2www/pages/site/docs/spec/i2np.html +++ b/i2p2www/pages/site/docs/spec/i2np.html @@ -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`