diff --git a/i2p2www/spec/proposals/158-ipv6-transport-enhancements.rst b/i2p2www/spec/proposals/158-ipv6-transport-enhancements.rst new file mode 100644 index 00000000..10b2f481 --- /dev/null +++ b/i2p2www/spec/proposals/158-ipv6-transport-enhancements.rst @@ -0,0 +1,316 @@ +================= +IPv6 Peer Testing +================= +.. meta:: + :author: zzz, orignal + :created: 2021-03-19 + :thread: http://zzz.i2p/topics/3060 + :lastupdated: 2021-03-19 + :status: Open + :target: 0.9.50 + +.. contents:: + + +Overview +======== + +This proposal is to implement enhancements to the SSU and NTCP2 transports for IPv6. + + +Motivation +========== + +As IPv6 grows around the world and IPv6-only setups (especially on mobile) becomes more common, +we need to improve our support for IPv6 and remove the assumptions that +all routers are IPv4-capable. + + + +Connectivity Checking +----------------------- + +When selecting peers for tunnels, or selecting OBEP/IBGW paths for routing messages, +it helps to calculate whether router A can connect to router B. +In general, this means determining if A has outbound capability for a transport and address type (IPv4/v6) +that matches one of B's advertised inbound addresses. + +However, in many cases we don't know A's capabilites and have to make assumptions. +If A is hidden or firewalled, the addresses are not published, and we don't have direct knowledge - +so we assume it's IPv4 capable, and not IPv6 capable. +The solution is adding two new "caps" or capabilities to the Router Info to indicate outbound capability for IPv4 and IPv6. + + +IPv6 Introducers +---------------------------------- + +Our specifications [SSU]_ and [SSU-SPEC]_ contain errors and inconsistencies about whether +IPv6 introducers are supported for IPv4 introductions. +In any case, this has never been implemented in either Java I2P or i2pd. +This needs to be corrected. + + +IPv6 Introdutions +---------------------------------- + +Our specifications [SSU]_ and [SSU-SPEC]_ make clear that +IPv6 introductions are not supported. +This was under the assumption that IPv6 is never firewalled. +This is clearly not true, and we need to improve support for firewalled IPv6 routers. + + +Introduction Diagrams +------------------------- + +Legend: ----- is IPv4, ====== is IPv6 + +Current IPv4-only: + +.. raw:: html + + {% highlight %} + Alice Bob Charlie + RelayRequest ----------------------> + <-------------- RelayResponse RelayIntro -----------> + <-------------------------------------------- HolePunch + SessionRequest --------------------------------------------> + <-------------------------------------------- SessionCreated + SessionConfirmed ------------------------------------------> + Data <--------------------------------------------------> Data +{% endhighlight %} + + +IPv4 introduction, IPv6 introducer + +.. raw:: html + + {% highlight %} +Alice Bob Charlie + RelayRequest ======================> + <============== RelayResponse RelayIntro -----------> + <-------------------------------------------- HolePunch + SessionRequest --------------------------------------------> + <-------------------------------------------- SessionCreated + SessionConfirmed ------------------------------------------> + Data <--------------------------------------------------> Data +{% endhighlight %} + +IPv6 introduction, IPv6 introducer + + +.. raw:: html + + {% highlight %} +Alice Bob Charlie + RelayRequest ======================> + <============== RelayResponse RelayIntro ===========> + <============================================ HolePunch + SessionRequest ============================================> + <============================================ SessionCreated + SessionConfirmed ==========================================> + Data <==================================================> Data +{% endhighlight %} + +IPv6 introduction, IPv4 introducer + +.. raw:: html + + {% highlight %} +Alice Bob Charlie + RelayRequest ----------------------> + <-------------- RelayResponse RelayIntro ===========> + <============================================ HolePunch + SessionRequest ============================================> + <============================================ SessionCreated + SessionConfirmed ==========================================> + Data <==================================================> Data +{% endhighlight %} + + +Design +====== + +There are three changes to be implemented. + +- Add "4" and "6" capabilities to Router Address capabilities to indicate outbound IPv4 and IPv6 support +- Add support for IPv4 introductions via IPv6 introducers +- Add support for IPv6 introductions via IPv4 and IPv6 introducers + + + +Specification +============= + +4/6 Caps +-------- + +See also [CAPS]_. + + +Two new capabilities "4" and "6" are defined. +These new capabilities will be added to the "caps" property in the Router Address, not in the Router Info caps. +We currently don't have a "caps" property defined for NTCP2. +An SSU address with introducers is, by definition, ipv4 right now. We don't support ipv6 introduction at all. +However, this proposal is compatible with a IPv6 introductions. See below. + +Additionally, a router may support connectivity via an overlay network such as I2P-over-Yggdrasil, +but does not wish to publish an address, or that address does not have a standard IPv4 or IPv6 format. +This new capability system should be flexible enough to support these networks as well. + +We define the following changes: + +NTCP2: Add "caps" property + +SSU: Add support for a Router Address without a host or introducers, to indicate outbound support +for IPv4, IPv6, or both. + +Both transports: Define the following caps values: + +- "4": IPv4 support +- "6": IPv6 support + +Multiple values may be supported in a single address. See below. +At least one of these caps are mandatory if no "host" value is included in the Router Address. +At most one of these caps is optional if a "host" value is included in the Router Address. +Additional transport caps may be defined in the future to indicate support for overlay networks or other connectivity. + + +Use cases and examples +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +SSU: + +SSU with host: 4/6 optional, never more than one. +Example: SSU caps="4" host="1.2.3.4" key=... port="1234" + +SSU outbound only for one, other is published: Caps only, 4/6. +Example: SSU caps="6" + +SSU with introducers: never combined. 4 or 6 is required. +Example: SSU caps="4" iexp0=... ihost0=... iport0=... itag0=... key=... + +SSU hidden: Caps only, 4, 6, or 46. Multiple is allowed. +No need for two addresses one with 4 and one with 6. +Example: SSU caps="46" + +NTCP2: + +NTCP2 with host: 4/6 optional, never more than one. +Example: NTCP2 caps="4" host="1.2.3.4" i=... port="1234" s=... v="2" + +NTCP2 outbound only for one, other is published: Caps, s, v only, 4/6/y, multiple is allowed. +Example: NTCP2 caps="6" i=... s=... v="2" + +NTCP2 hidden: Caps, s, v only 4/6, multiple is allowed No need for two addresses one with 4 and one with 6. +Example: NTCP2 caps="46" i=... s=... v="2" + + + +IPv6 Introducers for IPv4 +---------------------------- + +The following changes are required to correct errors and inconsistencies in the specs. + +Spec Changes +~~~~~~~~~~~~~~~~ + +[SSU}_ currently says (IPv6 notes): + +IPv6 is supported as of version 0.9.8. Published relay addresses may be IPv4 or IPv6, and Alice-Bob communication may be via IPv4 or IPv6. + +Add the following: + +While the specification was changed as of version 0.9.8, Alice-Bob communication via IPv6 was not actually supported until version 0.9.50. + + +[SSU-SPEC]_ currently says (Relay Request): + +The IP address is only included if it is be different than the packet's source address and port. +In the current implementation, the IP length is always 0 and the port is always 0, +and the receiver should use the packet's source address and port. +This message may be sent via IPv4 or IPv6. If IPv6, Alice must include her IPv4 address and port. + +Add the following: + +The IP and port must be included to introduce an IPv4 address when sending this message over IPv6. +This is supported as of release 0.9.50. + + + +IPv6 Introductions +---------------------------- + +All three of the SSU relay messages (RelayRequest, RelayResponse, and RelayIntro) contain IP length fields +to indicate the length of the (Alice, Bob, or Charlie) IP address to follow. + +Therefore, no change to the format of the messages is required. +Only textual changes to the specifications, indicating that 16-byte IP addresses are allowed. + + +Spec Changes +~~~~~~~~~~~~~~~~ + +[SSU]_ currently says (IPv6 notes): + +Bob-Charlie and Alice-Charlie communication is via IPv4 only. + +[SSU-SPEC]_ currently says (Relay Request): + +There are no plans to implement relaying for IPv6. + +Change to say: + +Relaying for IPv6 is supported as of release 0.9.xx + +[SSU-SPEC]_ currently says (Relay Response): + +Charlie's IP address must be IPv4, as that is the address that Alice will send the SessionRequest to after the Hole Punch. +There are no plans to implement relaying for IPv6. + +Change to say: + +Charlie's IP address may be IPv4 or, as of release 0.9.xx, IPv6. +That is the address that Alice will send the SessionRequest to after the Hole Punch. +Relaying for IPv6 is supported as of release 0.9.xx + +[SSU-SPEC]_ currently says (Relay Intro): + +Alice's IP address is always 4 bytes in the current implementation, because Alice is trying to connect to Charlie via IPv4. +This message must be sent via an established IPv4 connection, +as that's the only way that Bob knows Charlie's IPv4 address to return to Alice in the RelayResponse. + +Change to say: + +For IPv4, Alice's IP address is always 4 bytes, because Alice is trying to connect to Charlie via IPv4. +As of release 0.9.xx, IPv6 is supported, and Alice's IP address may be 16 bytes. + +For IPv4, this message must be sent via an established IPv4 connection, +as that's the only way that Bob knows Charlie's IPv4 address to return to Alice in the RelayResponse. +As of release 0.9.xx, IPv6 is supported, and this message may be sent via an established IPv6 connection. + + + + +Migration +========= + +All old routers should ignore the caps property in NTCP2, and unknown capability characters in the SSU caps property. + + + + + +References +========== + +.. [CAPS] + http://zzz.i2p/topics/3050 + +.. [NTCP2] + {{ spec_url('ntcp2') }} + +.. [SSU] + {{ site_url('docs/transport/ssu', True) }} + +.. [SSU-SPEC] + {{ spec_url('ssu') }}