NTK_RFC 0003

Subject: Internet Gateway Search


This text describes a change to the Npv7. It will be included in the final documentation, so feel free to correct it. But if you want to change the system here described, please contact us first.


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.

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.

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:

gateways. The gateway for the connections is chosen randomly.

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

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 ;).

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"

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".

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


related: ["Netsukuku RFC"]