wiki:OldKeaRequirements

Version 2 (modified by tomek, 6 years ago) (diff)

--

Kea (BIND10 DHCP) Requirements

Introduction

This page lists requirements for Kea project. The requirements list has two purposes. First, it is dev team needs to design,implement and fix reported bugs in all those features. Second, QA team needs to prepare and execute tests and report issues in all those features.

This document identifies the areas of testing required to validate already released and currently being developed work. It covers the following phases:

  • as no test plan was produced after the delivery of the "skeleton Kea" at the end of 2011, this document is more comprehensive in that it is a test plan covering all of the functionality of Kea to date.
  • 2012 SoW work (allocation engines, options framework, direct v6, relayed v4)
  • August 2013 work (relayed v6, direct v4, DDNS, hooks)

Note that:

  • There are 2 separate tools for protocol conformance: IxANVL and ISC Forge.
  • The document does not describe the tests in detail - that will be covered elsewhere.
  • Each item is considered a separate requirement (denoted in bold). Each requirement is color coded:
    • red: Tests not ready to run (tests not designed, implementation in progress, environment setup in progress etc);
    • yellow: Tests are being executed, but some of them failing (due to code bugs, test bugs), the health of the feature is not confirmed yet;
    • green: Tests are mostly passing, the only outstanding issues are minor and are not affecting feature readiness. The feature is ready for release.

Kea Requirements (aka Functionality) August 2013

By the end of August 2013, the Kea DHCP server is expected to have the following functionality.

  • BIND 10 Integration
    • Starting/stopping server through BIND 10 mechanisms (b10-integration.startstop)
    • Logging using the BIND 10 logging mechanism (b10-integration.logging)
    • Configuration using the BIND 10 configuration database (b10-integration.configdb)
  • DHCPv4 Features
    • Handle directly connected DHCPv4 clients (v4.direct)
    • Handle remotely (via relay) connected DHCPv4 clients (v4.relay)
    • Allocation of DHCPv4 leases for clients (v4.allocate)
    • Ability to specify multiple subnets for the server to service. (v4.many-subnets)
    • Ability to specify multiple pools of available addresses in each subnet (v4.many-pools)
    • Ability to service a client lease request with an address from one of the pools (v4.inpool)
    • Ability to service a client renew request (v4.renew)
    • Ability to handle lease release (v4.release)
    • Ability to reuse expired lease (v4.expire)
  • DHCPv6 Features
    • Handle directly connected DHCPv6 clients (v6.direct)
    • Handle remotely (via relay) connected DHCPv6 clients (v6.relay)
    • Ability to specify multiple subnets for the server to service (v6.many-subnets)
    • Ability to specify multiple pools of available addresses in each subnet (v6.many-pools)
    • Ability to service a client lease request with an address from one of the pools (v6.inpool)
    • Ability to service a client renew request (v6.renew)
    • Ability to handle lease release (v6.release)
    • Ability to reuse expired lease (v6.expire)
  • Options (both V4 and V6)
    • Selection of standard options available (v4.options, v6.options).
    • Ability to define user-defined options (v4.user-options, v6.user-options)
    • Ability to specify values for standard and user-defined options globally and on a per-subnet basis (v4.subnet-options, v6.subnet-options)
    • Responding with appropriate options (and values) in response to a client requests. ("Appropriate" means responding with options that have been requested by the client.) (v4.prl, v6.oro)
  • Performance tool
    • Able to test DHCPv4 servers (perfdhcp.v4)
    • Able to test DHCPv6 servers (perfdhcp.v6)
    • Able to measure performance for initial v4 handshake (DISCOVER/OFFER) (perfdhcp.do)
    • Able to measure performance for initial v6 handshake (SOLICIT/ADVERTISE) (perfdhcp.sa)
    • Able to measure full v4 four-way (DISCOVER/OFFER/REQUEST/ACK) handshakes. (perfdhcp.dora)
    • Able to measure full v6 four-way (SOLICIT/ADVERTISE/REQUEST/RESPONSE) handshakes. (perfdhcp.sarr)
    • Able to simulate at least 100 clients (perfdhcp.clientcount)
    • Able to send packets at a defined rate and measure both average latency, throughput and drop rate (perfdhcp.ratecontrol)

  • Lease storage
    • All leases stored in a MySQL database (db.mysql)
  • Performance
    • "Adequate" performance. (This is loosely defined as the full-server will be multi-process: the ideal is for a multi-process server to handle up to 3k leases per second.) (performance)
  • DDNS (Detailed list of requirements is maintained in dedicated document.)
    • Kea must be able to update forward DNS entries (A record) for allocated v4 leases (v4.ddns.fwd)
    • Kea must be able to update forward DNS entries (AAAA record) for allocated v6 leases (v6.ddns.fwd)
    • Kea must be able to update reverse DNS entries (PTR record) for allocated v4 leases (v4.ddns.rev)
    • Kea must be able to update reverse DNS entries (PTR record) for allocated v6 leases (v6.ddns.rev)
    • Kea must be able to process S,O,N,E bits properly in DHCPv4 requests (v4.ddns.flags)
    • Kea must be able to process S,O,N bits properly in DHCPv6 requests (v6.ddns.flags)
    • Kea must support more than one DNS server for DHCPv4 and fall back through the list in case of problems (v4.ddns.many-servers)
    • Kea must support more than one DNS server for DHCPv6 and fall back through the list in case of problems (v6.ddns.many-servers)
    • Kea must be able to ignore DHCPv4 client's name (v4.ddns.policy-ignore)
    • Kea must be able to use DHCPv4 client's name as is (v4.ddns.policy-ignore)
    • Kea must be able to add domain name to DHCPv4 client's hostname (v4.ddns.concatenate)
    • Kea must be able to generate procedurally hostname for DHCPv4 client (v4.ddns.concatenate)
    • Kea must be able to ignore DHCPv6 client's name (v6.ddns.policy-ignore)
    • Kea must be able to use DHCPv6 client's name as is (v6.ddns.policy-ignore)
    • Kea must be able to add domain name to DHCPv6 client's hostname (v6.ddns.concatenate)
    • Kea must be able to generate procedurally hostname for DHCPv6 client (v6.ddns.concatenate)
  • Hooks (list of DHCP hooks available here: [DhcpHooks])
    • The ability to use general BIND10 hooks framework (defined [Bind10HooksFramework here]) (hooks.framework)
    • Configure and load external user library that will register callouts for DHCPv4 engine (v4.hooks.load)
    • Configure and load external user library that will register callouts for DHCPv6 engine (v6.hooks.load)
    • Execute callouts from user library during specific DHCPv4 engine events (v4.hooks.execute)
    • Execute callouts from user library during specific DHCPv6 engine events (v6.hooks.execute)
    • Cancel certain actions based of callouts' skip flag status (when allowed for specific v4 hook point) (v4.hooks.skip)
    • Cancel certain actions based of callouts' skip flag status (when allowed for specific v6 hook point) (v6.hooks.skip)
    • Callouts are able to modify data and that modification is used by the DHCPv4 server (v4.hooks.modify)
    • Callouts are able to modify data and that modification is used by the DHCPv6 server (v6.hooks.modify)