Kea Testing on IETF93 Hackathon

Kea developers will be participating in the hackathon event organized during the IETF93 in Prague, between July 18-19th. The hackathon agenda and other details may be found on the Hackathon wiki.

The following DHCPv6 "Technologies" will be tested:

  • DHCPv6 Stateful Issues (RFC7550)
  • Secure DHCPv6
  • DHCP Privacy
  • Yang Module for DHCPv6

The following sections describe the details of the Kea setup for testing some of the technologies listed above.

Kea Setup for Testing Against RFC7550

The overview of the technology and high level plan for testing Kea DHCPv6 server and Cisco Prime Network Registrar is available on the Hackathon List Archives.

Environment for Testing DHCP server

The typical setup for testing the DHCP server requires at least two systems, one for running the server, another one for running a client. The client system may have different DHCP clients installed, if they can run on a particular OS. However, some clients require a dedicated OS or are bundled into the specific OS. For this reason, the typical setup may end up including multiple client systems, e.g. one Linux, one Linux and one OS-X system.

In case if running multiple physical machines is not an option, it is recommended to use virtualization, e.g. VirtualBox? (, which is available on many operating systems through software package managers.

A virtual machine (VM) running the server should be connected to at least one "internal" network, but it is recommended to use multiple internal networks through different interfaces to test the scenarios where different DHCP clients belong to different subnets, each subnet served on the different interface. The client VMs should be connected to various "internal" networks, e.g. each client connected to a single internal network.

Note: using the internal network (a network simulated by the virtualization software) isolates the DHCP server from the public (IETF) network to avoid IETF participants obtaining their configuration from the test server.

Building and Installing

In this section we provide the guidelines for setting up the Kea server and testing it against RFC7550.

The support for RFC7550 is currently only available in the prototype Kea implementation on github. Please follow the following link:

to the Kea project on github and fork it, using the "Fork" button in the upper right corner of the page. This requires having a github account. If you don't have an account and you don't want to create it, you should still be able to clone the repository anonymously using the HTTPS URL. However, in this case the repository will be cloned "read-only" and you'll not be able to commit your changes/fixes.

The fork of Kea can be then cloned to your local machine where you wish to run the Kea server, using the following command:

git clone

where "msiodelski" is the user name and should be replaced with your github login.

In order to clone anonymously from the main repository, use the following command:

git clone

For the repositories with the "read-write" permissions it is required to setup the user name and email, as they should appear in the commits log:

git config --local "Marcin Siodelski"
git config --local ""

The prototype implementation of the RFC7550 is available on the "rfc7550" git branch:

git checkout rfc7550

Kea has a couple of dependencies which need to be installed before building Kea. The Introduction section of the Kea Administrator Reference Manual lists both the dependencies and operating systems supported.

The configuration switches used for building Kea are specific to your needs and locations of dependences on your system. The simple command line for building Kea on FreeBSD 10.1 systems are:

autoreconf --install
./configure --prefix=/home/marcin/devel/kea-build --with-gtest --without-werror --with-openssl
make -j8

which intructs to build Kea with the installation directory specified with the "prefix" switch, build with unit tests and use OpenSSL for crypto operations.

When it builds successfully, you can try running unit tests:

make check

Before running the server, it should be installed:

make install

If the build is installed in the directory requiring root privileges, use:

sudo make install

To uninstall Kea use:

make uninstall

or delete the installation directory.

The System Specific Notes page may be useful as a guideline for building Kea on various operating systems. However, some information may be slightly outdated or may refer to a different instance of the Kea git repository. Please use these guidelines with caution.

Running the Server

Kea is shipped with a default configuration file. This configuration file provides no configuration for the subnets or interfaces. It is meant to be a base for writing the actual configuration file, specific to the given deployment.

The default configuration file, however, is useful to test if the Kea software has been built and installed properly. Once the Kea is installed use the default configuration file to test if the server starts up:

cd ~/devel/kea-build
cd sbin
sudo kea-dhcp6 -c ../etc/kea.conf

assuming that the Kea is installed in the home directory, in "devel/kea-build".

The server should start up and output some log messages to the console.


The following is the basic configuration of the DHCPv6 server. The server will listen on two interfaces: "em1" and "em2". Each interface is associated with one subnet, from which the server allocates addresses and prefixes to the clients. This association is made using the "interface" parameter in a subnet declaration. The clients contacting the server via "em1" will be assigned addresses and prefixes from the subnet with the prefix "2001:db8:1::/64", and the clients contacting the server via "em2" will be assigned addresses and prefixes from the subnet with the prefix "2001:db8:2::/64".

The lifetimes and timers are global and thus used by all subnets defined.

The "new-leases-on-renew" parameter is used to disable support for creating new leases for the renewing client, as specified in the RFC7550. A client including an empty IA in the Renew or Rebind message, to request creation of the new bindings for this IA will receive NoBinding status code. When this parameter is set to True, the server will try to create new bindings for this IA.


# DHCPv6 configuration starts here.
# Add names of interfaces to listen on.
  "interfaces-config": {
    "interfaces": [ "em1", "em2"  ]

# Use Memfile lease database backend to store leases in a CSV file.
  "lease-database": {
    "type": "memfile"

# Define leases lifetimes and renewal timers.
  "preferred-lifetime": 300,
  "valid-lifetime": 400,
  "renew-timer": 100,
  "rebind-timer": 200,

# This enables/disables support for requesting new leases while
# renewing existing leases, as per RFC7550.
  "new-leases-on-renew": False,

# The following list defines subnets.
  "subnet6": [
  {    "subnet": "2001:db8:1::/64",
       "pools": [
            "pool": "2001:db8:1::100 - 2001:db8:1::200"
        } ],
        "pd-pools": [
            "prefix": "3001::",
            "prefix-len": 64,
            "delegated-len": 96
        } ],
        "interface": "em1"
  {    "subnet": "2001:db8:2::/64",
       "pools": [
             "pool": "2001:db8:2::100 - 2001:db8:2::200"
        } ],
        "pd-pools": [
            "prefix": "3002::",
            "prefix-len": 64,
            "delegated-len": 96
        } ],
        "interface": "em2"

# Logging configuration starts here.
  "loggers": [
      "name": "kea-dhcp6",
      "output_options": [
             "output": "stdout"
      "severity": "INFO",
      "debuglevel": 0


Most of the test configurations can be derived from this configuration. For example, in order to disable prefix delegation for the particular subnet, the "pd-pools" section should be removed or commented out for this subnet. The client requesting a prefix during the Renew or Rebind should receive NoPrefixAvail status code in this case, if the "new-leases-on-renew" is enabled.

The logger is configured to output log messages to the console. It is possible to direct the log messages to a file. To do so, the value of the "output" parameter should point to the location of the log file.

Also, in most cases it will be useful to use the "DEBUG" severity, instead of "INFO" to see detailed traces from the server.

Forge Automated Testing Tool Setup for Testing Kea Against RFC7550

To start testing Kea with Forge tool it requires two systems, one for DHCP server and second for Forge (which emulates client behavior). Installing DHCP is described in section above but for cooperation with Forge that system needs couple tweaks:

  • bash installed and accessible by /bin/bash
  • sudo - program that allows some users to execute commands as root
  • user account that have rights to use 'sudo' without password (or accessible root account):
    $ visudo
    and add line:
     %<user_name> ALL=(ALL) NOPASSWD: ALL
  • system needs to be accessible via ssh (if you are using root account for testing sshd_config needs to be tweaked to let root login)
    vim /etc/ssh/sshd_config 
    and add/change line:
    PermitRootLogin yes
    service sshd restart

Forge Installation

On the other system we need to setup Forge, to do it first we need to have python 2.7 then get Forge source code:

got clone

and scapy 2.2.0 - packet manipulation tool

tar -xvf scapy-2.2.0-dev.tar.gz
cd scapy-2.2.0-dev
sudo python install

and lettuce - testing environment

tar -xvf lettuce-0.2.19.tar.gz
cd lettuce-0.2.19
sudo python install

and fabric - python ssh module

tar -xvf Fabric-1.8.3.tar.gz
cd Fabric-1.8.3.tar.gz
sudo python install

additional packages, but not required to Forge is: tcpdump

Forge Configuration

  1. Configurations should be started with applying Scapy patch
    (is should be something similar to this: /usr/local/lib/python2.7/dist-packages/scapy/layers/
    cd /forge_source_code/patches/scapy/
    patch -p /scapy_code/ <scapy-2.2.0-dhcp6.patch
  1. Forge needs two separate networks between both systems, one for server management of the DHCP server (via ssh) and one for exchange messages during tests.
  1. In Forge source code copy default config file:
    cp lettuce/features/init_all.py_default lettuce/features/
  1. Last one thing is fill config file with variables according to environment and instructions in config file itself. But because we will test just Kea v6 variables needed would be:
    SHOW_PACKETS_FROM = "both"
    SOFTWARE_UNDER_TEST = "kea6_server",
    PROTO = "v6"
    IFACE = "ethX" 
    CLI_LINK_LOCAL = "" # IPv6 link local address of the ethX
    SERVER_IFACE = "" # server interface connected to IFACE
    SOFTWARE_INSTALL_DIR = "/usr/local/" 
    SRV_IPV6_ADDR_GLOBAL = "" # global IPv6 address of the SERVER_IFACE
    SRV_IPV6_ADDR_LINK_LOCAL = "" # link local IPv6 address of the SERVER_IFACE
    SAVE_LOGS = True
    SAVE_LEASES = True
    Management via ssh:
  1. To check if everything is working just start one of the basic tests:
    sudo ./ -6 -n v6.basic.message.solicit-advertise
  1. For testing RFC 7550 there is prepared feature:

which automatically builds config file presented in "Configuration" section above. To run this test simply start Forge:

sudo ./forge -6 -n 7550_1
Last modified 3 years ago Last modified on Jul 17, 2015, 2:55:52 PM