Netsukuku - Close the world, txEn eht nepO - -- 0. Preface 1. The old wired 2. The Netsukuku wired 2.1 Gandhi 2.2 No name, no identity 2.3 So, WTF is it? 2.4 Other implementations 2.5 The born 3. Netukuku Protocol v7: the seventh son of Ipv7 3.1 #define Npv7 4. Npv7_II: Laser Broadcast 5. Npv7 Hybrid Theory: the final way 5.1 QSPN: Quantum Shortest Path Netsukuku 5.1.1 QSPN screenshot 5.1.2 Continual qspn starters 5.1.3 The Qspn sickness: RequestForRoute 5.1.4 Qspn round 5.2 Npv7_HT Hook & Unhook 5.2.1 Qspn Hook & Unhook 5.3 The truly Gnode^n for n<=INFINITE 5.3.1 Groupnode: one entity 5.3.2 Gnode fusion 6. Broadcast: There can be only one! 6.1 Tracer pkt: one flood, one route 7. ANDNA: Abnormal Netsukuku Domain Name Anarchy 7.1 ANDNA Metalloid elements: registration recipe 7.1.1 ANDNA hook 7.1.2 Don't rob my hostname! 7.1.3 Count again 7.1.4 Registration step by step 7.1.5 Endless rest and rebirth 7.1.6 Hash_gnodes mutation 7.1.7 Yaq: Yet another queue 7.8 Hostname resolution 7.8.1 Distributed cache for hostname resolution 7.8.2 noituloser emantsoh esreveR 7.9 dns wrapper 7.10 Scattered Name Service Disgregation 7.10.1 Service, priority and weight number 7.10.1.1 Service number 7.10.1.2 Priority 7.10.1.3 Weight 7.10.2 SNSD Registration 7.10.2.1 Zero SNSD IP 7.10.2.2 SNSD chain 8. Heavy Load: flood your ass! 9. Spoof the Wired: happy kiddies 10. /dev/Accessibility 11. Internet compatibility 11.1 Private IP classes in restricted mode 11.1.1 Netsukuku private classes 11.1.2 Notes on the restricted mode 11.2 Internet Gateway Search 11.2.1 Multi-gateways 11.2.1.1 Anti loop multi-inet_gw shield 11.2.2 Load sharing 11.2.3 The bad 11.2.4 MASQUERADING 11.2.5 Traffic shaping 11.2.6 Sharing willingness 11.2.7 See also 12. Implementation: let's code 13. What to do 14. The smoked ones who made Netsukuku -- 0. Preface This document and the relative source code are available on: http://netsukuku.freaknet.org Future extensions to this document can be found and added here: http://lab.dyne.org/Netsukuku 1. The old wired The Internet is a hierarchic network managed by multinational companies and organizations supported by governments. Each bit of Internet traffic passes through proprietary backbones and routers. The Internet Service Providers give the connectivity to all the users, who are in the lowest rank of this hierarchic pyramid. There is no way to share the ownership of Internet and people can join the Net only in accordance with conditions and terms imposed by the Majors. The Internet represents, today, the means to access information, knowledge and communication. About 1 billion of people can connect to this great proprietary network, but the remaining 5 billion of people, which don't have enough economic resource, are still waiting the multinationals to supply a service with in their reach. The Internet was born with the intent of warranting a secure and unattackable communication between the various nodes of the network, but now, paradoxally, when an ISP decide to stop to provide its service, entire nations are immediately cut out of the Internet. Beside that, Internet is not anonymous: the ISP and the multinationals can trace back and analyse the traffic of data going through their servers, without any limits. The centralised and hierarchical structure of Internet creates, as a consequence, other identical systems, based on it, i.e. the DNS. The servers of the Domain Name System are managed by different ISPs, as well and the domains are literally sold through a similar centralised system. This kind of structures allows, in a very simple and efficient way, to physically localise any computers, which are connected to the Internet, in a very short time and without any particular efforts. In China, the whole net is constantly watched by several computers filtering the Internet traffic: a Chinese will never be able to see or came to know about a site containing some keywords, such as "democracy", censored by the government. Beside that, he'll never be able to express his own ideas on the net, e.g. about his government's policy, without risking till the death penalty. Internet was born to satisfy the military needs of security for the administration of the American defence, not to ensure freedom of communication and information: in order to communicate each other the Internet users are obliged to submit themselves to the control and to the support of big multinationals, whose only aim is to expand their own hegemony. As long as all the efforts to bring more freedom, privacy and accessibility in the Internet face aversions, fears, contrary interests of governments and private companies, the very alternative solution to this problem is to let the users migrate toward a distributed, decentralised and fully efficient net, in which all the users interact at the same level, with no privilege and no conditioning means, as authentic citizens of a free world wide community. 2. The Netsukuku wired Netsukuku is a mesh network or a p2p net system that generates and sustains itself autonomously. It is designed to handle an unlimited number of nodes with minimal CPU and memory resources. Thanks to this feature it can be easily used to build a worldwide distributed, anonymous and not controlled network, separated from the Internet, without the support of any servers, ISPs or authority controls. This net is composed by computers linked physically each other, therefore it isn't build upon any existing network. Netsukuku builds only the routes which connects all the computers of the net. In other words, Netsukuku replaces the level 3 of the model iso/osi with another routing protocol. Being Netsukuku a distributed and decentralised net, it is possible to implement real distributed systems on it, e.g. the Abnormal Netsukuku Domain Name Anarchy (ANDNA) which will replace the actual hierarchic and centralized system of DNS. 2.1 Gandhi Netsukuku is self-managed. It generates itself and can stand alone. A node hooks to Netsukuku, the net automatically rewrites itself and all the other nodes known which are the fastest and more efficient routes to communicate with the new arrived. The nodes don't have privileges or limitation, when compared with other nodes, they are part of the net and give their contribution to its expansion and efficiency. The more they increase in number the more the net grows and becomes efficient. In Netsukuku there is no any differences among private and public nets and talking about LAN became meaningless. It can be neither controlled nor destroyed because it is totally decentralised and distributed. The only way to control or demolish Netsukuku is knocking physically down each single node which is part of it. 2.2 No name, no identity Inside Netsukuku everyone, in any place, at any moment, can hook immediately to the net without coming trough any bureaucratic or legal compliance. Moreover, every elements of the net is extremely dynamic and it's never the same. The ip address which identify a computer is chosen randomly, therefore it's impossible to associate it to a particular physical place, and the routes themselves, been composed by a huge number of node, show the tendence to have such a high complexity and density to make the trace of a node a titanic task. Since there isn't any contract with any organisations, the speed of the data transfer is uniquely limited by the actual tecnology of the network cards. 2.3 So, WTF is it? Netsukuku is a mesh network or a p2p net composed by a net protocol for dynamic routing called Npv7_HT. Currently there is wide number of protocols and algorithms for the dynamic routing, but they differ from the Npv7_HT, 'cause they are solely utilized to create small and medium nets. The routers of Internet are also managed by different protocols as the OSPF, the RIP, or the BGP, based on different classical algorithms, able to find out the best path to reach a node in the net. These protocols require a very high waste of cpu and memory, this is the reason why the Internet routers are computers specifically dedicated to this purpose. It would be impossible to implement one these protocols in order to create and maintain such a net as Netsukuku is, where every each node is a router by itself, because the map of all the routes would require a space, on each pc connected to the net, of about ten Gb. The Npv7 structures the entire net as a fractal and, in order to calculate all the needed routes which are necessary to connect a node to all the other nodes, it makes use of a particular algorithm called Quantum Shortest Path Netsukuku (QSPN). A fractal is a mathematical structure which can be compressed up to the infinite, because inside it, every part itself is composed by the same fractal. Thus there is a high compression of a structure which can be infinitely expanded. This means that we need just a few Kb to keep the whole Netsukuku map. The map structure of Netsukuku can be also defined more precisely by calling it a highly clusterised graph of nodes. On the other hand, the QSPN is a meta-algorithm in the sense that it doesn't follow any predefined mathematical instructions but exploits the chance and the chaos, which both don't need any heavy computation. The QSPN has to be executed on a real (or simulated) network. The nodes have to send the QSPN packets in order to "execute" it. For this reason it is not always true that a determinated pkt will be sent before another one. 2.4 Other implementations Netsukuku is not restricted solely to the creation of a net of computers, it is a protocol which implements a mesh net, and alike every net protocol can be used in all the situations in which it's necessary to connect different nodes to each other. Let's take in exam the case of mobile phones. Also the mobile phone net is a hierarchic and centralised net. Thousands of nodes hook to a same cell, which will sort the traffic to the other cells and these, finally, will send the data to the destination-nodes. Well, Netsukuku can be used also by mobile phones, making pointless the existence of all the mobile telecommunication companies. This can be applied to all the systems of communication which are used nowadays. 2.5 The born The story of how the idea of Netsukuku was born is quite a long and complicated story. During a historical transmission of radio Cybernet at the Hackmeeting 2000, the idea of Ipv7, nocoder, nocrypt came to life. They were absurd theoric jokes about a IP protocols, intelligent compiler and crypto programs. In the far 2003, a crew of crazy freaks continued to expand the concepts of the Ipv7: a net in which all the packets were sent in broadcasted, compressed with the zlib7, an algorithm which could compress all the existent Internet into just 32 byte ( See http://idiki.dyne.org/wiki/Zlib7 ). In Ipv7 the nodes were devoid of an ip address, it was an extremely decentralised and totally free net. Those people were really happy after the first draft of the RFC. One year later, the project was lost in the infinite forks of time, but after some time, the dust was shaked off the great Ipv7 book. We started to delineate the idea of the implementation of a pure net. Month by month the net became more and more refined, and the project became something concrete. <>. <>. <>. Other three months passed by and after many mystical meditations, the theoretical kernel was ready. The algorithms were defined. We started to code. The curse of the protocols coders of Pharaon Mortedelprimogenito invaded the Netsukuku code. The delirium is the right reward to all those who dare to create protocols of pure nets. In spite of all, exactly after one year and after fourteen thousand lines of code, Netsukuku Beta version was ready and immediately presented at the National Hackmeeting 2005 in Naples. The ANDNA was completed and documented. In October, the first public version of Netsukuku was released. By now, in May 2006, the protocol has been greatly improved, and feature after feature the daemon has reached forty thousand lines of code. What's left sleeps in our minds and still have to become. -- -- The Netsukuku Protocol Npv7 3. Netsukukuku protocol v7 Netsukuku uses its own protocol, the Npv7 (Netsukuku protocol version 7), which derives from three different previous versions. The first one was quite similar to the current dynamic routing protocols: the network was in fact divided into several groups of nodes, and every single node had a distinct map of the entire network. This system, absolutely not optimal, cannot be employed by Netsukuku 'cause it needs continuous and subsequent updates of the early map, and each update will bring an overload in the net. Moreover, each time the map changes, it's necessary to recalculate all the routes. Future extensions to the Npv7 can be found and added here: http://lab.dyne.org/Netsukuku_RFC 3.1 #define Npv7 The basic definitions used in Netsukuku are: src_node: Source node. It is the node who send a packet to the dst_node. dst_node: Destination node. It is the node which receives the packet from the src_node. r_node: Remote node, given a node X, it is any other node directly linked to X. g_node: Group node, a group of nodes, or a group of a group of nodes, and so on. b_node: Border node, a node connected to rnodes of different gnode. h_node: Hooking node, a node hooking to Netsukuku. int_map: Internal map. The internal map of the node X contains the informations about the gnode, which the node X belongs to. ext_map: External map. The external map contains the informations about the gnodes. bmap / bnode_map: Border node map. It's the map which keeps the list of border_nodes. quadro_group: A node or a groupnode located at any level, disassembled in its essential parts. 4. Npv7_II: Laser Broadcast Npv7_II is the second version of the Npv7. Netsukuku is divided into many smaller groupnodes, which contains up to six hundred nodes each and every node will solely have an external map. All the groupnodes are grouped into multi-groupnodes, calle quadro groupnodes. In order to create a new route and connect to a given dst_node, the src_node, using the external map, firstly tries to find out the best path to reach the destination gnode, which the dst_node belongs to. In this way the founded route is stored in the pkt broadcasted inside the gnode, which the src_node belongs to. The border_nodes of the gnode of the src_node receive the pkt and check if the next gnode, to which the pkt has to be broadcasted, is the proper neighbor gnode. If the condition is true, the border_nodes broadcast the pkt to that same neighbor gnode. Otherwise the pkt is dropped. And so on... In this way the packet will reach the destination gnode. When the dst_node receives the pkt it has just to set an inverse route, using the route already stored in the pkt. The Npv7_II and its previous version are not utilised, but they are just the theoretical base of the Npv7_HT, the present version of the Netsukuku protocol. 5. Npv7 Hybrid Theory: the final way From the union of the Npv7 and Npv7_II Npv7 Hybrid Theory was born from the union of the Npv7 and Npv7_II. This new version, exploits the advantages of both the internal map and the laser broadcast and in this way it can overpass their limits. In Npv7_HT the maximum number of nodes, present in a group node (MAXGROUPNODE) is equal to 2^8, thus the groupnodes are relatively small. The main change in Npv7_HT is about its own essence, in fact, it's based on a algorithm appositely created for Netsukuku, which is called Quantum Shortest Path Netsukuku, which allows to obtain at once all the informations related to the complete situation of the gnode, all the best routes, the reduction of the load of the gnode, an efficient management of high dynamic gnodes and moreover it's not even necessary to authenticate each node. 5.1 QSPN: Quantum Shortest Path Netsukuku In Netsukuku, as well as in Nature, there is no any need of using mathematical schemes. Does a stream calculate the best route to reach the sea when it is still at the top of the mountain? The stream simply flows and its flux will always find its ideal route. Netsukuku exploits the same chaotic principle. The result of its net discovery algorithm can be different each time, even if the net hasn't changed at all. This is because the discovery algorithm is "executed" by the net itself. The use of a map, for a protocol of dynamic nets, creates a lot of troubles, since it has to be continuously updated. The solution is simple: to avoid totally the use of maps and make every broadcasted request a tracer_pkt (See 6.1 Tracer pkt). In this way every node, which will receive the pkt, will known the best route to reach the src_node and all the nodes which are at the middle of the route itself, it will record these informations inside its internal map, it will add its own entry inside the tracer_pkt and will continue to broadcast the pkt. The left problem is: in order to obtain all the routes for all the nodes it's necessary that all the nodes broadcast a tracer_pkt. Currently this problem doesn't exist at all. In fact, with the tracer_pkt we can obtain also the routes for the middle-nodes: that means we need a smaller number of n packets, where n is the number of nodes. If every time a node receives a tracer_pkt, it sends it back to the src_node, in this way we are sure that all the nodes can receive all the possible routes. By using this system we obtain the same result achieved by making every node send a tracer_pkt. Those who already know the physic of waves, can easily understand how the qspn works. If we throw a pebble at a mirror of water, contained in a basin, circular waves begin to propagate themself from the point of impact. Each wave generates a child wave that continues to spread and to generate child waves, as well, which generate children, and so on... When a wave hits the borders of the basin, it is reflected and goes back to the start point. The same happens if the wave meets an obstacle. The qspn_starter is the pebble thrown inside the groupnode and each wave is a tracer_pkt. Each child wave carries with itself the information of the parent wave. When the wave arrives at an extreme_node (an obstacle or a dead road), the qspn_open (the reflected wave) starts. The QSPN is based on this principle. To begin the tracing of the gnode, any node sends a qspn_pkt called qspn_close and then this node becomes a qspn_starter. A qspn_pkt is a normal tracer_pkt, but its broadcasting method is lightly different from the normal one. Each node, which receives a qspn_close "closes" the link the pkt was received and sends the pkt to all its other links. All the following qspn_close pkts, which will arrive to the node, will be sent to all the links, which have not been already closed. When the qspn_close is totally diffused, some nodes will have all their links closed. These nodes will be the extreme_nodes, which will send another qspn_pkt (called qspn_open) in order to reply. The qspn_open contains all the information already stored in the last qspn_close receveid. The extreme_nodes will send the qspn_open to all their links, except the one from which they have received the last qspn_close and to which they'll send an empty qspn_open. The qspn_open is a normal qspn_pkt, so it "opens" all the links in the same way of the qpsn_close. The nodes, which will have all their links opened will do absolutely nothing, in this way the end of the qspn_close is warranted. A qspn_open pkt has also a sub_id, a number that identifies, in the internal map, the extreme node, which has generated the qspn_open pkt itself. The sub_id, which remains unmodified in all the child qspn_open pkts, generated from the first packet, is used to manage simultaneusly more qspn_pkts, since each extreme_node generates one qspn_open and each of them has to be independent from the others. Indeed all the nodes, which have only one link, are surely e_nodes (extreme nodes), in fact, when they receive a qspn_close they are already closed. A node, after sending a qspn_open, cannot reply anymore to any qspn_pkts that it is going to receive and so it will send no more qspn_pkts. The qspn_starter, the node which has triggered the qspn, acts as a normal node but will not send qspn_opens, since it already sent the very first qspn_close. Moreover, in order to update its own map, it will use all the qspn_closes which are going to be received, excepting those which have been already sent by the qspn_starter and those which already crossed more than one hop. In this way, even if there is more than one qspn_starter, the stability is maintained. The in-depth description of the qspn_starter is in the following paragraph 5.1.1. At the end, the total number of packets, which are sent in broadcast are equal to the number of e_nodes, exactly 2 per cyclic net segment and 1 per single non-cyclic segment. Every time a tracer_pkt goes trough the net, the information about the crossed routes, which it carries, are stored by all the nodes which receive the tracer_pkt. A node will probably receive different routes to reach the same node, but it will memorize only the best MAXROUTES (10) routes. The qspn_pkt id, which is stored in the pkt itself, is at the beginning set as 1 and is incremented by 1 every time a new qspn_pkt is sent by any nodes. Because of that, all the nodes know the current qspn_pkt id. Each time a node desires to globally update the internal or external map, it sends a qspn_close, but only if it hasn't received, in the previous QSPN_WAIT seconds, another qspn_close yet. If two nodes send, at the same time, a qspn_close, they will use the same pkt id 'cause they don't know that another qspn_close, with the same id, was already sent; in this case the way of working of the qspn doesn't change, in fact, if the two qspn_pkt were sent from very distant places, the qspn_pkt will spread more rapidly. When a node downloads the internal map from another node, it has to restore the map before making use of it. To do that the node has to just to insert the r_node, from which it has downloaded the map, to the beginning of all the routes. If the node downloads the map from more than one rnode, it will have to compare all the routes and choose the best one. The resulting map will have all the best routes. The routes of the internal and external maps will be always copied in the kernel routing table. In this way, it will not be necessary to create every time different routes to reach different destination nodes. 5.1.1 QSPN screenshot (A)-----(B) / | \ | \ (E) | \ | (F) \ | \ | / (C)-----(D) Let's recap, then! All the extreme nodes shall send a tracer_pkt, but we cannot know which are they. In the above picture it's easy to point them out, because, indeed, they are drawn in a map, but in reality (inside the Netsukuku code) a topologic map doesn't exist at all, so we cannot know where a group of nodes begins and where it ends. This is what will happen, in a theoretical simulation, if the node E sends a qspn_close: E has sent the first qspn_close of a new qspn_round, so it is now a qspn_starter. Let's consider the case when the node A receives before C the qspn_close. A closes the link E and sends the pkt to B, C and D. C receives the pkt, closes the link E and sends it to A and D. C receives the pkt from A and closes the link. B e D have received the pkt and close the respective links. Let's consider the case when B sends the pkt before F. D, immediately, sends it to F, but at the same time F sends it to D. D receives the pkt from B, too. D and F have all the links closed. They send a qspn_open. The qspn_open propagates itself in the opposite sense. The qspn_open ends. Each node has the routes to reach all the other nodes. In general, the basic topology of a map for the qspn is a rhomb with the nodes at the vertexes, then, to have a more complex topology it's possible to add other rhombs united each other from the vertexes. 5.1.2 Continual qspn starters If more qspn_starters, which launch a qspn, are contiguous among them, so the way of working of the qspn is slightly different. A group of qspn_starter nodes is contiguous when all its nodes are linked to other nodes, which are qspn_starters, as well. In this scenary the qspn_starters continue to mutually forward solely the qspn_closes sent by the qspn_starters; in fact, they acts as normal nodes, but whenever they receive pkts coming from outside of the contiguous group of qspn_starters, they follow again their basic instructions. So, if A sends a qspn_close and B has already sent a qspn_close, as well, when B receives the qspn_close of A, B forwards it as a normal tracer_pkt with the BCAST_TRACER_STARTERS flag, which will spread only among the other starters. The reason why all this happens is that in the contiguous group of nodes, every single node send a tracer_pkt, therefore, the qspn_pkts are declassified as normal tracer_pkts. 5.1.3 The Qspn sickness: RequestForRoute /* To code, and maybe not really necessary */ The only big hole in the qspn is the impossibility of having a vast number of routes in order to reach the same node. With the qspn we are sure to obtain just the best routes, but currently qspn can also generate uncountable routes, all what we need is to let the broadcast working forever, without interruption. Surely, it's unthinkable to wait for the eternity, that's why we use the RequestForRoute! The RFR will be used all the time a node gets connected to another node. This is what happens: the node sends to all its rnodes a RFR request for a specific route. This request contains also the number of sub-requests (total_routes), which the rnodes have to send to their rnodes. Practically, the node decides how many routes wants to receive and calculates the number of sub-requests, which its rnode will send: subrfr=(total_routes-r_node.links)/r_node.links. After that it sends the rfr request. After having sent the route, used to reach the dst_node specified inside the rfr_pkt, its rnodes sends, in the same way, an rfr with the number of total_routes equal to the number of subrfr. The rnodes of the rnodes will execute the same procedure and will directly answer to the requester node. 5.1.4 Qspn round If a node finds a change around itself, e.g. one of its rnodes is dead, or the rtt, between it and its rnode, has considerably changed, then it will send a qspn. In order to avoid to continuously generate qspns the node must firstly verify that QSPN_WAIT_ROUND (60 seconds) has expired. The QSPN_WAIT_ROUND expires at the same moment for all the nodes belonging to the same gnode. In order to make the nodes which hook to the gnode synchronised to the nodes of the gnode itself, the rnodes give to the hooking nodes the number of seconds passed since the previous qspn, in this way all the nodes will know when the next deadline will be, i.e. it will be after (current_time-prev_qspn_round)+QSPN_WAIT_ROUND seconds. When a qspn_starter sends a new qspn_pkt, it increases by 1 the id of the qspn_round. If a node receiving a qspn_pkt notices that its id is greater than the previous already recorded qspn_round id, it means that it has received a new qspn_round. In this case it will update its local id and its qspn_time (the variable, which indicates when the last qspn has been received or sent). For updating the qspn_tim, it has to set it on current_time - sum_of_the_rtt_contained_in_the_tracer_pkt. 5.2 Npv7_HT Hook & Unhook In order to make a node join Netsukuku, it has to be hooked to its rnodes. Hook in Netsukuku doesn't refer to a physical hooking to the net, 'cause we assume that a node has been already physically linked to other (r)_nodes. The hooking of a node is the way the node communicate to its nearest rnodes, if it doesn't receive any answer it will choose another rnode. Practically during the hooking, the node gains the internal map, the external one, the border node map and chooses a free ip. Now it is officially a member of the net, therefore it sends a normal tracer_pkt and its rnodes will send, later, a qspn. This is in details what really happens: The node chooses an ip included in 10.0.0.1 <= x <= 10.0.0.1+256, removes the loopback nets from the routing table and sets as default gateway the choosen ip. The step number one is to launch the first radar to see what its rnodes are. If there are no rnodes, it creates a new gnode and the hooking ends here. Then it asks to nearest rnode the list of all the available free nodes (free_nodes) presents inside the gnode of the rnode. If the rnode rejects the request (the gnode might be full), the node asks for the list of another rnode. It chooses an ip from all the received free_nodes and sets it on the network interface, modifying the default gw. The step number two is to ask the external map to the same rnode from which it obtained the list of free nodes. Using this list it checks if it has to create a new gnode. If it found it unnecessary it downloads the int_map from every rnode. Then, it joins all the received int_map into a unique map, in this way it knows all the routes. At the end, it gets the bnode_map. If everything has worked properly, it re-launch a second radar, sends a simple tracer_pkt and updates its routing table. Fin. 5.2.1 Qspn Hook & Unhook After having been hooked to a gnode, what the node has to do is to send a tracer_pkt. In this way all the nodes will already have an exact route to reach it, so they will update some routes and they will be happy. Then for what the secondary routes may concern the match will be played at the next qspn round. When a node dies or un-hooks itself from Netsukuku, doesn't warn anyone. When its rnodes notice its death, they will send a new qspn round. 5.3 The truly Gnode^n for n<=INFINITE In the world there are 6*10^9 people and if we colonize other planets they will increase to about (6*10^9)^n, where n is a random number > 0. It is also true that they will extinguish themself with one of the usual stupid war. Practically, Netsukuku has to manage a HUGE number of nodes and for this reason, as you already are aware, the gnodes are used. But they are not enough, 'cause, even using them, it would be still necessary to have an external and internal map of 300Mb. How can the problem be solved then? The gnodes are divided in further groups, which doesn't contain normal nodes but, on the contrary, whole gnodes. The contained gnodes are considered as single nodes... Continuing recursively with groups of groups, Netsukuku can contain about an infinite number of nodes with a small effort. The way of working of all the Netsukuku system remains unchanged. In order to implement the fractal gnodes we use more than one extern map, which will contain information about these groups of groups. A "group of group" is still called "groupnode". Every map of groupnodes belong to a specific level, thus the basic groupnode, which includes the single nodes, is in level 0. The map of the first groupnodes of groupnodes of nodes is located in level 1 and the map of the groupnodes of groupnodes of groupnoes is in the second level, and so on. A node, in order to reach any other node it must only have its internal map, which is the map of level 0 and all the maps of all the upper levels where it belongs to. With simple calculations, it's easy to know that to use all the IPs of the ipv4, the total number of levels is 3 (considering a group composed by MAXGROUPNODE of members). In the ipv6, instead, there are a huge number of IPs, therefore the number of levels if 16. A simple estimation tells us that, in the ipv4, all the maps needs 144K of memory, while in the ipv6 1996K are required. As usual, the QSPN is utilised to find all the routes, which connects the groupnodes. The QSPN will be restricted and started in each level, in this way, for example, it will find all the routes which links the gnodes belonging to the second level. The use of the levels isn't so complicated, just think about the way of working of the internal map, then apply it recursively to the external maps. Just consider every groupnode a single node. In order to use a route to reach a gnode, we store in the routing table range of ips (i.e. from ip x to ip y), instead of a single ip. In this way, the total number of routes necessary to reach all the nodes of Netsukuku is about is about MAXGROUPNODE*(levels+1). Let's take in exam the case of the ipv4 which has 3 levels. First of all, a node must have all the routes to reach every node of its groupnode at level 0, thus we have MAXGROUPNODE routes, then we have to add all the routes to reach the groupnodes of its upper level, so we add other MAXGROUPNODE routes. Continuing we arrive at the last level and we finally have MAXGROUPNODE*(3+1) routes. In the end we have 1024 routes for the ipv4 and 4352 for the ipv6. All of them are kept in the routing table of the kernel. 5.3.1 Groupnode: one entity The real QSPN of groupnodes changes a bit. The difference between a groupnode and a single node is subtle: the node is a single entity, which maintains its links directly by itself, the groupnode, instead, is a node composed by more nodes and its links are managed by other nodes, which are the border nodes. In order to transform the gnode in a single entity the bnodes of the gnode have to communicate each other. When a bnode receives a qspn_close from another gnode, it closes its links, then it will communicate to the other bnode of the same gnode when all its links to the external gnodes are closed. The other bnodes, of that gnode, will do the same. In this way, the qspn_open will be sent only when _all_ the bnodes have all their external links closed. The situation changes again when we consider gnode of high level, because the bnode aren't anymore a single node but a complete gnode. The procedure remains the same: the bnode-gnode is formed by all its internal bnodes. How is possible for the bnode to communicate each other? Obviously they talk passively: when a bnode closes all its external links, having received a qspn_close, it sets in the tracer_pkt, which is going to be forwarded, the BNODE_CLOSED flag, in this way all the other bnodes, noticing that flag, will increment their counter of closed bnodes. When the number of closed bnodes is equal to the that of the total bnodes, which are in the same gnode, then the bnodes will send the qspn_open. One last trick: when a bnode receives a qspn_close sent from a bnode of its same gnode, then, it considers itself a QSPN_STARTER and forwards the tracer_pkt without adding its entry, that's because the gnode has to appear as a single node. Moreover, the bnodes close and open only the external links, which connect them to the bnodes of the bording gnodes. All this strategy is also valid for the qspn_open. 5.3.2 Gnode fusion When a node creates a new group_node, it will chose it completely randomly, using a random ip. If two gnode, originally isolated, unfortunately have the same groupnode id, (and also the same range of IPs), one of them must change, that means to change the IPs of all the nodes of the gnode. The solution is described in the NTK_RFC 0001: http://lab.dyne.org/Ntk_gnodes_contiguity 6. Broadcast: There can be only one! The broadcasted packet, generally, are not sent to being forwarded forever in Netsukuku ;). Each node keeps a cache with MAXGROUPNODE members, which is stored in the internal map. Each member is associated to a node of the gnode and it contains the pkt_id of the last pkt broadcasted from that node itself. When a broadcast pkt is received by a node, first of all, it is analysed: if the pkt_id is less or equal to that memorised in the cache, it will be dropped, because it is surely an old pkt. It's useless to say that the pkt_id of the broadcast pkt being sent are incremented by one each time. If the pkt passes the test, the node executes the action requested by it and forwards it to all its rnode, excluding the one from which it has received the pkt. The number of hops the broadcast pkt has to cross can also be choosen with the ttl (time to live) of the pkt. 6.1 Tracer pkt: one flood, one route The tracer_pkt is just the way to find the best route using the broadcast. If the broadcasted pkt uses the "tracer_pkt" flag, then each crossed node will append in the pkt its ip. In this way the entire route crossed by the pkt is memorised in the pkt itself. The first pkt, which will arrive at destination, will be surely the pkt which has passed through the best route, therefore the dst_node will set the memorised route and it connects to the src_node. The first tracer_pkt has also another subtle benefit, in fact, the tracer_pkt carries the route to reach all the nodes which are part of the memorised route. That is because, if the pkt has really gone through the best route it has also crossed _all_ the best routes for the middle hops. The conclusion is that a tracer_pkt can memorise the best route to reach the src_node, and thus all the routes to reach all the middle nodes, which have been crossed. The border_node, in order to append their ip in a tracer_pkt, set the "b_node" flag and adds the id of the bording gnode, but only if that gnode belongs to a level higher than the one where the tracer_pkt is spreading. In order to optimise the utilised space in a tracer_pkt, the IPs of the nodes are stored in the IP2MAP format, which is equivalent to the IDs of the nodes in the gnode of level 0. With this format only a u_char (one byte) is required, instead of 20. 7. ANDNA: Abnormal Netsukuku Domain Name Anarchy ANDNA is the distributed, non hierarchical and decentralised system of hostname management in Netsukuku. It substitutes the DNS. The ANDNA database is scattered inside all the Netsukuku and the worst of cases every node will have to use about 355 Kb of memory. ANDNA works basically in the following way: in order to resolve a hostname we just have to calculate its hash. The hash is nothing more than a number and we consider this number as an ip and the node related to that ip is called andna_hash_node. Practically the hash_node will keep a small database, which associates all the hostnames related to it with the ip of the node, which has registered the same hostnames. Node X ip: 123.123.123.123 hash( hostname: "andna.acus" ) == 11.22.33.44 || || Node Y ip: 11.22.33.44 { [ Andna database of the node Y ] } {hash_11.22.33.44 ---> 123.123.123.123} The revocation requests don't exist, the hostname is automagically deleted when it isn't updated. 7.1 ANDNA Metalloid elements: registration recipe It is very probable that the hash_node doesn't exist at all in the net, 'cause it can be one ip among the available 2^32 ips, and even if it is up, it can also die soon and exist from the net. The adopted solution to this ugly problem is to let the hostnames be kept by whole gnodes, in this way the working of the ANDNA and a minum of hostnames backup is warranted. The gnodes related to the hash of the hostname is the hash_gnode. Inside the hash_gnode there is the hash_node too. Since even the hash_gnodes cannot exist, a approximation strategy is utilised: the nearest gnode to the hash_gnode is the rounded_hash_gnode and it is consider as a normal hash_gnode. For example, if the hash_gnode is the 210, the nearest gnode to it will be the 211 or the 209. Generally, when we are referring to the gnode, which has accepted a registration, there is no difference between the two kind of gnodes, they are always called hash_gnode. There are also gnodes, which backup the hash_gnode when it dies. A backup_gnode is always a rounded_gnode, but the number of its nodes, which backup the data is proportional to the total number of its nodes (seeds): if(seeds > 8) { backup_nodes = (seeds * 32) / MAXGROUPNODE ); } else { backup_nodes = seeds; } The maximum number of backup_gnodes per hostname is about MAX_ANDNA_BACKUP_GNODES (2). 7.1.1 ANDNA hook When a node hooks to Netsukuku becoming automatically part of a ash_gnode, it will also wonder about hooking to ANDNA through the andna_hook. With the andna_hook it will get from its rnodes all the caches and databases, which are already inside the nodes of that gnode. Obviously it is first necesarry the hooking of the node to Netsukuku. 7.1.2 Don't rob my hostname! Before making a request to ANDNA, a node generates a couple of RSA keys, i.e. a public one (pub_key) and a private (priv_key). The size of the pub_key will be limitated due to reasons of space. The request of a ostname made to ANDNA will be signed with the private key and in the same request the public key will be attached. In this way, the node will be able to certify the true identity of its future requests. 7.1.3 Count again The maximum number of hostnames, which can be registered is 256, in order to prevent the massive registration of hostnames, formed by common keyword, by spammers. The problem in ANDNA is to count. The system is completely distributed, therefore is cannot know how many hostnames a node has registered. However a there is a solution: a new element will be added, the andna_counter_node. A counter_node is a node with an ip equal to the hash of the public key of the node, which registers its hostnames, in this way there is always a counter_node for each register_node. The counter_node keeps the number of hostnames registered by the register_node related to it. When a hash_gnode receives a registration request, it contacts the relative counter_node, which reply by telling how many hostnames have been registered by the register_node. If the register_node has not exceeded its limit, the counter_node will increments its counter and the hash_gnode finally register the hostname. A counter_node is activated by the check request the hash_gnode sends. The register_node has to keep the counter_node active following the same rules of the hibernation (see the chapter below). Practically, if the counter_node receives no more chech requests, it will deactivate itself, and all the registered hostnames become invalid and cannot be updated anymore. The same hack of the hash_gnode is used for the counter_node: there will be a whole gnode of counter_nodes, which is called, indeed, counter_gnode. 7.1.4 Registration step by step Let's see the hostname registration step by step: The node x, which wants to register its hostname, finds the nearest gnode to the hash_gnode, contacts a random node belonging to that gnode (say the node y) and sends it the request. The request includes a public key of its key pair. which is valid for all the future requests. The pkt is also signed with its private key. The node y verifies to be effectively the nearest gnode to the hash_gnode, on the contrary it rejects the request. The signature validity is also checked. The node y contacts the counter_gnode and sends to it the ip, the hostname to be registered and a copy of the registration request itself. The counter_gnode checks the data and gives its ok. The node y, after the affermative reply, accepts the registration request and adds the entry in its database, storing the date of registration. Finally it forwards in broadcast, inside the its gnode, the request. The other nodes of the hash_gnode, which receive the forwarded request, will check its validity and store the entry in their db. At this point the node x sends the request to the backup_gnodes with the same procedure. 7.1.5 Endless rest and rebirth The hash_gnode keeps the hostname in an hibernated state for about 3 days since the moment of their registration or update. The expiration time is very long to stabilise the domains. In this way, even if someone attacks a node to steal its domain, it will have to wait 3 days to fully have it. When the expiration time runs out, all the expired hostnames are deleted and substituted with the other in queue. A node has to send an update request for each of its hostnames, each time it changes ip and before the hibernation time expires, in this way it's hostname won't be deleted. The packet of the update request has an id, which is equal to the number of updates already sent. The pkt is also signed with the private key of the node to warrant the true identity of the request. The pkt is sent to any node of the hash_gnode, which will send a copy of the request to the counter_gnode, in order to verify if it is still active and that the entry related to the hostname being updated exists. On the contrary, the update request is rejected. If all it's ok, the node of the hash_gnode broadcasts the update request inside its gnode. The register_node has to send the update request to the backup_gnodes too. If the update request is sent too early it will be considered invalid and will be ignored. 7.1.6 Hash_gnodes mutation If a generical rounded_gnode is overpassed by a new gnode, which is nearer to the hash_gnode, it will exchange its rule with that of the second one, and so the old rounded_gnode is transformed into the new one. This transition takes place passively: when the register_node will update its hostname, will directly contact the new rounded_gnode and since the hostname stored inside the old rounded_gnode is not up to date, they'll be dropped. In the while, when the hostname has not been updated, all the nodes trying to resolve it, will find the new rounded_gnode as the gnode nearest to the hash_gnode and so they'll send the requests to the new gnode. Since the new rounded_gnode doesn't have the database yet, it will ask to the old hash_gnode to let it get its andna_cache related to the hostname to resolve. Once it receives the cache, it will answer the node and in the while it will broadcast, inside its gnode, the just obtained andna_cache. In this way, the registration of that hostname is automatically transfered into the new gnode. In order to avoid a node to take the hostname away from the legitimate owner before the starting of the transfer, all the nodes of the new hash_gnode, will double check a registration request. In this way, they will come to know if that hostname already exists. In case of positive response, they will start the transfer of the andna_cache and they'll add the node asking for the hname registration in queue. 7.1.7 Yaq: Yet another queue Every node is free to choose any hostname, even if the hostname has been already chosen by another node. The node sends a request to the gnode which will keep the hostname, the request is accepted and it is added in the queue, which can have a maximum of MAX_ANDNA_QUEUE (5) elements. The node is associated to the registered hostname and the date of the request is memorized by the hash_node. When the hostname on top of the queue expires, it will be automatically substituted by the second hostname, and so on. A node which wants to resolve the hostname can also request the list of the nodes stored in the andna_queue. In this way, if the first node is unreacheble, it will try to contact the other ones. 7.8 Hostname resolution In order to resolve a hostname the X node has to simply find the hash_gnode related to the hostname itself and randomly send to any node of that gnode the resolution request. 7.8.1 Distributed cache for hostname resolution In order to optimise the resolution of a hostname, a simple strategy is used: a node, each time it resolves a hostname, stores the result in a cache. For each next resolution of the same hostname, the node has already the result in its cache. Since in the resolution packet is written the last time when the hostname has been registered or updated, an entry in the cache expires exactly when that hostname is not valid anymore in ANDNA and has to be updated. The resolved_hnames cache is readable by any node. A node X, exploiting this feature, can ask to any bnode Y randomly choosen insied its same gnode to resolve for itself the given hostname. The bnode Y, will search in its resoved cache the hostname and on negative result the bnode will resolve it in the standard way, sending the result to the node X. These tricks avoid the overload of the hash_gnodes, which keep very famous hostnames. 7.8.2 noituloser emantsoh esreveR If a node wants to know all the related hostnames associated to an ip, it will directly contact the node which possides that ip. 7.9 dns wrapper The work of a DNS requests wrapper will be to send to the ANDNA daemon the hostnames to resolve and to return the IPs associated to them. Thanks to the wrapper it will be possible to use the ANDNA without modifying any preexistent programs: it will be enough to use its own computer as a dns server. See the ANDNS RFC: http://lab.dyne.org/Ntk_andna_and_dns the andna manual: http://netsukuku.freaknet.org/doc/manuals/html/andna.html 7.10 Scattered Name Service Disgregation -- The updated "SNSD" can be found here: http://lab.dyne.org/Ntk_SNSD -- The Scattered Name Service Disgregation is the ANDNA equivalent of the SRV Record of the Internet Domain Name System, which is defined here: http://www.ietf.org/rfc/rfc2782.txt For a brief explanation you can read: http://en.wikipedia.org/wiki/SRV_record SNSD isn't the same of the "SRV Record", in fact, it has its own unique features. With the SNSD it is possible to associate IPs and hostnames to another hostname. Each assigned record has a service number, in this way the IPs and hostnames which have the same service number are grouped in an array. In the resolution request the client will specify the service number too, therefore it will get the record of the specified service number which is associated to the hostname. Example: The node X has registered the hostname "angelica". The default IP of "angelica" is 1.2.3.4. X associates the "depausceve" hostname to the `http' service number (80) of "angelica". X associates the "11.22.33.44" IP to the `ftp' service number (21) of "angelica". When the node Y resolves normally "angelica", it gets 1.2.3.4, but when its web browser tries to resolve it, it asks for the record associated to the `http' service, therefore the resolution will return "depausceve". The browser will resolve "depausceve" and will finally contact the server. When the ftp client of Y will try to resolve "angelica", it will get the "11.22.33.44" IP. The node associated to a SNSD record is called "SNSD node". In this example "depausceve" and 11.22.33.44 are SNSD nodes. The node which registers the records and keeps the registration of the main hostname is always called "register node", but it can also be named "Zero SNSD node", in fact, it corresponds to the most general SNSD record: the service number 0. Note that with the SNSD, the NTK_RFC 0004 will be completely deprecated. 7.10.1 Service, priority and weight number 7.10.1.1 Service number The service number specifies the scope of a SNSD record. The IP associated to the service number `x' will be returned only to a resolution request which has the same service number. A service number is the port number of a specific service. The port of the service can be retrieved from /etc/services. The service number 0 corresponds to a normal ANDNA record. The relative IP will be returned to a general resolution request. 7.10.1.2 Priority The SNSD record has also a priority number. This number specifies the priority of the record inside its service array. The client will contact first the SNSD nodes which have the higher priority, and only if they are unreachable, it will try to contact the other nodes which have a lower priority. 7.10.1.3 Weight The weight number, associated to each SNSD record, is used when there are more than one records which have the same priority number. In this case, this is how the client chooses which record using to contact the servers: The client asks ANDNA the resolution request and it gets, for example, 8 different records. The first record which will be used by the client is chosen in a pseudo-random manner: each record has a probability to be picked, which is proportional to its weight number, therefore the records with the heavier weight are more likely to be picked. Note that if the records have the same priority, then the choice is completely random. It is also possible to use a weight equal to zero to disable a record. The weight number has to be less than 128. 7.10.2 SNSD Registration The registration method of a SNSD record is similar to that described in the NTK_RFC 0004. It is possible to associate up to 16 records to a single hostname. The maximum number of total records which can be registered is 256. The registration of the SNSD records is performed by the same register_node. The hash_node which receives the registration won't contact the counter_node, because the hostname is already registered and it doesn't need to verify anything about it. It has only to check the validity of the signature. The register node can also choose to use an optional SNSD feature to be sure that a SNSD hostname is always associated to its trusted machine. In this case, the register_node needs the ANDNA pubkey of the SNSD node to send a periodical challenge to the node. If the node fails to reply, the register_node will send to ANDNA a delete request for the relative SNSD record. The registration of SNSD records of hostnames which are only queued in the andna_queue is discarded. Practically, the steps necessary to register a SNSD record are: * Modify the /etc/netsukuku/snsd_nodes file. {{{ register_node# cd /etc/netsukuku/ register_node# cat snsd_nodes # # SNSD nodes file # # The format is: # hostname:snsd_hostname:service:priority:weight[:pub_key_file] # or # hostname:snsd_ip:service:priority:weight[:pub_key_file] # # The `pub_key_file' parameter is optional. If you specify it, NetsukukuD will # check periodically `snsd_hostname' and it will verify if it is always the # same machine. If it isn't, the relative snsd will be deleted. # depausceve:pippo:http:1 depausceve:1.2.3.4:21:0 angelica:frenzu:ssh:1:/etc/netsukuku/snsd/frenzu.pubk register_node# register_node# scp frenzu:/usr/share/andna_lcl_keyring snsd/frenzu.pubk }}} * Send a SIGHUP to the NetsukukuD of the register node: {{{ register_node# killall -HUP ntkd # or, alternatively register_node# rc.ntk reload }}} 7.10.2.1 Zero SNSD IP The main IP associated to a normal hostname has these default values: {{{ IP = register_node IP # This value can't be changed service = 0 priority = 16 weight = 1 }}} It is possible to associate other SNSD records in the service 0, but it isn't allowed to change the main IP. The main IP can only be the IP of the register_node. Although it isn't possible to set a different association for the main IP, it can be disabled by setting its weight number to 0. The string used to change the priority and weight value of the main IP is: {{{ hostname:hostname:0:priority:weight # For example: register_node# echo depausceve:depausceve:0:23:12 >> /etc/netsukuku/snsd_nodes }}} 7.10.2.2 SNSD chain Since it is possible to assign different aliases and backup IPs to the zero record, there is the possibility to create a SNSD chain. For example: {{{ depausceve registers: depausceve:80 --> pippo pippo registers: pippo:0 --> frenzu frenzu registers: frenzu:0 --> angelica }}} However the SNSD chains are ignored, only the first resolution is considered valid. Since in the zero service there's always the main IP, the resolution is always performed. In this case ("depausceve:80 --> pippo:0") the resolution will return the main IP of "pippo:0". The reply to a resolution request of service zero, returns always IPs and not hostnames. 8. Heavy Load: flood your ass! The routes set by Netsukuku are created with the nexthop support, which allows a node to reach another node using more than one route simultaneusly (multipath), warranting a balanced sorting of the pkts traffic. The anti-flood shield is a consequence of this multipath routes system, in fact, also when a node is bombed by a continuous and consistent flux of data, it receives that flux subdivided into different routes and links, therefore it is always be able to communicate with other nodes. 9. Spoof the Wired: happy kiddies If a node hooks Netsukuku spoofing an ip, it will obtain nothing simply because no nodes will know how to reach it, as the exact route to reach the true node is already known. Moreover, the rnodes will not allow a hooking an ip which was already present inside the maps. 10. /dev/accessibility The best medium to make the nodes linked each other is, obviously, the wifi, but any kind of links, which connects two nodes can be used for the same purpose. The mobile phones are a great device, where Netsukuku can run. Some of the newest models use Linux as kernel. 11. Internet compatibility Netsukuku cannot instantaneusly spread and it's impossibile to imagine to move from the Internet to Netsukuku immediately. Currently, during its early phase of diffusion, we need to make it compatible with the old Internet and the only way is to temporarily limitate the growing of Netsukuku. A node which uses Netsukuku cannot enter inside the Internet because when ntkd is launched, it can take any random ip and there's an high probability of a collision with an IP address of the Internet. For example it can take the IP 195.169.149.142, but that, in the Internet, is the IP of 195.169.149.142. In order to keep the compatibility with the Internet, Netsukuku has to be restricted to a subclass of ip, so that it doesn't interfere with the normal default classes of the Internet. We use the private A class of ip for the ipv4 and the Site-Local class for the ipv6. The passage from the restricted Netsukuku to the complete one is easy: at the same moment the user decides to abandon the Internet, he will restart NetsukukuD without any options of restriction. Obviously all the other private classes are not influenced, to let the user create a LAN with just one gw/node Netsukuku. 11.1 Private IP classes in restricted mode -- The updated "Restricted IP classes" can be found here: http://lab.dyne.org/Ntk_restricted_ip_classes -- The user can decide to use, in restricted mode, a different private IP class from the default one ( 10.x.x.x ). This is useful if the 10.x.x.x class cannot be used, for example in Russia, it is very popular to provide Internet access through big LANs which use the 10.x.x.x class. The other available classes are: 172.16.0.0 - 172.31.255.255 = 16*2^16 = 1048576 IPs 192.168.0.0 - 192.168.255.255 = 2^16 = 65536 IPs The 192.168.x.x class cannot be used as an alternate restricted mode IP class because it is the default Netsukuku private class, thus the only alternative to 10.x.x.x is the "172.16.0.0 - 172.31.255.255" IP class. However it is adviced to always use the default class. 11.1.1 Netsukuku private classes It necessary to provide at least one private IP class inside Netsukuku to allow the creation of private LANs which are connected to Netsukuku with just one node. The default Netsukuku private class is 192.168.x.x. The random IPs choosen by the nodes will be never one of that class. The default private class is valid both in normal and restricted mode. Only in normal mode the "172.16.0.0 - 172.31.255.255" class becomes private. This class is assigned to very large private networks. The 10.x.x.x class IS NOT private since it is too big and it would be just a waste of IP addresses to use it as a private class. Note also that for each Netsukuku node you can have a private network, therefore with just 16 Netsukuku nodes you can form a private network of 16777216 nodes, which is equivalent to a 10.x.x.x class. 11.1.2 Notes on the restricted mode A node which runs in restricted mode cannot be compatible with normal mode nodes, for this reason a restricted node will drop any packets coming from a normal node. While in restricted mode the "172.16.0.0 - 172.31.255.255" class IS NOT private. In restricted mode, when two different networks which use different private classes (say 10.x.x.x and 192.168.x.x) are linked, nothing happens and they will not rehook, this is necessary because it's assumed that the specified private class is the only choice the user can utilize. This leds to some problems, consider this scenario: 10.0.0.0 <-> 172.16.0.0 In this case the rehook isn't launched, so it is possible that there will be a lot of collision. 11.2 Internet Gateway Search -- The updated "Internet Gateway Search" can be found here: http://lab.dyne.org/Ntk_IGS -- If the nodes are in restricted mode (compatibility with the Internet), they should share their Internet connection. This can be easily done, in fact, if a node X, connected to the Internet, activates the masquerading, it is possible for the other nodes to connect by setting as the default gateway their rnode which lead to the node X. This can be automated by Netsukuku itself and it requires small changes in the code: it is just necessary that the nodes connected to the Internet set a flag in the qspn_pkt, in this way the other nodes will know the routes to reach the Internet. 11.2.1 Multi-gateways The situation becomes a little complex when there is more than one node which shares its internet connection. Let's consider this scenario: A(gw) B(gw) \ / \___ ___/ \/ Ntk nodes (10.x.x.x) A and B are nodes which shares their internet connection, we call them gateways. Let's call X the node which wants to connect to an Internet host. In this case, the nodes near A, might find useful to use A itself to reach the Internet, the same happens for the nodes near B. Instead, the nodes in the middle don't know what is the best choice and they might continuosly change their gw. This means that a tcp connection (to an inet host), which was established trough A, when is then routed trough B dies because A and B have different public IPs on the Internet. The node X has to create an IPIP tunnel to the gateway it wants to use, and set as default gw the tunnel. In this way, the node X is sure to always use the same gateway while the routing of the packets between it and the gw is made transparently by the other Netsukuku nodes. 11.2.1.1 Anti loop multi-inet_gw shield An inet-gw is a normal node like all the other, therefore it can use the Internet connections of the other inet-gws in conjunction with its own one. Consider the previous scenario, A and B are two inet-gw. A sets in his internet default route the adsl modem and B. B does the same, but sets A as the second default route. What would happen if the default route, written in the routing cache of A, is B and, at the same time, the default route set in the routing cache of B is A? The packets would jump endlessy in a infinite loop loosing themself forever. That's why we need the "anti loop multi-inet_gw shield". It's working way is simple: each inet-gw has a netfilter rule which marks all the packets coming from the outside and directed to the Internet. These packets are then routed directly to the Internet without being sent, again, to an inet-gw. In the example: A wants to send a packet to the Internet and its looks in its routing cache. It decide to forward the packet to B. B receives the packet, recognizes it is an extern packet directed to the Internet and shoots it on its modem. 11.2.2 Load sharing Let's consider the previous scenario. The node X can also decide to use both A and B to reach the Internet, using at the same time their connections! Even the gw A can use at the same time its own line and the connection of the gw B. The procedure to implement this is what follows: * X creates a tunnel to A and another one to B * X adds in the routing table the default route using A and B as multipath gateways. The gateway for the connections is chosen randomly. * X adds a rule in the routing table to route all the packets of established connections trough the same gateway used to create the same connection. The rule is linked to some netfilter rules which track and mark each connection. The method is described in details here: https://lists.netfilter.org/pipermail/netfilter/2006-March/065005.html 11.2.3 The bad The implementation of the Load sharing is very Linux specific, so it will be very difficult to port it to other kernels, therefore this feature will be available only to nodes which run Linux (ehi, one more reason to use Linux ;). 11.2.4 MASQUERADING Each node sharing the Internet connection (inet-gw) has to masquerade its interfaces, so iptables must be used. In order to keep the daemon portable, NetsukukuD will launch the script found at /etc/netsukuku/masquerade.sh, which in Linux will be a simple script that executes "iptables -A POSTROUTING -t nat -j MASQUERADE". When NetsukukuD is closed the added firewall rules are flushed with "/etc/netsukuku/masquerade.sh close" 11.2.5 Traffic shaping The inet-gw can also shape its internet connection in order to prioritize its local outgoing traffic (the traffic coming from its 192.168.x.x LAN). In this way, even if it shares its Internet connection, it won't notice any difference 'cause it will have the first priority. Moreover with the traffic shaper, the inet-gw can also prioritize some protocol, i.e. SSH. The traffic shaper will activated at the start of NetsukukuD. The daemon will run the /etc/netsukuku/tc_shaper.sh script, which in Linux utilizes the iproute2 userspace utility. When the daemon is closed the traffic shaping will be disabled with "/etc/netsukuku/tc_shaper.sh close". 11.2.6 Sharing willingness If your ISP isn't very kind, it might decide to ban you because your sharing your Internet connection. It's a pity, but it is for your ISP, not for you, that's because probably someone is also sharing its Inet connection and you can use it too. What if you want to be completely sure that you'll have a backup connection? An idea would be to share your Inet connection only when you're sure that you can reach someone which is doing the same. In this way you won't share it when you are still alone in your area and you can't contact other Netsukuku nodes. This is a good compromise: until another node doesn't guarantees you a backup connection, you won't share your. This can be done automatically by activating the `share_on_backup' option in netsukuku.conf. NetsukukuD will start to share your Internet connection _only_ when it will be in contact with another node which is sharing, or it is willingly to share, its own connection. 11.2.7 See also For more information on the necessity of using ipip tunnels in an adhoc network used to share internet connections, you can read this paper: http://www.olsr.org/docs/XA-OLSR-paper-for-ICC04.pdf 12. Implementation: let's code The Netsukuku protocol isn't low-level, 'cause all it has to do is to set the routes in the routing table of the kernel, therefore the daemon NetsukukuD runs in userspace. All the system is, in fact, maintained by the daemon, which runs on every node. NetsukukuD communicates with the other nodes using the tcp and the udp ad sets the routes in the kernel table. All the code is written in C and is well commented, thus it should be easy to follow the flux of the program, but, before reading a .c is adviced to peep the relative .h. The code in netsukuku.c launches the main threads. Every port listened by NetsukukuD is owned by a daemon, which runs as a single thread. The used ports are the 269-udp , 269-tcp, 271-udp, 277-udp, 277-tcp. All the packets received by the daemons are filtered by accept.c and request.c, which avoid flood attacks using a small table. (accept.c is the same code used to patch the user-level-denial-of-service OpenSSH vulnerability). Secondly, the packets are given to pkts.c/pkt_exec(). When all the daemons are up and running, hook.c/netsukuku_hook(), which is the code used to hook at Netsukuku, is called. Hook.c will launch the first radar scan calling radar.c/radar_scan(). The radar_scan thread will then launch a radar scan every MAX_RADAR_WAIT seconds. When radar_update_map() notices a change in its rnodes, it sends a new qspn_close with qspn.c/qspn_send(). All the code relative to the qspn and the tracer_pkts is in qspn.c and tracer.c The ANDNA code was subdivided in andna_cache.c. which contains all the functions used to manage the caches and in andna.c, where the code for the ANDNA packets is written. The sockets, sockaddr, connect, recv(), send, etc... are all in inet.c and are mainly utilsed by pkts.c. Pkts.c is the code which receives the requests with pkt_exec() and sends them with send_rq(), a front end used to packet and send the majority of requests. Ipv6-gmp.c makes use of GMP (GNU multiple precision arithmetic library) in order to manipulate the 16 bytes of the ipv6, considering them as a unique big number. That is essential for some formulas, which modify directly the ip to know many information, in fact, in Netsukuku, an ip is truly a number. The code for the kernel interface, used to set the routes in the routing table and to configure a network interface is in: krnl_route.c, if.c, ll_map.c, krnl_rule.c, libnetlink.c. Route.c is the middleman between the code of the Netsukuku protocol and the functions which communicates with the kernel. The cares of the internal map are up to map.c. All the other maps are based on it and they are: bmap.c for the border node map. gmap.c for the external maps. In order to compile the Netsukuku code, it isn't necessary to use autoconf, automake and the others, but it's just needed the handy scons (http://www.scons.org). The latest version of the code is always available on the hinezumilabs cvs: cvs -d :pserver:anoncvs@hinezumilabs.org:/home/cvsroot login or give a look on the online web cvs: http://cvs.netsukuku.org/ 13. What to do - Testing on large Netsukuku and ANDNA. - Complete what is in src/TODO. - Code, code and code. - Something else is always necessary. If you wants to get on board, just blow a whistle. 14. The smoked ones who made Netsukuku Main theory and documentation: Andrea Lo Pumo aka AlpT The NTK_RFC 0006 "Andna and dns": Federico Tomassini aka Efphe The NTK_RFC 0001 "Gnode contiguity": Andrea Lo Pumo aka AlpT Enzo Nicosia aka Katolaz Andrea Milazzo aka Mancausoft Emanuele Cammarata aka U scinziatu Special thanks to: Valvoline the non-existent entity for the implementation advices, Newmark, the hibernated guy who helped in some ANDNA problems, Crash aka "il nipponico bionico" who takes BSD, breathes the 2.4Ghz and worship the great Disagio, Tomak aka "il magnanimo" who watches everything with his crypto eyes and talks in the unrandomish slang, Asbesto aka "l'iniziatore" who lives to destroy the old to build the new, Nirvana who exists everywhere to bring peace in your data, Ram aka "il maledetto poeta" who builds streams of null filled with the infinite, Quest who taught me to look in the Code, Martin, the immortal coder and our beloved father, Elibus, the eternal packet present in your lines, Pallotron, the biatomic super AI used to build stream of consciousness, Entropika, the Great Mother of Enea, Uscinziatu, the attentive, Shezzan, the holy bard of the two worlds, Katolaz, Gamel, ... the list goes on... V C G R A N Q E M P N E T S U K and finally thanks to all the Freaknet Medialab whose we are all part, and the poetry Poetry Hacklab About the translator of this document, you have to thank this great guy: Salahuddin, the hurd-nipponese old british one, which is always joyful. -- This file is part of Netsukuku. This text is free documentation; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. For more information read the COPYING file.