Bering-uClibc 7.x - User Guide - IPv6 Networking - Configure DHCPv6

IPv6 Networking - Configure DHCPv6
Prev	Bering-uClibc 7.x - User Guide

---

Introduction

While Stateless Autoconfiguration using Router Advertisements is sufficient for some IPv6 networks, DHCPv6 provides a mechanism for better managing which IPv6 addresses get allocated to which clients and permits clients to be automatically informed of DNS servers, NTP servers and other local network resources which would otherwise need to be configured manually.

DHCPv6 is defined by a number of RFCs, most notably RFC 3315.

The most common use case for a Bering-uClibc machine will be acting as a DHCPv6 server while also acting as an IPv6 router, providing a full set of IPv6 services to clients on one or more internal networks. Alternative, but less common use cases will be:

• Acting as a DHCPv6 client
  • Actually, for anyone with a native IPv6 connection, this is rather important to replace dhcpcd.lrp
• Acting as a DHCPv6 relay

DHCPv6 Software Candidates

There are three main candidates for DHCPv6 software for Linux and hence for Bering-uClibc 7.x:

• Dibbler, a dedicated IPv6 DHCP server, relay or client.
  • Note the Dibbler development project has concluded and the original project website (http://klub.com.pl/dhcpv6/) is no longer operational.
  • Version 1.0.1 of the Dibbler software, as included in Bering-uClibc 7.x, was released in 2015 so is now rather old and should generally be avoided.
  • Dibbler seems to provide better diagnostic messages than ISC DHCP when running as a DHCPv6 server.
  • One important use-case for Dibbler remains the hosting of a Prefix Delegation Server which is not supported by dnsmasq, for example.
• ISC DHCP, a generic DHCP solution which includes IP(v4) as well as IPv6 DHCP server and client capabilities.
  • The ISC DHCP server takes command-line arguments which specify either IPv4 (-4) or IPv6 (-6) behaviour. These are mutually exclusive, in other words a dhcpd process can run in either IPv4 mode or IPv6, but not both. Two separate processes must be run in order to support both DHCPv4 and DHCPv6 at the same time.
  • In many ways this is A Good Thing. In particular, it means that dhcpd in IPv6 mode can run alongside an existing IPv4 DHCP server like dnsmasq.
  • The ISC DHCP server supports automatic fail-over between two DHCP server machines.
  • See http://www.ipamworldwide.com/dhcp-options/isc-dhcpv6-options.html for details of the DHCPv6 option syntax.
  • See also http://tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-isc-dhcp.html for more configuration hints.
  • Note that the ISC DHCP Server project declared End of Maintenance for this software at the end of 2022. Users are now directed to the replacement software, ISC Kea but that is not yet available for Bering-uClibc 7.x
• Dnsmasq, the well known IP(v4) DHCP and DNS server.
  • This started to support IPv6 and DHCPv6 at version 2.60.
  • Available from Bering-uClibc 4.3 onwards.
  • Unlike the ISC DHCP server a single dnsmasq process can support IP(v4) as well as IPv6, which makes for a smaller memory footprint.
  • Unlike both other candidates dnsmasq can also provide Router Advertisements and hence replace radvd as well, further reducing system resource requirements.

Of these, Dnsmasq is the preferred solution for Bering-uClibc 4.3 onwards since it provides enough functionality for most users while making efficient use of system resources.

The other alternatives are still supported since they offer more advanced functionality in some cases. DHCPv6 is still relatively new and testing by Davidmbrooke and others has exposed issues with various different DHCPv6 client implementations. In some cases the alternative DHCPv6 server implementations offer better compatibility with particular clients.

General Considerations

As well as, not instead of Router Advertisements

DHCPv6 is not a replacement for Router Advertisements. These are still required, most notably so that the Default IPv6 Gateway can be identified (there is no way to define a Default Gateway using DHCPv6).

It is necessary to slightly change the Router Advertisement configuration in order to specify that a client should also initiate a DHCPv6 transaction. Depending on the desired behaviour, two Router Advertisement configuration settings can be relevant:

• AdvManagedFlag can be used to set the "M" flag in the Router Advertisement, which means that a client should use DHCPv6 to obtain a stateful IPv6 address (and potentially other network settings as well).
• AdvOtherConfigFlag can be used to set the "O" flag in the Router Advertisement, which means that DHCPv6 should be used to obtain other network settings (such as a DNS or NTP server), most likely for use in conjunction with an auto-configured IPv6 address.

The relevant Radvd configuration field must be set to "on" for each interface where DHCPv6 is being used (or the equivalent dnsmasq configuration directive should be selected if dnsmasq is used rather than radvd).

If AdvManagedFlag is set to "on" then implicitly AdvOtherConfigFlag is set to "on" as well. A DHCPv6 client which obtains an IPv6 address via DHCPv6 will also obtain other settings via DHCPv6.

Note: It is legitimate to specify AdvManagedFlag on at the same time as AdvAutonomous on. However, different DHCPv6 clients seem to react differently when this is done and the results can be difficult to predict.

Firewall rules

A DHCPv6 server (or relay) listens on UDP port 547, so if Shorewall6 is being used this must have a Rule to accept traffic on this port for each interface where DHCPv6 is being used.

• This rule is configured automatically if the "dhcp" option is specified for the interface in /etc/shorewall6/interfaces

A DHCPv6 client listens on UDP port 546 so the DHCPv6 server firewall must also be allowed to send to this port and any DHCPv6 client firewall must be allowed to listen on this port.

Dnsmasq

Configuration

The IPv6 entries are simply added to the standard dnsmasq configuration file, /etc/dnsmasq.conf.

Dynamic IPv6 Address Assignment from a Range

To enable basic DHCPv6 dynamic address assignment behaviour add a line like the following (replace 2001:db8:1:1:: with your own IPv6 network address.):

dhcp-range=2001:db8:1:1::10:1, 2001:db8:1:1::10:ffff, 64, 12h

Multiple lines can be added (with different addresses) if you wish to enable Router Advertisements on multiple network interfaces.

Fixed IPv6 Address Assignment based on DUID

Fixed IPv6 addresses cannot be assigned based on MAC address but they can be assigned based on a client's DHCP Unique Identifier (DUID). For example:

dhcp-host=id:00:01:00:01:16:d2:83:fc:92:d4:19:e2:d8:b2, myclient, [2001:db8:1:1::7]

For All DHCPv6 Variants

In order to ensure that Router Advertisements are generated when DHCPv6 is in use un-comment the following line:

enable-ra

This causes dnsmasq to issue Router Advertisements for all interfaces on which DHCPv6 is active. By default these RAs specify that:

• The "Managed" flag is set
  • So DHCPv6 will be used to obtain an IPv6 address
• The "OtherConfig" flag is set
  • So DHCPv6 will be used to obtain other IPv6 configuration settings (e.g. DNS server, NTP server)
• The "Autonomous" flag is not set
  • So a StateLess Automatic Address Configuration (SLAAC) address will not be used

These defaults can be over-ridden by other dnsmasq configuration settings. Refer to the comments in the dnsmasq configuration file for further details.

Once configuration is complete the dnsmasq daemon must be (re)started:

svi dnsmasq restart

Dibbler

The Dibbler download includes source code to build three separate executables:

• dibbler-server which is a regular DHCPv6 server.
• dibbler-relay which is a cut-down server to relay traffic to a DHCPv6 server running on another machine.
• dibbler-client which is a DHCPv6 client.

At this time, only the "server" and "client" are packaged for Bering-uClibc 7.x. The "relay" would be a separate Package, but since Dibbler stopped being developed in 2015 this is not intended to be added.

Dibbler Server

Packages

The "server" capability is available for Bering-uClibc 7.x in the form of the dibbler-server.lrp Package. This depends on libcxx.lrp.

Modules

There are no specific kernel Modules required for Dibbler.

Configuration

The Dibbler server has a single configuration file: /etc/dibbler/server.conf. The initial version included in the dibbler-server.lrp Package is just the standard example from the Dibbler distribution.

The full documentation is available in the user manual, available as dibbler-user.pdf. (Note that this link points to the master configuration management repository for the Dibbler software and might refer to a later version of Dibbler than is packaged for Bering-uClibc 7.x).

The basic structure of /etc/dibbler/server.conf is as follows:

• A header section which contains configuration settings which apply in "global scope".
• A set of per-interface configuration blocks, each of which takes settings in "interface scope".

A very simple example file is shown below:

# Global settings
log-level 8
preference 9
stateless

# Internal network interface
iface "eth1" {
    option lifetime 1800
    option domain private.network
    option dns-server 2001:db8:1:1::1
}

Note in particular the "stateless" setting which indicates that this server should not issue IPv6 address to clients but is only serving "other" (as in AdvOtherConfigFlag) configuration details such as DNS settings. Since this is a global setting it applies to all interfaces. If any interface is serving IPv6 addresses this setting must be removed.

Runtime Files

Log messages are written to file /var/log/dibbler/dibbler-server.log.

The "log-level" specified in the configuration file governs the volume of log output generated.

Other files containing run-time state information are written to the /var/lib/dibbler/ directory.

Debugging

In case of problems, you can run the dibbler-server executable in the foreground, displaying any error messages, with the following command:

dibbler-server run

ISC DHCP

As with Dibbler, the ISC DHCP download includes source code to build three separate executables:

• dhcpd which is a DHCP(v4) or DHCPv6 server.
• dhrelay which is a cut-down server to relay traffic to a DHCP(v4) or DHCPv6 server running on another machine.
• dhclient which is a DHCP(v4) or DHCPv6 client.

Again just as with Dibbler, at this time, only the "server" is packaged for Bering-uClibc 7.x. The "relay" and "client" may be added in the future.

ISC DHCP Server

Packages

The "server" capability is available for Bering-uClibc 7.x in the form of the dhcpd.lrp Package. This name was chosen for compatibility with the Package name used for old, IPv4-only versions of the ISC DHCP code. This Package has no dependencies.

The optional omshell utility (the ISC DHCP server Object Management API shell) is available in the separate omshell.lrp Package.

Modules

There are no specific kernel Modules required for ISC DHCP.

Configuration

TODO

---

Prev

Up