Hyper Open Edge Cloud

Rapid.Space SDN Features

Short introduction of Rapid.Space SDN features
  • Last Update:2023-11-21
  • Version:002
  • Language:en

Rapid.Space SDN

Rapid.Space SDN is based on Re6st (also called Re6stnet and pronounced resist), a multiprotocol random mesh generator. It is used to solve the current lack of reliability of Internet connectivity for distributed enterprise applications due to bugs in routers, packet inspection breaking TCP protocol, government filters filtering too much, etc. Without Rapid.Space SDN, it would have been impossible to deploy critical business applications used by large companies (Mitsubishi, SANEF, Aide et Action, etc.) on a decentralized cloud. It would also be impossible to manage the deployment of distributed cloud in Brazil, China or Ivory Coast where the Internet is even less reliable.

The SDN service is one of the basic services provided by Rapid.Space. It is legally available in China thanks to the company GrandeNet which carries the "National VPN" license: 中华人民共和国增值电信业务经营许可证 (Value-added telecommunications business license of the People's Republic of China) 沪A1-20140091.



  • Guarantee connectedness between computers connected to the internet, for which there exists a working route (in case the direct route isn't available).
  • Give ipv6 addresses to machines with only ipv4 available.
  • Autonomous: Re6st nodes on a lan do not depend on internet access.

Resilience & Scalability

Re6stnet guarantees that if there exists a route between two machines, traffic will be correctly routed between these two machines. Even if the registry node is down, the probability that the network is not connected is very low for big enough networks (more than a hundred nodes). Re6stnet can detect and take into account nodes present on the local network to optimize performance and work locally even with no internet.

Since nodes don't need to know the whole graph of the network, re6stnet is easily scalable to tens of thousand of nodes.

Computers installed with Re6st will also become a router among the SDN IPv6 network. With increasing 100+ routers, OpenVPN is constantly creating tunnels among the nodes making sure there is always a way between two servers.


Rapid.Space SDN always pick the most effective and fastest tunnels. We compared Rapid.Space SDN performance with standard ipv4. We observed that Rapid.Space SDN globally reduced latency between 15% to 30% and packet loss to lower than 1% (a 5-10x improvement) for a group of computers if compared with standard IPv4.

We used a small set of servers (12) with public IPv4 running SlapOS Distributed Monitoring. Each server tries to contact (using ICMP Protocol) all other 12 servers using IPv4 and IPv6 addresses. Tests are performed 10 times (10 pings) every 10 minutes and we get the average and packet loss for testing and comparison. The image illustrates the tests with using just 3 servers. 

Please check GrandeNet - The Internet on Steroids to get details of our research. 

Standard IPv4 vs Standard IPV6 vs Rapid.Space SDN

Connections Standard IPV4 Standard IPV6 Rapid.Space SDN
Standard IPV4 Fluctuating Performance and routing issues Need Proxy

Need Rapid.Space CDN Proxy

Standard IPV6 Need Proxy Fluctuating Performance and routing issues    

OK but unreliable
may have bad connection

Rapid.Space SDN Fluctuating Performance and rooting issues     Fluctuating Performance and routing issues    

Good connection
Low latency

No Routing Issues

Re6st Technical implementation

Rapid.Space SDN is Software-defined networking. A way to describe abstracting network functions in order to virtualize them and control them by software. For more information: Wikipedia: Software-defined networking

Re6st  creates a resilient, scalable, ipv6 network on top of an existing ipv4 network. A re6stnet network consists of at least one Registry and many nodes. The Registry is only used to deliver certificates for secure authentication of peers, and to bootstrap new nodes. The addresses of re6stnet nodes are assigned by Registry during the certificates delivery. It establishes connections with other nodes by creating OpenVPN tunnels. Babel routing protocol is used to discover optimal routes between each point in the mesh. It supports IPv6 and IPv4.

Re6st generates a random mesh of tunnels between computers located all over the world. A certain number (ex. 10) of arrows (tunnels) are randomly created from each node (computer) of the mesh to another node. Each arrow (tunnel) of the mesh is used to carry payloads between nodes (computers) of the mesh. Every given time period (ex. 5 minutes), a certain share of arrows (tunnels) is destroyed and replaced by randomly chosen tunnels. The best possible combination of arrows to reach another node is computed in real time by a routing protocol, in our case babel. The general design of re6st is modular in abstract: tunnel technology can be changed (ex. openvpn, gre, fou, tinc, etc.) as well as routing protocol (ex. babel, batman, etc.) or protocol (ex. IPv6, IPv4, RINA, etc.).

Babel: a loop-avoiding distance-vector routing protocol for IPv6 and IPv4 with fast convergence properties

OpenVPN: creating secure point-to-point or site-to-site tunnel

Re6st is developed and maintained by Nexedi (see our full free software stack).

Traceroute from a re6st node


Inside a re6st network, re6st nodes use openVPN tunnels to communicate effectively and packets are routed by babel protocol. In order to reach ipv6 addresses outside the re6st network, a border gateway is used.

In this example, Rapid.Space SDN User is sending several test packets of data to a specified destination address(archlinux.org), and records each intermediate router or link passed by the data on it's journey. Each router encountered represents a hop, and is also known as a node. It's common for data to have several hops before it reaches its destination. Among them, there is a special re6stnet node which is the border gateway between the Re6st network and the external network. 

$ traceroute6 archlinux.org
traceroute to archlinux.org (2a01:4f9:c010:6b1f::1), 30 hops max, 80 byte packets
1 2401:5180:0:1c::5172 (2401:5180:0:1c::5172) 1.046 ms 0.914 ms 0.742 ms
2 2401:5180:0:2b::1 (2401:5180:0:2b::1) 18.375 ms 18.354 ms 17.184 ms
3 * * *
4 e0-24.core2.dus1.he.net (2001:470:0:3b2::1) 36.447 ms 36.728 ms 37.518 ms
5 100ge6-1.core1.fra1.he.net (2001:470:0:52e::1) 35.054 ms 35.110 ms 34.913 ms
6 decix2-gw.hetzner.com (2001:7f8::616c:0:2) 39.494 ms 33.941 ms 2001:7f8:1::a502:4940:1 (2001:7f8:1::a502:4940:1) 32.218 ms
7 core3.sto.hetzner.com (2a01:4f8:0:3::56) 55.978 ms 57.759 ms 57.364 ms
8 core6.hel.hetzner.com (2a01:4f8:0:3::2a6) 58.433 ms core31.hel1.hetzner.com (2a01:4f8:0:3::2e6) 59.828 ms 2a01:4f8:0:3::42d (2a01:4f8:0:3::42d) 63.540 ms
9 2a01:4f9:0:c001::a076 (2a01:4f9:0:c001::a076) 64.292 ms 61.013 ms 2a01:4f9:0:c001::a006 (2a01:4f9:0:c001::a006) 58.401 ms
10 * * *
11 2a01:4f9:0:c001::1e3a (2a01:4f9:0:c001::1e3a) 57.017 ms 56.935 ms 61.506 ms
12 archlinux.org (2a01:4f9:c010:6b1f::1) 57.713 ms !X 57.470 ms !X 56.138 ms !X