int $0x80 Your daily work interruption

Rfc 6106 Dns Configuration For Ipv6 Slaac

20 Aug 2011

Bringing IPv6 internet access in your home network when your ISP just routes your IPv4 packets is fairly simple today, thanks the various tunnel brokers like Hurricane Electric or SixXS. Once you have set up your tunnel, the next step is to configure your hosts to get an IPv6 address and a recursive DNS server and you're done.

Manual configuration can be a viable option for some specific use cases, but most networks will use either DHCPv6, stateless address autoconfiguration (SLAAC), or both.

RFC 5006, published in September 2007 was a first attempt to overcome this issue. The proposed idea was to add an option to RA packets, containing a list of recursive DNS servers so hosts, after getting their IPv6 address configured, could updated their local DNS server database (/etc/resolv.conf on most Unix systems) accordingly. RFC 6106, published in November 2010 is an extension to the original RFC 5006 and thus, obsoletes it.

Options introduced by RFC 6106

RDNSS: Recursive DNS Server option

This options is basically the same that was presented in RFC 5006. As said before, it provides each host with a list of recursive DNS servers with their associated lifetime.

The format of the option is as follows:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Lifetime                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:            Addresses of IPv6 Recursive DNS Servers            :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DNSSL: DNS Search List option

This RFC also adds an option that was not present in the original RFC 5006, the ability to give hosts a search list. Search lists are the thing that allow you to specify only the host name of a machine and skip the domain name. For example, if I am in EPITA's network and I want to ssh on a machine called maya, a correctly configured search list allows me to type ssh maya instead of ssh maya.epita.fr. You can configure this in your /etc/resolv.conf with the domain and search keywords.

The format of this option is similar to RDNSS options:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Lifetime                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:                Domain Names of DNS Search List                :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Problems

This RFC comes with its set of problems, mostly related to implementation in general purpose operating systems. If we take the case of DHCP/DHCPv6, everything is done by a userland daemon that communicates with the server, gets the packets, parses them, and updates addresses of network interfaces and /etc/resolv.conf accordingly. SLAAC does not work exactly the same way. Data received in RA packets is processed in the kernel and addresses are updated from there. This works pretty well with the original specifications of router advertisement, but can cause some problems with options that need to modify files belonging to the userland. As pointed out by section 6 of this RFC, a communication channel must be established between the userland and the kernel to export information about RA packets and allow further processing.

Another problem that can arise, is concurrent access to the local DNS servers database that can cause inconsistency. If we take the example of a dual stacked machine, getting IPv4 information from DHCP and IPv6 information from RA packets, both trying to update /etc/resolv.conf, we have a non-negligible chance to end up with only IPv4 or IPv6 DNS servers. The proposed solution is to use an external tool that can serialize accesses to the file and make both daemons use it.

Another thing we might consider as a problem, is the lack of security measures in these options, but obviously, these are inherited from the assumptions made by IPv6 regarding to local networks. So I'd say this is "nothing new".

Implementation status

Every major operating system (be it Linux, Windows or any BSD) has IPv6 support today and is able to configure its interfaces with information gathered in RA packets. On a Linux system for example, one just needs to set the net.ipv6.conf.all.accept_ra sysctl button to 1 to allow RA configuration.

When it comes to RFC 6106 support, all systems are not equal: