I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Prop. 159 MTU and RI block updates

Browse Source
This commit is contained in:
zzz
2022-02-06 10:24:58 -05:00
parent 0c356ba0fd
commit 313c8c4eff
1 changed files with 34 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
i2p2www/spec/proposals/159-ssu2.rst
View File

@ -128,6 +128,8 @@ Design Goals
- Avoid any year 2038 issues in timestamps, must work until at least 2106.
- Increase minimum MTU from 620 to 1280 for efficiency and ease of implementation.
- Maintain a max I2NP message size of approximately 32K, as in SSU.
Increase to 64 KB? TBD
@ -3835,6 +3837,7 @@ Notes
The simplest implementation may be to never include I2NP blocks in
the Session Confirmed message, and send all I2NP blocks in
subsequent Data messages.
See Router Info block section below for maximum block size.
KDF for data phase
@ -4383,10 +4386,33 @@ Notes:
Compression is recommended if it allows a Router Info to fit
in a single message without fragmentation.
- Maximum size of first or only fragment in the Session Confirmed message:
MTU - 113 for IPv4 or MTU - 133 for IPv6.
Assuming 1500 byte default MTU, and no other blocks in the message,
1387 for IPv4 or 1367 for IPv6.
97% of current router infos are smaller than 1367 witout gzipping.
99.9% of current router infos are smaller than 1367 when gzipped.
Assuming 1280 byte minimum MTU, and no other blocks in the message,
1167 for IPv4 or 1147 for IPv6.
94% of current router infos are smaller than 1147 witout gzipping.
97% of current router infos are smaller than 1147 when gzipped.
- Maximum size of a follow-on fragment in a Data message:
MTU - TBD for IPv4 or MTU - TBD for IPv6.
Assuming 1500 byte default MTU, and no other blocks in the message,
TBD for IPv4 or TBD for IPv6.
Assuming 1280 byte minimum MTU, and no other blocks in the message,
TBD for IPv4 or TBD for IPv6.
- If the Router Info is compressed AND fragmented,
the data is compressed first and then fragmented.
The fragments are not individually compressed.
- State machine handling and retransmission for a fragmented router info
in the handshake will be quite complex; it would be much easier
to simply require the router info to be unfragmented,
and avoid outbound SSU2 connections if the local router info is too large.
- Flooding must not be requested unless there are published
RouterAddresses in the RouterInfo. The receiving router
must not flood the RouterInfo unless there are published
@ -5563,20 +5589,24 @@ MTU
========
Requirements vary, based on whether the published address is shared with SSU 1.
Current SSU 1 IPv4 minimum is 620, which is probably too small.
Current SSU 1 IPv4 minimum is 620, which is definitely too small.
The minimum SSU2 MTU is 1280 for both IPv4 and IPv6,
which is the same as specified in [RFC-9000]_.
See below.
SSU Address
------------
Shared address with SSU 1, must follow SSU 1 rules.
IPv4: Default and max is 1484. Min is 620.
IPv4: Default and max is 1484. Min is 1292.
(IPv4 MTU + 4) must be a multiple of 16.
IPv6: Must be published, min is 1280 and the max is 1488.
IPv6 MTU must be a multiple of 16.
SSU2 Address
------------
Must follow SSU 1 rules.
IPv4: Default and max is 1500. Min is TBD.
IPv4: Default and max is 1500. Min is 1280.
IPv6: Default and max is 1500. Min is 1280.
No multiple of 16 rules, but should probably be a multiple of 2 at least.