wiki:OldKeaRequirements

Version 6 (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 3 separate tools for protocol conformance: IxANVL, TAHI (http://tahi.org) and ISC Forge. They may be used to cover some of those requirements.
  • 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.)
    • update forward DNS entries (A record) for allocated v4 leases (v4.ddns.fwd)
    • update forward DNS entries (AAAA record) for allocated v6 leases (v6.ddns.fwd)
    • update reverse DNS entries (PTR record) for allocated v4 leases (v4.ddns.rev)
    • update reverse DNS entries (PTR record) for allocated v6 leases (v6.ddns.rev)
    • remove DNS entries (A and PTR records) when v4 client releases (v4.ddns.release)
    • remove DNS entries (AAAA and PTR records) when v6 client releases (v6.ddns.release)
    • remove DNS entries (A and PTR records) when v4 lease expires (v4.ddns.expire)
    • remove DNS entries (AAAA and PTR records) when v4 lease expires (v6.ddns.expire)
    • process S,O,N,E bits properly in DHCPv4 requests (v4.ddns.flags)
    • process S,O,N bits properly in DHCPv6 requests (v6.ddns.flags)
    • support more than one DNS server for DHCPv4 and fall back through the list in case of problems (v4.ddns.many-servers)
    • support more than one DNS server for DHCPv6 and fall back through the list in case of problems (v6.ddns.many-servers)
    • be able to ignore DHCPv4 client's name (v4.ddns.policy-ignore)
    • be able to use DHCPv4 client's name as is (v4.ddns.policy-ignore)
    • be able to add domain name to DHCPv4 client's hostname (v4.ddns.concatenate)
    • be able to generate procedurally hostname for DHCPv4 client (v4.ddns.concatenate)
    • be able to ignore DHCPv6 client's name (v6.ddns.policy-ignore)
    • be able to use DHCPv6 client's name as is (v6.ddns.policy-ignore)
    • be able to add domain name to DHCPv6 client's hostname (v6.ddns.concatenate)
    • be able to generate procedurally hostname for DHCPv6 client (v6.ddns.concatenate)
    • Must be able to support conflict resolution (as defined in RFC4703, section 5.3) for A records (v4.ddns.conflict-resolution)
    • Must be able to support conflict resolution (as defined in RFC4703, section 5.3) for AAAA records (v6.ddns.conflict-resolution)
  • Hooks (Useful documents: 1. General Hooks API for BIND10, 2. The list of DHCP-specific hooks)
    • The ability to use general BIND10 hooks framework (defined 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)
  • Prefix Delegation (under consideration, target date November 2013)
    • Parse and generate IA_PD and IAPREFIX options (v6.pd.options)
    • Assign a prefix for requesting router (v6.pd.assign)
    • Renew a prefix for requesting router (v6.pd.renew)
    • Release a prefix for requesting router (v6.pd.release)
    • Configure server to handle prefixes (v6.pd.config)
    • Ability to store PD leases (v6.pd.leases)
    • Ability to handle NA (non-temporary addresses) and PD (prefix delegation) at the same time (v6.pd.na-pd)
    • Ability to have prefix only configuration (v6.pd.no-ia)
    • Ability to respond properly to IA_NA in prefix only configuration (v6.pd.no-ia-response)
    • Ability to have address only configuration (v6.pd.no-pd)
    • Ability to respond properly to IA_PD in addr only configuration (v6.pd.no-ia-response)
  • Demo (under consideration, target date November 2013)
    • Ability to handle IPv4 and IPv6 traffic at the same time (demo.dual-stack1)
    • Ability to handle specific number of dual-stack devices (demo.dual-stack2)
    • Stability: run for specified period of time (demo.stability)