Difference between revisions of "Bering-uClibc 4.x - User Guide - IPv6 Networking - Configure DHCPv6"

Revision as of 17:48, 1 June 2011

Introduction

While Stateless Autoconfiguration using Radvd 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.

Note: DHCPv6 support for Bering-uClibc 4.x is currently under development and is not yet included as a standard part of Bering-uClibc 4.x. This page is being developed along with the supporting software.

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 two main candidates for DHCPv6 software for Linux and hence for Bering-uClibc 4.x:

• Dibbler, a dedicated IPv6 DHCP server, relay or client.
  • Dibbler seems to provide better diagnostic messages than ISC DHCP when running as a DHCPv6 server.
• 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.

Of these, Dibbler appears to be a better fit alongside existing IP(v4) tools like Dnsmasq, whereas ISC DHCP offers the opportunity of a unified IP(v4) and IPv6 DHCP solution.

We probably need to investigate both of these in order to settle on the best option - Davidmbrooke 17:54, 8 January 2011 (UTC)

After reviewing both options my current preference is for the ISC DHCP server - Davidmbrooke 19:11, 30 May 2011 (UTC)

But now I'm not so sure. DHCPv6 is relatively new and there are different implementations which interpret the RFCs in different ways. I have one IPv6 client which insists on sending a DHCPv6 "SOLICIT" even when AdvManagedFlag is set to "off", and which I cannot get ISC DHCP to grant an address to, but Dibbler works OK. Maybe for now we should include both Packages, and let users decide. I have them both mostly packaged anyway. - Davidmbrooke 17:48, 1 June 2011 (UTC)

General Considerations

As well as, not instead of Radvd

DHCPv6 is not a replacement for Radvd. Router Advertisements 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 Radvd configuration in order to specify that a client should also initiate a DHCPv6 transaction. Depending on the desired behaviour, two Radvd 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.

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. 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.