Kea Client Requirements

This page was created as part of a hackathon in Prague during IETF'99. This is very early version and it will change significantly.


  • MUST support v4 (RFC2131)
  • MUST support v6 (RFC3315bis)
  • MUST strictly follow 3315bis
  • SHOULD long term goal of being a reference implementation, short term no
  • SHOULD be able to detect dynamic interfaces and conduct actions when new interface appears (MUST in longterm)
  • SHOULD be able to run duplicate address detection and be able to recover from duplication event
  • MUST be able to receive PD and split it to remaining interfaces (must be able to determine downlink interfaces on its own) (long term)
  • MUST be capable of understanding prefix hint in its configuration, MUST send the prefix to the server and handle the responses, even if the response contains a prefix different than expected.
  • SHOULD add received addresses with dynamic lifetimes
  • MUST support all of the following:
    • call a hook
    • add address on its own (if the hook didn't do it)
    • call external script (via hook)
  • SHOULD be able to detect link flaps and cope with it
  • SHOULD be able to run several copies in parallel on the same physical interface (Rackspace use case), affects file management (everything relative)
  • MUST use configuration in JSON
  • SHOULD support custom options
  • SHOULD support vendor class options
  • MUST support both v4 and v6 in a single process
  • MUST support rewriting /etc/resolv.conf (must support rewriting on its own, calling a script, do both, do neither, hook)
  • SHOULD support stateless configuration
  • MAY be able to obey M and O bits (by default not honored, with obey-ra-bits, they should be)

  • SHOULD support reconfigure (including reconfigure-key)
  • MUST do hooks
  • MAY support CONFIRM (there must be a way to skip Cofirm and start with SOLICIT)
  • SHOULD support DNS Updates
  • MAY request hints (hints are mostly deprecated in 3315bis, except prefix length)
  • SHOULD use bison as parser
  • MUST the binaries should be as small as possible (i.e. push as much as realistically possible to hooks)
  • MUST NOT use log4cplus (just a very rudimentary logging)
  • MUST work out of the box - a big advantage of dibbler praised by many users was that it "just works" out of the box (the defaults were reasonable, it was able to pick the right interfaces and do the right thing on them)
  • Hook: for full PD scenario? upstream side working as client, downstream working as a server. The configuration is pushed via control channel. The received prefix must be split into /64s for every downlink interface.
  • IOT requirement: try to conserve energy (e.g. sleep between transmissions), minimal functionality
  • Client MAY support performing dynamic DNS updates
Last modified 11 months ago Last modified on Jul 25, 2017, 12:17:26 PM