Wow, Another Routing Protocol -_-

This protocol aims to design a distributed peer to peer network based on the ADN framework. It consists in three parts:

• The link layer, allowing to interact with the kernel
• The relay layer allowing to manage packets between neighbors nodes
• The routing layer allowing to find a route according to the knowledge of the node

This protocol presents the following features:

• It is self addressed: each node is referred using a UserID and duplicates are most of the time allowed.
• Each node routes its own traffic.

Further works should involve a research layer for discovering some routes.

Currently, the protocol allows to tunnel the IP traffic into the WARP network, as a standard VPN does (without the privacy :smile:).

In the following, we will present the protocol inside a simple network with only two devices: an internet gateway and a client. For this purpose, each device has at least a physical interface and a virtual interface each one receiving either IP or WARP trafic.

For a sake of simplicity, instead of using standard names, physical interfaces are denoted by phygw and phycl for the gateway and the client respectively. Similarly, virtual interfaces are referred to as virtgw and virtcl.

Keep in mind that virtual interfaces are used to interact with the kernel. Thus, they only process IP packets. At the opposite, the physicals interface process only WARP packets.

Packet structure

In addition to the payload, a WARP packet contains the following header:

• the remaining route (a tree)
• the route the packet has already taken (a path)

Therefore, assuming the honesty[^1] of every node, the path is apriori still valid and nodes can use it to update their knowledge about the network.

In our implementation, this knowledge is materialized by a graph of nodes. An edge e between two vertices corresponds to a valid link, that will timeout if not involved for too long. This timeout is refreshed each time e is part of the path of any observed packet. Note that a node without any neighbor is discarded.

If you belong to the remaining route, you are supposed to add yourself to the path of the packet and to update its remaining route before relaying it to the next node. In this implementation, relaying consists of broadcasting the packet on the WARP interface.

Obviously, if the node is the last on a route, it should process the packet.

The gateway implementation

Assume the gateway is connected to the internet through its wan interface. Encapsulated IP packets will be sent to virtgw and the traffic should therefore be routed (using a standard NAT) to wan.

The gateway sets an IP address on virtgw (e.g. 10.10.0.1) and chose a subnet that will be the virtual network (in our implementation, the sub-network is 10.10.0.0/24).

The gateway maintains a set of leases, containing an association between the UserID of the connected nodes and their local IP address in the virtual network.

The payload of each packet incoming from WARP should be pushed into virtgw. The kernel will translates the source address and route it into wan. When a packet arrives from wan, the kernel will revert the translations and push the packet into virtgw: the daemon can thus read the translated packet. By examining the destination address, the daemon can recover the corresponding UserID and therefore send the packet over WARP.

The client implementation

After having identified a route to a gateway, the client must first send a RequestLease packet to it, to obtain a local IP address in the virtual network which will be received wrapped into a OfferLease packet.

The client must then set the provided address on virtcl and add a default route sending all the traffic into this interface. The packets can be read by the daemon, then encapsulated inside a WARP packet and sent into phycl to the gateway. At the opposite, when a WARP packet arrives, it is just desencapsulated and the payload is pushed into virtcl.

Bonus: the relay implementation

[^1]: no spoofing, no lying which is clearly utopian but so much simpler !