This module is intended to provide a complete IP level decentralised Internet experience. The 4 motivations below are listed in priority order with the most important being at the top.
VPN shall use operating system calls appropriately, including only one read() after each select(), and treat OS errors as non fatal wherever possible, such as out-of-ram. VPN will be built to survive…
VPN uses GNUnet’s node key infrastructure to generate a unique number per node. There is no central database of nodes or routes. This provides the most trustable anonymity when multiple hops are between you and an adversary.
GNUnet checks that nodes are allowed to use that unique number as it comes from the node’s public key. This helps prevent an adversary spoofing other nodes.
I got around 60ms best latency out of VPN for 40ms raw peer to peer connection. It is intentional that VPN has a low latency by limiting usage of memcpy() etc.
Note that end to end or even link encryption isn’t such a priority here, although it is in use on individual links. This is as the main VPN ideal is to remove registry control on IP rather than to possibly slow the system down more with aggessive encryption
Private ranges in IPv4 are very likely to be in use for important tasks in private networks. Using them here would make VPN unusable for these people.
IPv6 was chosen due to the setting aside of an address range for exactly this purpose in the document RFC4193. I have not seen many other people using this range, so chances are it is unused on your lan. Even if you do use RFC 4193 addresses, such as on a wireless mesh, if you use them as the RFC recommends you are unlikely to conflict with the VPN usage.
In RFC4193 the 40 bits after a 0xfd are supposed to be randomly derived. For security reasons public keys are effectively random, so we take the first 40 bits of the node hash and use it for the node’s prefix. Hopefully this will provide for several million nodes and still remain compliant to the RFC The next 16 bits of the address provide space to identify the network interface or tunnel number. We do not use the lower 64 bits of the address, as that is used when annexing ethernet subnets or other hardware networks to your node.
Routing in VPN is handled by each node initially populating it’s own routing table with a single route to itself, with a hop count of 0. Each node actually maintains 2 routing tables to allow a full routing table to be maintained while the new routing table is being rebuilt. This is because the node scans the routing table of its peers and adds all routes found to an upper limit to its own table. Duplicate routes to the same destination that exit a node via the same tunnel are removed, as we keep the lowest hop count.
This results in a table that has an entry for every accessible node via a given peer. When scanning is done, it becomes the node’s new routing table, which can be read by other nodes to build their routes. At this time routes with a hop count of 2 or more are loaded into the OS routing tables, as a hop count of 0 is an implicit route to self, and a hop count of 1 would represent a route to a peer, and those are added automatically as peers are added.
For the Linux IP stack, the hop count will then become the route metric. Linux will be able to choose a route then, which will usually be the route with the lowest metric, to reach the destination. An arbitary choice can be made if several peers have the same metric to the same destination.
Translation engine based on i18nHTML © 2003, 2004, 2005 Christian Grothoff.