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.
- DHCPv6 is basically an adaptation of DHCP for IPv6. For instance, it does not
use broadcast but instead takes advantage of the
ff02::1:2multicast address to find available DHCP servers on the network.
- Another configuration method for IPv6 hosts is the Router Advertisement (RA) / Router Discovery (RD) couple, commonly referred as SLAAC. Both have the ability to give a full 128 bit IPv6 address to each host on the network, but only DHCPv6 provides information on available recursive DNS servers, so it is impossible to rely only on RA to configure your network today.
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
maya.epita.fr. You can configure this in your
/etc/resolv.conf with the
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 : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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”.
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
sysctl button to
1 to allow RA configuration.
When it comes to RFC 6106 support, all systems are not equal:
Linux has full server-side support with
radvd, so it can emit RA packets with both RDNSS and DNSSL options. For client-side support, there was
rdnssd(now merged in the
ndisc6suite) which could handle RFC 5006 options, and
radnswhich is said to work for Linux and supports full RFC 6106.
FreeBSD will have full RFC 6106 support in the upcoming 9.0 release, with
OpenBSD has no support for RFC 6106 at all, but I’m currently working on a server-side patch for
rtadvd. The code can be found here, in
Edit: The patch has been submitted to the OpenBSD tree.
Windows has no support at all either.