Kea DHCPv6 Design Considerations
  • 09 Apr 2019
  • 4 Minutes to read
  • Contributors
  • Dark
  • PDF

Kea DHCPv6 Design Considerations

  • Dark
  • PDF

The following are some tips for administrators used to running a DHCPv4 server, who are implementing Kea's DHCPv6 server.

Providing IPv6 addresses

  • Prefix delegation is an important part of IPv6; try to provide it to your customers if you can. Prefix delegation enables the service provider to delegate a globally routable IPv6 network to a customer, eliminating the need for a NAT gateway. The customer CPE can then allocate addresses from their delegated network to devices on the customer network.
  • IPv6 addresses are plentiful. Typical address pools are /64. Much smaller pools (such as /96) are generally frowned upon. Kea is capable of handling many leases, so don't worry about configuring large networks.
  • RIPE, the RIR (Regional Internet Registry) for Europe, has published a well-regarded BCOP (Best Current Operational Practices) document concerning IPv6 deployment. This document addresses in more detail the network sizes you should consider for various applications (prefix delegation in particular).

Configuration differences between DHCPv4 and DHCPv6

  • Contrary to DHCPv4, DHCPv6 does not allow you to configure default gateways. This is a protocol property and it is done that way on purpose. Kea cannot provide that information (nor can any other DHCPv6 server). Make sure your routers announce RAs (Route Advertisements) with appropriate information.

  • DHCPv6 addresses have an additional timer, preferred-lifetime. This concept does not exit in DHCPv4.

  • Since practically the number of available IPv6 addresses is infinite, you can use longer lease lifetimes and t1/t2 renewals. Using longer t1 timers decreases DHCP traffic in your network. This may be useful if you are experiencing or are concerned with performance bottlenecks.

  • Many DHCPv4 implementations, such as ISC DHCP, make certain assumptions regarding network topology. For example, to serve subnet via the eth0 interface, it expects there to be some address from the served subnet configured on the local interface. This is generally not required in DHCPv6; therefore, Kea controls this behavior explicitly. If you want directly connected clients to be served from a certain subnet, please add the following to your subnet definition:

"interface": "eth0"
  • Contrary to this, most networks use relayed traffic. DHCPv6 offers several ways to select an appropriate subnet. You can specify the interface-id, which is an arbitrary identifier that relays can insert. Alternatively, you can specify a relay address. This is well-documented in the Kea Administrators' Reference, Section 9.2.18: "DHCPv6 Relays".

Dual-stack issues

  • Running dual-stack on a single device is often tricky. From the protocol perspective the DHCPv4 client and the DHCPv6 client are two independent entities, even when they are on the same machine. Kea has some mechanisms to correlate v4 and v6 information, but this is never seamless.

  • Although this is not a common arrangement, in principle DHCPv4 and DHCPv6 Kea servers can share the same hosts database if you want to do host reservations. This may be useful if you want to maintain some consistency, such as assigning the same hostnames over DHCPv4 and DHCPv6. Running dual-stack in this mode is not very popular, though, so it is not as well-tested in the field as other features.

  • Our prior experience with dual-stack deployments shows that DDNS in a dual-stack environment is complex. Unless you have specific business needs to do otherwise, our general recommendation is to not use DDNS for both protocols.

Associating DHCPv4 and DHCPv6 addresses for the same machine

  • The IPv4 addresses leased via DHCPv4 will be stored in the lease4 table and the DHCPv6 addresses in the lease6 table. It is not possible to combine DHCPv4 and DHCPv6 leases in a single lease table. However, you can easily search for the same hwaddr field in both tables to find the leases assigned to a single machine.
  • A similar approach could be to use the same host reservations table for both DHCPv4 and DHCPv6 servers. This in principle allows you to have a single entry that would describe a dual-stack device identified by a single MAC address.
  • host reservations describe what Kea is expected to assign. This is considered a part of the Kea configuration.

  • leases describe what Kea currently has assigned. This is considered run-time state information. Except in rare corner cases, the leases should match the addresses specified in host reservations.

What about MAC addresses in DHCPv6?

Originally, DHCPv6 didn't have any notion of MAC addresses; DUIDs were supposed to replace them as the basic client identifier. This choice led to some operational problems (such as not being able to tell what the device's DUID was until it was booted up the first time or having different duids on dual-boot or multi-stage devices). As a result, option 79 (also called the client link-layer address) was defined in RFC6939.

Kea stores IPv6 leases in the lease6 table. Because the DUID is fundamental to the DHCPv6 protocol, it can't be replaced. However, Kea will also store MAC addresses as additional information in the lease, if it can obtain a MAC address.

Option 79 may be inserted by DHCPv6 relays. However, relays typically don't include it, unless specifically configured to do so.

Some deployments use other options, such as subscriber-id, to identify clients. But in general the client link-layer option (79) is your best bet if your relays can insert it. There's a nice list of various alternatives in the Kea Administrators' Guide, Section 9.10.

Kea does support option 79, although support is not enabled out of the box. There are several ways that Kea can extract MAC addresses from incoming DHCPv6 packets. Option 79 is one of them. To tell Kea to use option 79, please use the following:

"Dhcp6": {
   "mac-sources": [ "client-link-addr-option" ],

Please consult section 9.10 of the Kea Administrator's Guide, "MAC/Hardware Addresses in DHCPv6" for more information.