Lease requirements (applies to both IPv4 and IPv6):
- L1. MUST support:
- L1.1 IPv4 addresses (yaddr field),
- L1.2 non-temporary IPv6 addresses (IA_NA option),
- L1.3 temporary IPv6 addresses (IA_TA option),
- L1.4 IPv6 Prefixes (IA_PD option);
- L2. MUST allow lease information storage and manipulation ("crud" approach: create, read, update, delete);
- L3. MUST allow interrogation and manipulation of the lease by external tools while the server is operating;
- L4. MUST allow lease reservation for specific hosts;
- L5. Lease reservation MUST be flexible, i.e. based on DUID, client MAC, relay options, other options vendor-specific options etc. or combinations of thereof;
- L6. It must be possible to store DHCP options with the lease (e.g. subscriber-id, relay-id and other options);
- L6.1 The number of options that can be associated with the lease MUST NOT be limited;
- L6.2 No restrictions must exist on the types of options and their data;
- L6.3 It MUST be possible to store multiple options of the same type with a particular lease. This will be used for DHCPv6. The DHCPv4 specification says that the server MUST concatenate option instances. The most obvious example is several instances of the same option (e.g. remote-id) added by several DHCPv6 relays.
- L6.4 MUST be able to store user-defined options (not part of the current work)
- P1. MUST allow pool configuration storage and manipulation;
- P2. MUST support large pools on small memory devices (e.g. IPv6 /56 prefix or 10.0.0.0/8 for IPv4 on low-end CPEs);
- P3. Number of pools MUST NOT be limited (i.e. limited only by available memory);
- P4. MUST allow interrogation and manipulation of the pools by external tools while the server is operating;
- P5. MUST allow pool selection for new clients;
- P6. Each pool MUST be assigned unique id;
- H1. It MUST be possible to reserve a fixed-lease for specific host (fixed-address, fixed-address6 or fixed-prefix6).
- H2. It MUST be possible to provision different options for selected hosts. It MUST be possible to specify this on per-host basis.
DNS Update requirements:
- S1. MUST scale to many cores (including many worker threads or processes)
- S2. MUST be able to support concurrent read/write access from multiple processes
- S3. MUST be able to work with different databases (scaling from small, e.g. sqlite to medium e.g. Postgres, MySQL, Oracle to large e.g. cassandra, hadoop). Note that this is a requirement for the API itself, it does not guarantee that all back-ends will behave reasonably all time, e.g. storing 1 million leases in sqlite may be a bad idea.
- M1. timestamps MUST have at least 1 second accuracy. Greater resolution will be required for client storage to handle degraded (i.e. 2 seconds) leases;
- M2. MAY allow to view/update by existing tools, like cfgmgr in BIND10 or sql clients (This is not a separate requirement, but rather a guideline: if there are two equally favorable solutions available, pick the one that can be used by existing tools). This API will not support OMAPI.
- M3. MUST be able to store user-defined options (not part of the current work)
- M4. Database scheme MUST be enumerated. We acknowledge that there will be DB format changes (e.g. when adding v6-failover related information). With each format upgrade, we will need to provide a upgrade mechanism.
- M5. API MUST offer both programmatic (via an externally-exposed API) and administrative ability to change leases.
- M6. API itself MUST have enumerated version as well. It MUST provide a way to query API version.