|
|
# Requirements for Host Reservations in Kea
|
|
|
|
|
|
## Introduction
|
|
|
Host Reservations (HR) is a DHCP server feature which allows for creating static assignments of resources to nodes running DHCP clients. The resources include IP addresses, delegated prefixes, hostnames, specific DHCP options etc.
|
|
|
|
|
|
A "static" resource is a resource assigned to a client until the assignment is removed from the server configuration. Such resources are reserved for exclusive use of a client even if the client is offline and doesn't communicate with a server.
|
|
|
|
|
|
## Related documents
|
|
|
The design document describing implementation of the requirements is available [here]((implemented designs/host reservation).
|
|
|
|
|
|
## Scope
|
|
|
This document includes all requirements for Host Reservations in Kea, including those that were implemented for Kea 0.9.1, Kea 1.0.0 and those that are planned for Kea 1.1.0.
|
|
|
|
|
|
## Terminology
|
|
|
- '''Resource''': an IP address, prefix, hostname, option value or any other explicit value assigned to a selected client.
|
|
|
- '''Reservation''': an assignment of a set of resources to a client connected to a particular subnet.
|
|
|
- '''Resolving conflicts''': in the context of HR, it describes the server dealing with the situation when an administrator created a reservation for a client for a resource which is currently in use by another client. The server resolves the conflict by assigning a different (unreserved) resource to the client holding a reserved resource. Then, it assigns the reserved resource to a client for which the reservation was made. Due to periodic nature of lease renewals and communication between clients and servers, the server is usually unable to resolve the conflict when the conflict is detected. It likely needs to wait for a client to inititiate communication with a server to start conflict resolution.
|
|
|
|
|
|
## Requirements for DSL network
|
|
|
We recently decided to start supporting host reservations in DSL networks. Those reservations are typically done using Circuit-ID (code 1) or Remote-ID (code 2), both being sub-options of the option 82 (RAI, or Relay Agent Information option). We determined that reservations by circuit-Id are urgently required. Reservations by remote-id are not urgent, but we did receive requests to support those reservations, too. Requirements urgently needed are marked as (DSL phase 1), while other features that are not urgent are designated (DSL phase 2).
|
|
|
|
|
|
Thomas suggested that we could develop a generic identification mechanism that would work in similar way to client classification. Let's call this approach custom This is a powerful, but complex feature. Pending future discussion, this may be in or out of scope for Kea 1.1. Therefore it's currently marked as MAY.
|
|
|
|
|
|
## General Requirements
|
|
|
1. MUST be supported by both DHCPv4 and DHCPv6 server.
|
|
|
1. MUST allow for creating reservations in a server configuration file.
|
|
|
1. MUST allow for creating reservations in a MySQL database.
|
|
|
1. MUST allow for creating reservations in a PostgreSQL database.
|
|
|
1. MUST allow for configuring the server to use reservations specified in a configuration file and one of the supported SQL databases (MySQL or PostgreSQL) at the same time.
|
|
|
1. MUST allow for configuring the server to use reservations specified in a configuration file only.
|
|
|
|
|
|
## DHCPv4 & DHCPv6 Requirements
|
|
|
1. MUST allow for creating a reservation for a hostname for a particular subnet.
|
|
|
1. MUST allow for creating reservation for a set of specific DHCP options to be handed out to a client belonging to a specific subnet.
|
|
|
1. MUST allow for creating multiple reservations of the same resource type for a single client, assuming that each reservation for a given resource type is specified for a different subnet.
|
|
|
1. MUST allow for creating a reservation using client's MAC address.
|
|
|
1. MUST allow for creating a reservation using client's DUID.
|
|
|
1. MUST allow for specifying names of client classes for a particular reservation for a subnet.
|
|
|
1. MUST allow for creating a reservation using Remote-ID value inserted by a relay agent (DSL phase 2).
|
|
|
1. MAY allow for creating a reservation using Subscriber-ID value inserted by a relay agent (DSL phase 2).
|
|
|
1. MAY allow for creating a reservation using custom expression.
|
|
|
|
|
|
## DHCPv4 Requirements
|
|
|
1. MUST allow for creating reservation for an IPv4 address.
|
|
|
1. MUST allow for creating a reservation for a subnet using client identifier option.
|
|
|
1. MUST allow for creating a reservation for siaddr, sname and file fields of a DHCPv4 message.
|
|
|
1. MUST allow for creating a reservation for a subnet using Circuit-ID value inserted by a relay agent (DSL phase 1).
|
|
|
1. MUST resolve conflicts when IPv4 address reserved for a client is in use by another client.
|
|
|
|
|
|
## DHCPv6 Requirements
|
|
|
1. MUST allow for creating a reservation for a subnet using Interface-ID value inserted by a relay agent.
|
|
|
1. MUST allow for creating reservation for multiple IPv6 addresses for a single client within a particular subnet.
|
|
|
1. MUST allow for creating reservation for multiple IPv6 prefixes (prefix delegation) for a single client within a particular subnet.
|
|
|
1. MUST allow for reserving multiple addresses or delegated prefixes to be sent in a single IA.
|
|
|
1. MUST allow for reserving multiple addresses or delegated prefixes to be sent in multiple/separate IAs.
|
|
|
1. MUST resolve conflicts when IPv6 address and/or delegated prefix reserved for a client is in use by another client. |