Kea DHCPv6 Design Considerations

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 192.0.2.0/24 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.20: "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, some relays don't include it, unless specifically configured to do so, and some relays don't support it at all.

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. Kea will try various other methods to obtain the mac address. These are detailed in section 9.11. MAC/Hardware Addresses in DHCPv6 of the Kea ARM. Kea will try these various methods to obtain the mac address of the client.

While iterating through this list of methods of obtaining a mac address from the incoming packet, Kea stops looking once a mac address is discovered. As noted in the aforementioned section 9.11, it is possible to modify this list, altering the order of the methods that are tried as well as which ones are tried to begin with. Below is shown a configuration example where the order and methods tried are both altered.

"Dhcp6": {
   "mac-sources": [ 
     "client-link-addr-option",
      "remote-id",
      "subscriber-id",
      "ipv6-link-local",
      "duid"
   ],
   ...
}

Here we see that option 79 (client-link-addr-option) will be used first, followed by option 82 sub option 2 (remote-id), RFC 4580 (subscriber-id), the client's ipv6-link-local address which may contain the mac address and finally duid. Omitted were the cable modem specific options of docsis-cmts and docsis-modem since this server was not serving a cable modem network.