A YANG Data Model for DHCPv6 Configuration
Extracted elements (30)
Only DHCPv6 options defined in RFC 8415 are included in this document, and only those requiring operator configuration are modeled. Options whose fields are computed by the server from other configuration inputs (e.g., OPTION_IA_NA) are excluded. Additional options can be added via YANG augmentation of the element modules.
The class-selector function (message classification for provisioning decisions) is intentionally omitted from the server module because research found that while the function is common to all DHCPv6 server implementations, the method for configuring it differs greatly between them. An empty vendor-config container and a class-selector container are provided as augmentation points instead.
The DHCPv6 client module is explicitly not a replacement for DHCPv6-assigned address and parameter configuration; it is intended only for configuration and monitoring of the DHCPv6 client function itself. Stateless DHCP (RFC 8415 Section 6.1) is effectively configured when all address and prefix features (non-temp-addr, temp-addr, prefix-delegation) are disabled.
The relay and client modules import the ietf-interfaces YANG module (RFC 8343) and use interface-refs to associate DHCPv6 functions with specific network interfaces, ensuring consistency with the standard interface management model. All four modules adopt NMDA (RFC 8342), requiring an NMDA-capable NETCONF/RESTCONF server.
Both delete-address-lease and delete-prefix-lease RPCs carry the nacm:default-deny-all extension, meaning access to these operations is denied by default and must be explicitly granted via NETCONF Access Control Model (NACM, RFC 8341) rules.
The status message leaf in RPC outputs MUST NOT be null-terminated, as it is a UTF-8-encoded text string for display to an end user. Per BCP 18, if available, a language identifier should be included in output messages.
Active lease state is exposed as config false (read-only) containers within each address-pool and prefix-pool. Each active-lease entry records leased-address/prefix, client-duid, ia-id, allocation-time, last-renew-rebind, preferred-lifetime, valid-lifetime, T1, T2, and status code.
Address pools are configured with mandatory fields pool-id, pool-prefix, start-address, and end-address (all inet:ipv6 types), plus an optional max-address-utilization threshold (1–100 percent) that triggers the address-pool-utilization-threshold-exceeded notification when exceeded.
Fourteen DHCPv6 options from RFC 8415 are modeled across the four modules: OPTION_ORO (6), OPTION_PREFERENCE (7), OPTION_AUTH (11), OPTION_UNICAST (12), OPTION_RAPID_COMMIT (14), OPTION_USER_CLASS (15), OPTION_VENDOR_CLASS (16), OPTION_VENDOR_OPTS (17), OPTION_INTERFACE_ID (18), OPTION_RECONF_MSG (19), OPTION_RECONF_ACCEPT (20), OPTION_INFORMATION_REFRESH_TIME (32), OPTION_SOL_MAX_RT (82), and OPTION_INF_MAX_RT (83).
Prefix pools are configured with mandatory fields pool-id, pool-prefix, and client-prefix-length (uint8, range 1–128), plus an optional max-pd-space-utilization threshold. They support static host reservations keyed by reserved-prefix.
RFC 9243 defines four YANG modules for DHCPv6 management: ietf-dhcpv6-common (shared typedefs and groupings), ietf-dhcpv6-server, ietf-dhcpv6-relay, and ietf-dhcpv6-client. All modules adopt NMDA (RFC 8342) and are intended for use via NETCONF (RFC 6241) or RESTCONF (RFC 8040).
The client module defines four notifications: invalid-ia-address-detected (ia-id, timers, invalid-address, lifetimes, description), transmission-failed (failure-type enumeration, description), unsuccessful-status-code (server-duid, status code and message), and server-duid-changed (new and previous DUIDs with leafrefs to affected IA leases).
The duid-unstructured typedef represents DUIDs not matching types 1–4. Its pattern constraint inverts the match on '000[1-4].*' to ensure the first 2 octets do not collide with defined DUID types, allowing arbitrary proprietary formats.
The ietf-dhcpv6-client module models client interfaces as a list keyed by if-name, with per-interface client-configured-options (ORO, rapid-commit, user-class, vendor-class, vendor-specific, reconfigure-accept) and separate ia-na, ia-ta, and ia-pd lists, each guarded by individual feature statements and containing read-only lease-state nodes.
The ietf-dhcpv6-relay module models relay interfaces as a list keyed by if-name (an ietf-interfaces interface-ref), with per-interface destination-address list, link-address, relay-options (AUTH and Interface-Id options), statistics counters, and optional prefix-delegation state (pd-leases).
The ietf-dhcpv6-server module models a hierarchical address and prefix allocation structure: a top-level allocation-ranges container holds global resource-config parameters, under which an allocation-range list specifies IPv6 prefixes, and within each range, separate address-pools (guarded by the na-assignment feature) and prefix-pools (guarded by the prefix-delegation feature) are defined.
The OPTION_AUTH (11) Authentication Option is modeled as a shared grouping in ietf-dhcpv6-common, with fields algorithm (uint8), rdm (uint8), replay-detection (uint64), and a protocol choice node supporting conf-token (binary) and rkap (datatype uint8 range 1–2, auth-info-value binary length 16).
The OPTION_RECONF_ACCEPT (20) and OPTION_RAPID_COMMIT (14) options are modeled as presence containers; their mere presence in configuration signals that the option should be sent, avoiding the need for an explicit boolean enable leaf.
The option-sets container allows the server to maintain multiple named groups of DHCPv6 options (referenced by option-set-id leafrefs from allocation-ranges, address-pools, prefix-pools, and host-reservations), enabling different option configurations to be supplied to different client classes or topological segments.
The relay module defines three RPCs for prefix delegation lease management (all guarded by prefix-delegation feature): clear-prefix-entry (removes a single delegated prefix lease), clear-client-prefixes (removes all leases for a client DUID), and clear-interface-prefixes (removes all leases for a relay interface).
The server module defines five YANG notifications: address-pool-utilization-threshold-exceeded (with pool-id, total, max-allocated, and allocated counts), prefix-pool-utilization-threshold-exceeded (similar), invalid-client-detected (message-type, duid, description), decline-received (duid and declined resource list), and non-success-code-sent (duid and status code).
The server module defines two RPCs: delete-address-lease (removes an active address lease by leafref, guarded by na-assignment feature) and delete-prefix-lease (removes an active prefix lease by leafref, guarded by prefix-delegation feature). Both carry nacm:default-deny-all and return an optional localized string message per BCP 18.
Section 6.1 registers four URIs in the 'IETF XML Registry' (RFC 3688): urn:ietf:params:xml:ns:yang:ietf-dhcpv6-common, ietf-dhcpv6-server, ietf-dhcpv6-relay, and ietf-dhcpv6-client, all referencing RFC 9243.
Section 6.2 registers four YANG module names in the 'YANG Module Names' registry (RFC 6020): ietf-dhcpv6-common, ietf-dhcpv6-server, ietf-dhcpv6-relay, and ietf-dhcpv6-client, with their respective namespaces and the reference RFC 9243.
The OPTION_AUTH (11) Authentication Option is modeled to allow configuration of DHCPv6 message authentication (algorithm, replay detection method, and RKAP). Proper use of this option protects against rogue server attacks and Reconfigure message injection; the RKAP protocol case specifically guards against misconfiguration by a malicious DHCP server.
The YANG modules contain data nodes that are sensitive or vulnerable in a network management context. Write access to the dhcpv6-server, dhcpv6-relay, or dhcpv6-client containers allows modification of DHCPv6 service behavior; NACM should be used to limit access. The delete-address/prefix-lease RPCs carry nacm:default-deny-all to restrict administrative operations to authorized principals.
DUID-EN (type 2) is encoded as: 2-octet type field (0x0002), 4-octet IANA Private Enterprise Number, followed by a vendor-assigned unique identifier of arbitrary length. Example: 0002 00007ED9 0CC084D303000912.
DUID-LL (type 3) is encoded as: 2-octet type field (0x0003), 2-octet IANA hardware type, and a variable-length link-layer address without separator characters. Example: 0003 0006 00005E005300.
DUID-LLT (type 1) is encoded as: 2-octet type field (0x0001), 2-octet IANA hardware type, 4-octet creation time (seconds since 2000-01-01 UTC modulo 2^32), and a variable-length link-layer address. Example: 0001 0006 28490058 00005E005300.
DUID-UUID (type 4) is encoded as: 2-octet type field (0x0004) followed by a 16-octet (128-bit) UUID. The total length is fixed at 18 octets. Example: 0004 9f03b182705747e38a1e422910078642.