From 313c8c4eff812627acb509d19e2dd3fbc623c0cc Mon Sep 17 00:00:00 2001 From: zzz Date: Sun, 6 Feb 2022 10:24:58 -0500 Subject: [PATCH] Prop. 159 MTU and RI block updates --- i2p2www/spec/proposals/159-ssu2.rst | 38 ++++++++++++++++++++++++++--- 1 file changed, 34 insertions(+), 4 deletions(-) diff --git a/i2p2www/spec/proposals/159-ssu2.rst b/i2p2www/spec/proposals/159-ssu2.rst index bf60cac5..9d4e0ac1 100644 --- a/i2p2www/spec/proposals/159-ssu2.rst +++ b/i2p2www/spec/proposals/159-ssu2.rst @@ -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.