Netsukuku - Your Own Internet

Recently, the habrasociety has been actively discussing topics related to piracy, the government tightening all kinds of nuts and other lawlessness. Options to counter the control, censorship and deanonymization policies of the network are discussed.

It is strange that against all this background there was not a single post about such an entertaining project as Netsukuku . The goal of which, no less than that, is to build your Internet with chess and administrators.

Rave? Not really.


Let's start with the basics. All of us beloved Internet was originally created as a military system, to which strict requirements were placed on reliability and fault tolerance. Ideally, the network should work even after the loss of part of the nodes and in the event of a nuclear war. Well, we already know that :)

In fact, everything turned into a bureaucracy. Being resilient by nature, the network is based on highways and centralized services like InterNIC, IANA and is completely dependent on them. For a long time, the Russian Internet was generally concentrated at almost one point (M9), the failure of which led to a network disaster several years ago.

In addition to purely technical problems, there are also political ones - every more or less defined state seeks, if not to manage, then to control its traffic. In especially neglected cases, this is expressed in a complete blockade of all content except the charitable. Under the auspices of the fight against piracy, all sorts of laws are being conceived, dissolving the hands of lawyers, special services and other pleasant offices. And the providers themselves are by no means striving to provide the user with maximum comforts - both traffic is cut and ports are blocked.

Well?

In contrast to all this, a hot Italian guys founded a project with a Japanese name - Netsukuku. This is a project to implement a fault-tolerant, distributed, self-organizing network, built on the basis of existing network technologies such as TCP / IP and WiFi. The software itself is extremely undemanding to resources and can be run even on embedded devices, such as access points and SOHO routers.

The main feature of this technology is that it allows you to build a network mesh with dynamic routing up to 2 ¹²⁸ nodes (!) In size . And to build it loudly said - just run the daemon on the device, and the rest will happen automatically.

Unlike Freenet, N depends on the Internet only partially and in the long run in general may refuse it. It should also be noted that Netsukuku operates at the 3rd level of the OSI model and involves the construction of an independent physical data network. That is, this is not another application protocol over the Internet, but an independent network.

Hmm ... And more?

So, in order. The foundation of the entire Netsukuku network is the host. A node is a network device (access point or user's PC) with routing software running on it. All nodes are peer to peer; there are no differences between the end user node and the router, which combines several adjacent subnets. The network itself implies the use of wireless technologies, as the most convenient in terms of scaling and connection.

As soon as the user has launched the Netsukuku daemon on his device, his node starts throwing broadcast packets in order to find neighbors. As soon as a neighbor is discovered, routing information is exchanged, address assignment and other matters; after that, our client becomes a full member of the network and can immediately start using it - for user applications, everything happens completely mundane and transparent.

From a technical point of view, this is a large LAN with dynamic routing and its own name servers. Routing is provided by the daemon, steering the kernel routing table. The rest remains as it is.

The key to the whole idea is the QSPN quantum routing protocol ^. as well as the hierarchical network topology, which together provide a quick and computationally easy way to find a route between two arbitrary nodes, which is close to the best in efficiency.

Network topology

Internet routing is not easy. Trunk routers are kind of monsters with huge (from the point of view of the home router) amount of memory and crazy performance. This is because they are a network bottleneck - all regional traffic rushing through a limited number of channels. The selection of a suitable route is carried out using complex graph algorithms. All this does not contribute to the simplicity of building modern networks and their management.

If you try to build a network the size of the Internet on the principle of "each with each" using conventional technologies, then this would require huge amounts of memory, not to mention performance. Even if we stored only one route from one node to another, and even if this information occupied only one byte, then for the modern Internet (about 10 ⁹ nodes) 1 gigabyte of memory would be required. For every node!

The Netsukuku network is built in a hierarchical way: every 256 nodes are combined in the so-called. Group Node (gnode) 256 group nodes already make up a higher order group (ggnode) and so on. Since each group node is the same full-fledged network node, the QSPN protocol can work the same at all levels of the hierarchy. Moreover, when searching for a route, in each case it operates with a maximum of 256 nodes, which makes the search itself very easy.

Finally, the fractal approach is used to store the routes themselves - due to the high self-similarity of the network, it is possible to cram all the information in just a few kilobytes (4K for 2 ³² nodes).

Route Detection and Tracing

The basis of the QSPN protocol is the trace packet (TP). This is a package that contains the identifiers of the nodes through which it passed. This package is not sent to anyone specifically. Instead, a natural flood flooding is arranged. When we say that “node A sent a TP packet”, it means that “node A started the flood flood”.

During the session, the trace package passes each node only once. Having accepted TP, the node sends it to all its neighbors (of course, except for the source neighbor), adding itself to it. Once participating in a flood session, the node will no longer forward incoming TPs related to the same flood.

Thus, it turns out that each node that receives the TP receives complete information about the route to the sender node, as well as to each of the intermediary nodes. Since initially node A sends several TPs (to each of its immediate neighbors), then at each moment in time, there are several TP versions on the network that belong to the same flood, called a “bouquet”.

Arbitrary node X, having received the first TP from node A and looking inside the packet, suddenly receives the shortest route with the minimum RTT to node A, as well as all nodes of the chain :) Subsequent packets arriving will be alternative routes, respectively, longer. Thus, routing information is collected automatically, based on the actual network topology and delays.

End of the first part

In conclusion, I would like to say a few words about the current state of affairs in the project. Firstly, as the developers assure, the project lives and lives. At the moment, the documentation and implementation of the daemon in Python is written, which should replace the obsolete version in C. Secondly, a full-fledged launch of the network has not yet been carried out, but I really hope that it will happen soon.

Information on the topic can be found on the official website of the project ; There is also a wiki , as well as a FAQ (+ version in Russian )

PS:

Well, that’s all for today :) I wanted to write more, but my eyes are already sticking together and my head is not thinking.

In the next part, I will write in more detail about the types of trace packets and the important mechanism for resolving IP address collisions. A couple of words will be said about the host naming system - an analogue of ordinary DNS. Perhaps also, there is enough space for the interaction of the network with the Internet.

Of course, if you have questions and suggestions - you are welcome. I will try to answer. Yes, and again: I am not (yet?) The developer of this system and cannot imagine all the subtleties of the algorithms. But there is information and a desire to master it too.