Tunnel IP over Reticulum

[marek22k]

Hello,

I would like to know if it is possible to tunnel IP traffic (both IPv4 and IPv6) via Reticulum - similar to a WireGuard or GRE tunnel.

Background (for those who are interested): I am a participant (AS4242422923) in dn42 and therefore like to experiment with new (routing/network) technologies. That's why I always like to try out new (FLOSS) ways of tunneling IP traffic. I therefore do not want to create classic client(s)-server tunnels, but "real" peer-to-peer tunnels.

Is there an example or maybe even a tutorial? Is it theoretically possible at all? If so, how much speed and latency can I expect? As far as I understand it, all traffic in Reticulum is encrypted - so would it be unnecessary to encrypt the tunnel again (e.g. via WireGuard)? How can I be sure that only my desired peer connects with me (authentication)? If the feature is not yet available, should I submit a feature request (as an issue)?

Regards
Marek Küthe

[faragher]

Technically possible, but practically a bad idea. Programs that expect TCP performance may have issues, and if you're simply encrypting the packet wholesale, you're losing the efficiency benefits of Reticulum.

Your speed and latency varies based on links in the node and traffic, from expected performance to kilobytes per second with multi-second latency.

The benefit of Reticulum, besides security, is functioning without TCP/IP infrastructure. There are options that already provide security over ethernet connections, as you know far better than I.

Much more discussion here: #290

[marek22k]

First of all, thanks for the answer!

The benefit of Reticulum, besides security, is functioning without TCP/IP infrastructure. There are options that already provide security over ethernet connections, as you know far better than I.

It is precisely this ability to establish connections via so many communication options that I find so good! I would like to be able to tunnel IP over things other than Ethernet and WiFi. Furthermore, with Reticulum I could easily connect two nodes even without an existing infrastructure (in the form of cables or radio).

[faragher]

From phone, sorry if not in a reply format. I want to once again reiterate it's a far better idea to use the system directly, and that the old floor was 500 bits per second and is now closer to 5. Most radios are under 5 kbits per second. But if you're aware of the issues, and how you likely won't like the results, and you want to continue, I see no reason to stop you. You want to look into establishing links and transferring information as resources, I think. The documentation is very good, if not always comprehensive. There's really nothing else to it, although you can always play with confirmations and the like. However: you might want to try UDP, as you won't need to worry about confirming everything. If you need to do so, perhaps you should look into Reticulum delivery confirmation and reconstruct the packet rather than shipping home every confirmation individually. Let us know if you have any success and, as a personal favor, let us know if it's a terrible mess that shouldn't really be considered. In either case, it'll be nice to have documentation for the next person who asks.

[marek22k]

However: you might want to try UDP, as you won't need to worry about
confirming everything

Personally, I wouldn't do any confirmation or retransmission at the level of Reticulum at all. The IP stack is structured in such a way that packet loss can occur in layer 3. It is up to the higher layers to take care of retransmission and the like.

Reticulum delivery confirmation and reconstruct the packet rather than
shipping home every confirmation individually.

Packet reconstruction sounds interesting.

Let us know if you have any success and, as a personal favor, let us know

I think I'm more of a user than a developer when it comes to things like this :-) But if I try it out, I can of course tell you about it!