Renzo Davoli

iothnamed is a DNS server/forwarder/cache for the Internet of Threads supporting hash based IPv6 addresses and OTIP, i.e. one time IP.

Hash based IPv6 addresses: The host part of an IPv6 address can be computed as the result of a hash function computer on the fully qualified domain name. This eases the life of system administrators dealing with IPv6 networks.

One Time IP: OTIP means that the current IP address of a server changes periodically to prevent networking attacks. This method has mainly been designed for IPv6 networks.

Hash Based IPv6 address: The configuration of an IPv6 network is a rather daunting and error-prone procedure for system administrators. Each node must be provided with its own (128 bit long) IPv6 address and with a domain name manageable by human beings. Autoconfiguration methods can give addresses to interfaces but do not provide any means of configuring the DNS. So autoconfiguration is suitable for clients. If a host has to act as a server, it must have a fully qualified domain name and the DNS service has to map its name to its IP address. In the Internet of Thread scenario, the number of network nodes can be orders of magnitude higher than before, as each process or thread can be a node. This idea of hash based IPv6 addresses is a viable solution to the problem to manage the DNS resolution in IoTh environments.

One Time IP: Hosting servers use a finite number of IP addresses to connect on the net. Attackers can collect those by wiretapping the network and create a catalog of valid addresses and services in order to attack the servers. OTIP can prevent these attacks, or make them harder to succeed as the addresses collected by network sniffers expire in a short time. OTIP aims to provide one further layer of protection for private services.

Microkernels, partial virtual machines and internet of threads are not unrelated. The challenge of this talk is to show that the new libioth providing an effective and flexible support for the internet of threads can open interesting perspectives for a wider range of applications.

A network protocol stack can be implemented as a library. There are several examples: lwip/lwipv6, picoxnet, lkl. These libraries can be used to implement processes connected as network nodes (the so called "Internet of Thread" processes) or to implement network protocol stack servers for microkernels.

The main goal of libioth is to provide a convenient API to interoperate with different network stack implementations. Libioth is also an infrastructure where the actual implementations can be loaded as plug-ins.

Libioth's API is minimal: it includes the complete set of Berkeley Sockets functions, some functions to add or delete a stack and 'msocket', an extended version of 'socket' providing one more leading argument to select which stack should manage the communication.

Libioth does not provide in its API any specific function to set up the network configuration, e.g. to configure the IP addresses/routes etc. These features are provided through netlink (see RFC3549). "nlinline" is a simple and effective set of inline functions to manage the network configuration.

The data link layer infratructure used by libioth is VDE, Virtual Distributed Ethernet.

Although libioth has been primarily designed for the Internet of Threads, the way it is used in the vunetioth module of vuos has many similarities with the network protocol stack servers for the microkernels.

Several concepts and many building blocks of libioth can be useful in microkernel development. The design of the minimal API itself can be used to reuse existing stack implementations in network protocol stack servers. Libnlq (a sibling project of libioth) is a library able to process netlink requests, and can be used to add the netlink support to those stack implementations providing configuration through a custom specific API.

Other people: Mikey Goldweber

VUOS is a different perspective on namespaces, anykernels and related concepts. The main idea behind VUOS is that it is possible to give processes their own "view" using partial virtual machines.

A partial virtual machine intercepts the system call requests and operates like a filter: system calls can be forwarded to the kernel of the hosting system or processed by the partial virtual machine hypervisor. In this way processes can see a mix of resources provided by the kernel (on which they have the same view of the other processes) and virtual resource. It is possible to mount filesystems, load networking stacks, change the structure of the file system tree, create virtual devices.

The hypervisor is just a user process so while it gives new perspective for processes, it does not widen the attack surface of the kernel.

Would you like a DNS server for IPv6 where adding a new node is as simple as typing in its name? If the answer is yes, try HashDNS.

IPv6 autoconfiguration methods can give addresses to interfaces but do not provide any means of configuring the DNS. So autoconfiguration is suitable for clients. If a host has to act as a server, it must have a fully qualified domain name and the DNS service has to map its name to its IP address.

In the Internet of Thread scenario, the number of network nodes can be orders of magnitude higher than before, as each process or thread can be a node. This idea of hash based IPv6 addresses is a viable solution to the problem to manage the DNS resolution in IoTh environments.

