* Distributed DNS64 implementation in Contiki OS

Overview

This sub-project concerns adding DNS64 services to the wireless nodes of a RPL network. These nodes, normally, want to access the IPv4 world, outside the IPv6 RPL network. Assuming that NAT64 services are provided, the nodes only need to know the destination addresses for their traffic to the IPv4 hosts.

Implementation of a distributed DNS64

DNS64 provides these services by translating outgoing DNS queries for AAAA addresses to queries for A addresses, and the incoming answers for A addresses to answers for AAAA addresses instead, based on the corresponding  NAT64 prefix information.

We implemented an extension in the Contiki resolv client, that provides this translation. However, instead of setting up a single DNS64 server at the border router (or any other point in the RPL sub-net), we implement the DNS64 translation in a DISTRIBUTED way, so each node performs the DNS64 translations, and sends out already prepared queries for A addresses. 

To favor a zero-configuration architecture, nodes resolve the address of the outgoing DNS server by querying for a local name in the RPL tree, using MDNS multi-cast services. For example, they can query for "contiki-dns.domain.org", and the respective host will reply with the IPv6 address.

The last step is to resolve the NAT64 prefix for the translation. This is done by inspecting the above answer, about the DNS server: the 96bit prefix can be extracted from the address of the DNS server.

The following picture illustrates the scenario:

mDNS for configuration multi-cast

mDNS is applied for forwarding network configuration to all the hosts in the RPL network. The implementation in Contiki OS has been extended, in order to include Network-wide configuration parameters in mDNS responses. 

In particular, we propagate the NAT64, DNS64 configuration using mDNS multi-casting on all IPv6 RPL hosts. In addition, we implement a distributed protocol for announcing and querying for mDNS services, that aims a minimizing the traffic overhead, while providing configuration services to all network hosts.

The outcome is a RPL network, where nodes do not need further configuration for handling outgoing traffic, as long as they are able to intercept DIO messages from joined RPL hosts.