The host part of an IPv6 address can be computed as the result of a hash function computer on the fully qualified domain name.

In this way it is possible to write a DNS server able to resolve the addresses of any hostname in a sub-domain provided the network prefix of that sub-domain.

The installation of a new node of the network (computer, namespace, IoTh process) is as simple as providing it with its IPv6 address (the one obtained by concatenating the network prefix and the host address computed by the hash function).

There is no need to change the configuration of the DNS.

Actually the installation of a new node (or its renaming) is even simpler than that. The host can use a DHCP service designed to get the right address from the DNS server given its fully qualified domain name.

So a system administrator has nothing to do more than assigning the new node its name. (They have just to baptize the new node)

vSwitches, vRouter, vGateway can be transparently deployed on the hosts of a LAN using VDE based Networks of Namespaces (NoN).

A Network of Namespaces (NoN) interconnects network namespaces running on different hosts as if they were on the same (virtual) Local Area Network. It is possible to set up and maintain NoN using VLANs, veth, kernel bridge definitions,… but it would be a daunting work for system administrators.

VXVDE and VXVDEX implement zero-configuration NoN. Starting a namespace connected to a NoN it is as simple as typing a command like: “vdens vxvde://“. This new approach is fast (about the same performance figures of VXLAN’s kernel implementation) and it runs on vanilla Linux kernels.

Several protection features can be added to support different usage scenarios: VXVDEX provides NoN with access control, and the agnostic encryption (meta) plugin can protect any kind of VDE implementation from eavesdropping.

The new VDEplug code now supports a URL-like syntax to define the virtual networking system to use. While it is backward compatible, and it is supported by many VM (kvm/qemu, virtualbox, user-mode linux, umview), now it is possible to add the compatibility layer for current and future virtual networking environments.

Currently VDEplug supports: legacy VDE, point-to-point AF_UNIX or UDP, tap, vxlan, vxvde, slirp.

In the developing phase of the slirp plugin, we have implemented a general purpose slirp library (derived from qemu's slirp implementation).

VDEplug4 together with new tools for the management of namespaces and capability create a new ecosystem for the support of virtual networking.

VXVDE does not require any program to dispatch packets: vxvde has been implemented as a module of the libvdeplug library. It does not need any infrustructure other than a well configured IPv4 or IPv6 network supporting IP multicast. VXVDE has a very simple configuration. A valid IP multicast address is enough to configure a "switchless switched" virtual network.

Unlike VXLAN, VXVDE does not require any Virtual Tunnel End Point (VTEP). Virtual Machines manage their own access to the virtual network. VXVDE unicast packets are mapped on UDP packets traveling on a direct path from the sending virtual machine to the receiving one, without any copy, any packet retransmission or extra header.

VirtualSquare community has created a number of tools for virtuality: VDE, View-OS, PureLibC, LWIPv6, etc. An entire new generation of our tools is being designed. This seminar will provide a preview on new developments and new features.

News ideas and tools will be presented during this seminar: - modular libvdeplug - vde-vxlan - parallel ptracing - ... and many others (all those which will be demo-able in time for the Fosdem date)

The Rbridge concept was introduced by Radia Perlman in her famous paper "Rbridges: Transparent Routing". Rbridges combine the transparency and self-configuration typical of the data-link layer to the packet routing that normally occur at the inter-networking layer. For this reason Rbridges have been defined as devices working at the second and a half layer. Vtrill is an implementation of Rbridges for VDE, a proof-of-concept of the Rbridge definition applied to virtual networking.

There are tons of virtualization projects based on tracing: user-mode linux, umview/kmview, fakeroot-ng, cde. Ptrace is ugly and old but fundamentals tools rely on it: gdb, strace. New tracing facilities like uprobes, lttng and systemtap have been designed mainly (only) for debugging, not for virtualization. In the meanwhile there are new efforts to create more flexible kernels: anykernels and millikernels. These new approaches need a specific support: hooks, hypercall or tracing. It does not matter how we call it. Utrace is (was) an option, with some minor effort at kernel level, even classic ptrace could be implemented at user level for back compatibility. The workshop wants to be a technologically agnostic discussion on tracing supports for virtualization and for new flexible kernels. All contributors of new ideas are welcome to the open discussion.