RFC 9243: A YANG Data Model for DHCPv6 Configuration
- I. Farrer, Ed.
Abstract
This document describes YANG data models for the configuration and management of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (RFC 8415) servers, relays, and clients.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
DHCPv6 [RFC8415] is used for supplying configuration and other relevant parameters to clients in IPv6 networks. This document defines YANG [RFC7950] modules for the configuration and management of DHCPv6 'elements' (servers, relays, and clients), using the Network Configuration Protocol (NETCONF) [RFC6241] or RESTCONF [RFC8040].¶
Separate modules are defined for each element. Additionally, a 'common' module contains typedefs and groupings used by all of the element modules. Appendix A provides XML examples for each of the element modules and shows their interaction.¶
The relay and client modules provide configuration that is
applicable to devices' interfaces. This is done by importing the
'ietf
It is worth noting that as DHCPv6 is itself a client configuration protocol, it is not the intention of this document to provide a replacement for the allocation of DHCPv6-assigned addressing and parameters by using NETCONF/YANG. The DHCPv6 client module is intended for the configuration and monitoring of the DHCPv6 client function and does not replace DHCPv6 address and parameter configuration.¶
The YANG modules in this document adopt the Network Management Datastore Architecture (NMDA) [RFC8342].¶
1.1. Scope
[RFC8415] describes the current version of the DHCPv6 base protocol specification. A large number of additional specifications have also been published, extending DHCPv6 element functionality and adding new options. The YANG modules contained in this document do not attempt to capture all of these extensions and additions; rather, they model the DHCPv6 functions and options covered in [RFC8415]. A focus has also been given on the extensibility of the modules so that they are easy to augment to add additional functionality as required by a particular implementation or deployment scenario.¶
1.2. Extensibility of the DHCPv6 Server YANG Module
The modules in this document only attempt to model
DHCPv6-specific behavior and do not cover the configuration
and management of functionality relevant for specific server
implementations
However, it is recognized that implementation
In DHCPv6, the concept of 'class selection' for messages
received by the server is common. This is the identification
and classification of messages based on a number of parameters
so that the correct provisioning information can be supplied,
for example, by allocating a prefix from the correct pool or
supplying a set of options relevant for a specific vendor's
client implementation. During the development of this
document, implementations were researched and the findings
were that while this function is common to all, the method
for configuring and implementing this function differs
greatly. Therefore, configuration of the class selection
function has been omitted from the DHCPv6 server module to
allow implementors to define their own suitable YANG modules.
Appendix D provides an
example of this, which demonstrates how this can be
integrated with the main 'ietf
1.2.1. DHCPv6 Option Definitions
A large number of DHCPv6 options have been created in addition to those defined in [RFC8415]. As implementations differ widely as to which DHCPv6 options they support, the following approach has been taken to defining options: only the DHCPv6 options defined in [RFC8415] are included in this document.¶
Of these, only the options that require operator configuration are modeled. For example, OPTION_IA_NA (3) is created by the DHCP server when requested by the client. The contents of the fields in the option are based on a number of input configuration parameters that the server will apply when it receives the request (e.g., the T1/T2 timers that are relevant for the pool of addresses). As a result, there are no fields that are directly configurable for the option, so it is not modeled.¶
The following table shows the DHCPv6 options that are modeled, the element(s) they are modeled for, and the relevant YANG module names:¶
Further option definitions can be added using additional YANG modules via augmentation of the relevant element modules from this document. Appendix B contains an example module showing how the DHCPv6 option definitions can be extended in this manner. Some guidance on how to write YANG modules for additional DHCPv6 options is also provided.¶
2. Terminology
The reader should be familiar with the YANG data modeling language defined in [RFC7950].¶
The YANG modules in this document adopt NMDA [RFC8342]. The meanings of the symbols used in tree diagrams are defined in [RFC8340].¶
The reader should be familiar with DHCPv6-relevant terminology defined in [RFC8415] and other relevant documents.¶
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
3. DHCPv6 Tree Diagrams
3.1. DHCPv6 Server Tree Diagram
The tree diagram in Figure 1 provides an overview of the DHCPv6 server module. The tree also includes the common functions module defined in Section 4.1.¶
- Descriptions of important nodes:
-
- enabled:
- This enables
/disables the function of the DHCPv6 server.¶ - dhcpv6-server:
- This container holds the server's DHCPv6-specific configuration.¶
- server-duid:
- Each server must have a DHCP Unique
Identifier (DUID) to identify itself to clients. A DUID consists
of a 2-octet type field and an arbitrary length (of no
more than 128 octets) content field. Currently, there are
four DUID types defined in [RFC8415] and
[RFC6355]. The DUID may be configured using
the format for one of these types or using the
'unstructured' format. The DUID type definitions are
imported from the 'ietf
-dhcpv6 -common .yang' module. [IANA -HARDWARE ] and [IANA-PEN] are referenced for the relevant DUID types.¶-TYPES - vendor-config:
- This container is provided as a location
for additional implementation
-specific YANG nodes for the configuration of the device to be augmented. See Appendix C for an example of such a module.¶ - option-sets:
- The server can be configured with multiple option-sets. These are groups of DHCPv6 options with common parameters that may be supplied to clients on request. The 'option-set-id' field is used to reference an option-set elsewhere in the server's configuration.¶
- option-set:
- This holds configuration parameters for DHCPv6
options. The initial set of applicable option definitions
are defined here, and additional options that are also
relevant to the relay and/or client are imported from
the 'ietf
-dhcpv6 -common' module. Where needed, other DHCPv6 option modules can be augmented as they are defined. The complete list of DHCPV6 options is located at [IANA -DHCPV6 ].¶-OPTION -CODES - class-selector:
- This is provided as a location for
additional implementation
-specific YANG nodes for vendor-specific class selector nodes to be augmented. See Appendix D for an example of this.¶ - allocation
-ranges : - A hierarchical model is used
for the allocation of addresses and prefixes. The top-level
'allocation
-ranges' container holds global configuration parameters. Under this, the 'allocation -range' list is used for specifying IPv6 prefixes and additional prefix-specific parameters.¶ - address-pools:
- This is used for Identity Association for Non-temporary Addresses (IA_NA) and Identity Association for Temporary Addresses (IA_TA) pool allocations with a container for defining host reservations. State information about active leases from each pool is also located here.¶
- prefix-pools:
- This defines pools to be used for prefix
delegation to clients. Static host reservations can also
be configured. As prefix delegation is not supported
by all DHCPv6 server implementations
, it is enabled by a feature statement.¶
- Information about RPCs:
-
- delete
-address -lease : - This allows the deletion of a lease for an individual IPv6 address from the server's lease database. Per [BCP18], if available, a language identifier should be included in the output message.¶
- delete
-prefix -lease : - This allows the deletion of a lease for an individual IPv6 prefix from the server's lease database. Per [BCP18], if available, a language identifier should be included in the output message.¶
- delete
- Information about notifications:
-
- address
/prefix -pool -utilization -threshold -exceeded : - This is raised when the number of leased addresses or prefixes in a pool exceeds the configured usage threshold.¶
- invalid
-client -detected : - This is raised when the server detects an invalid client. A description of the error and message type that has generated the notification can be included.¶
- decline
-received : - This is raised when a DHCPv6 Decline message is received from a client.¶
- non
-success -code -sent : - This is raised when there is a status
message for a failure. Status codes are drawn from [IANA
-DHCPV6 ].¶-STATUS -CODES
- address
3.2. DHCPv6 Relay Tree Diagram
The tree diagram in Figure 2 provides an overview of the DHCPv6 relay module. The tree also includes the common functions module defined in Section 4.1.¶
The RPCs in the module are taken from requirements defined in [RFC8987].¶
- Descriptions of important nodes:
-
- enabled:
- This globally enables
/disables all DHCPv6 relay functions.¶ - dhcpv6-relay:
- This container holds the relay's DHCPv6-specific configuration.¶
- relay-if:
- As a relay may have multiple client-facing
interfaces, they are configured in a list. The 'if-name' leaf
is the key and is an interface-ref to the applicable
interface defined by the 'ietf
-interfaces' YANG module.¶ - enabled:
- This enables
/disables all DHCPv6 relay functions for the specific interface.¶ - destination
-addresses : - This defines a list of IPv6 addresses that client messages will be relayed to, which may include unicast or multicast addresses.¶
- link-address:
- This configures the value that the relay will put into the link-address field of Relay-Forward messages.¶
- prefix
-delegation : - As prefix delegation is not
supported by all DHCPv6 relay implementations
, it is enabled by this feature statement where required.¶ - pd-leases:
- This contains read-only nodes for holding information about active delegated prefix leases.¶
- relay-options:
- This holds configuration parameters for DHCPv6
options that can be sent by the relay. The initial set of
applicable option definitions are defined here, and
additional options that are also relevant to the server
and/or client are imported from the 'ietf
-dhcpv6 -common' module. Information for the Authentication Option (OPTION_AUTH (11)) is drawn from [IANA -DHCPV6 ] and [RFC3118]. Where needed, other DHCPv6 option modules can be augmented as they are defined. The complete list of DHCPV6 options is located at [IANA-AUTH -NAMESPACES -DHCPV6 ].¶-OPTION -CODES
- Information about RPCs:
-
- clear
-prefix -entry : - This allows the removal of a delegated lease entry from the relay. Per [BCP18], if available, a language identifier should be included in the output message.¶
- clear
-client -prefixes : - This allows the removal of all of the delegated lease entries for a single client (referenced by client DUID) from the relay. Per [BCP18], if available, a language identifier should be included in the output message.¶
- clear
-interface -prefixes : - This allows the removal of all of the delegated lease entries from an interface on the relay. Per [BCP18], if available, a language identifier should be included in the output message.¶
- clear
- Information about notifications:
-
- topology-change:
- This is raised when the topology of the relay agent is changed, e.g., a client-facing interface is reconfigured.¶
3.3. DHCPv6 Client Tree Diagram
The tree diagram in Figure 3 provides an overview of the DHCPv6 client module. The tree also includes the common functions module defined in Section 4.1.¶
- Descriptions of important nodes:
-
- enabled:
- This globally enables
/disables all DHCPv6 client functions.¶ - dhcpv6-client:
- This container holds the client's DHCPv6-specific configuration.¶
- client-if:
- As a client may have multiple interfaces
requesting configuration over DHCP, they are configured in a
list. The 'if-name' leaf is the key and is an interface-ref to
the applicable interface defined by the 'ietf
-interfaces' YANG module.¶ - enabled:
- This enables
/disables all DHCPv6 client function for the specific interface.¶ - client
-duid /interface -duid : - The DUID is used to identify the client to servers
and relays. A DUID consists of a 2-octet type field
and an arbitrary length (1-128 octets) content field.
Currently, there are four DUID types defined in
[RFC8415] and [RFC6355]. The
DUID may be configured using the format for one of these
types or using the 'unstructured' format. The DUID type
definitions are imported from the 'ietf
-dhcpv6 -common .yang' module. [IANA -HARDWARE ] and [IANA-PEN] are referenced for the relevant DUID types. A DUID only needs to be configured if the client is requesting addresses and/or prefixes from the server. Presence of the 'client-duid' or 'interface-TYPES -duid' leaves is conditional on at least one of the 'non -temp -addr', 'temp-addr', or 'prefix -delegation' features being enabled. Additionally, if the 'anon-profile' [RFC7844] feature is enabled, a unique DUID can be configured per a DHCP-enabled interface using the 'interface -duid' leaf; otherwise, there is a global 'client-duid' leaf.¶ - client
-configured -options : - This holds configuration parameters
for DHCPv6 options that can be sent by the client. The
initial set of applicable option definitions are defined
here, and additional options that are also relevant to the
relay and/or server are imported from the
'ietf
-dhcpv6 -common' module. Where needed, other DHCPv6 option modules can be augmented as they are defined. The complete list of DHCPV6 options is located at [IANA -DHCPV6 ].¶-OPTION -CODES - ia-na, ia-ta, ia-pd:
- These contain configuration nodes relevant
for requesting one or more of each of the lease types.
Read-only nodes related to the active leases for each
type are also located here, drawing the status codes from
[IANA
-DHCPV6 ]. As these lease types may not be supported by all DHCPv6 client implementations-STATUS -CODES , they are enabled via individual feature statements. Stateless DHCP (Section 6.1 of [RFC8415]) is configured when all address and prefix features are disabled.¶
- Information about notifications:
4. DHCPv6 YANG Modules
4.2. DHCPv6 Server YANG Module
This module imports typedefs from [RFC6991] and the module defined in [RFC8343].¶
5. Security Considerations
The YANG modules specified in this document define schemas for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040].
The lowest NETCONF layer is the secure transport layer, and the
mandatory
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
There are a number of data nodes defined in these YANG modules that
are writable
These are the subtrees and data nodes in the 'ieft
Some of the RPC operations in these YANG modules may be considered sensitive
or vulnerable in some network environments. It is thus important to control
access to these operations. These RPCs use 'nacm
These are the operations in the 'ieft
An attacker sending DHCPv6 messages that cause the server to generate
'invalid
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus important to
control read access (e.g., via get, get-config, or notification) to these data
nodes. These are the subtrees and data nodes and their
sensitivity
The following subtrees and data nodes can be misused to track the activity or fingerprint the device type of the host:¶
Information about a server's configured address and prefix pools may be used by an attacker for network reconnaissance [RFC7707]. The following subtrees and data nodes could be used for this purpose:¶
[RFC7844] describes anonymity profiles for DHCP clients. These can be used to prevent client tracking on a visited network. Support for this can be enabled by implementing the 'anon-profile' feature in the client module.¶
[RFC7824] covers privacy considerations for DHCPv6 and is applicable here.¶
Security considerations related to DHCPv6 are discussed in [RFC8415].¶
Security considerations given in [RFC7950] are also applicable here.¶
6. IANA Considerations
This document registers four URIs and four YANG modules.¶
6.1. URI Registration
Per this document, IANA has registered the following four URIs in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -dhcpv6 -server¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -dhcpv6 -relay¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
6.2. YANG Module Name Registration
Per this document, IANA has registered the following four YANG modules in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry.¶
- name:
- ietf
-dhcpv6 -server¶ - namespace:
- urn
:ietf :params :xml :ns :yang :ietf -dhcpv6 -server¶ - maintained by IANA:
- N¶
- prefix:
- dhc6-srv¶
- reference:
- RFC 9243¶
- name:
- ietf
-dhcpv6 -relay¶ - namespace:
- urn
:ietf :params :xml :ns :yang :ietf -dhcpv6 -relay¶ - maintained by IANA:
- N¶
- prefix:
- dhc6-rly¶
- reference:
- RFC 9243¶
7. References
7.1. Normative References
- [BCP18]
-
Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, .<https://
www >.rfc -editor .org /info /bcp18 - [IANA
-DHCPV6 -AUTH -NAMESPACES] -
IANA, "Dynamic Host Configuration Protocol (DHCP) Authentication Option Name Spaces", <https://
www >..iana .org /assignments /auth -namespaces - [IANA
-DHCPV6 -OPTION -CODES] -
IANA, "Option Codes", <https://
www >..iana .org /assignments /dhcpv6 -parameters - [IANA
-DHCPV6 -STATUS -CODES] -
IANA, "DHCPv6 Status Codes", <https://
www >..iana .org /assignments /dhcpv6 -parameters - [IANA
-HARDWARE -TYPES] -
IANA, "Hardware Types", <https://
www >..iana .org /assignments /arp -parameters - [IANA-PEN]
-
IANA, "Private Enterprise Numbers", <https://
www >..iana .org /assignments /enterprise -numbers - [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC3118]
-
Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, DOI 10
.17487 , , <https:///RFC3118 www >..rfc -editor .org /info /rfc3118 - [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC6020]
-
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10
.17487 , , <https:///RFC6020 www >..rfc -editor .org /info /rfc6020 - [RFC6241]
-
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10
.17487 , , <https:///RFC6241 www >..rfc -editor .org /info /rfc6241 - [RFC6242]
-
Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10
.17487 , , <https:///RFC6242 www >..rfc -editor .org /info /rfc6242 - [RFC6355]
-
Narten, T. and J. Johnson, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, DOI 10
.17487 , , <https:///RFC6355 www >..rfc -editor .org /info /rfc6355 - [RFC6991]
-
Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10
.17487 , , <https:///RFC6991 www >..rfc -editor .org /info /rfc6991 - [RFC7844]
-
Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10
.17487 , , <https:///RFC7844 www >..rfc -editor .org /info /rfc7844 - [RFC7950]
-
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10
.17487 , , <https:///RFC7950 www >..rfc -editor .org /info /rfc7950 - [RFC8040]
-
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10
.17487 , , <https:///RFC8040 www >..rfc -editor .org /info /rfc8040 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8340]
-
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10
.17487 , , <https:///RFC8340 www >..rfc -editor .org /info /rfc8340 - [RFC8341]
-
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10
.17487 , , <https:///RFC8341 www >..rfc -editor .org /info /rfc8341 - [RFC8342]
-
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10
.17487 , , <https:///RFC8342 www >..rfc -editor .org /info /rfc8342 - [RFC8343]
-
Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10
.17487 , , <https:///RFC8343 www >..rfc -editor .org /info /rfc8343 - [RFC8415]
-
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10
.17487 , , <https:///RFC8415 www >..rfc -editor .org /info /rfc8415 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446 - [RFC8987]
-
Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson, "DHCPv6 Prefix Delegating Relay Requirements", RFC 8987, DOI 10
.17487 , , <https:///RFC8987 www >..rfc -editor .org /info /rfc8987
7.2. Informative References
- [GROUPINGS-TLS]
-
Watsen, K., "YANG Groupings for TLS Clients and TLS Servers", Work in Progress, Internet-Draft, draft
-ietf , , <https://-netconf -tls -client -server -28 datatracker >..ietf .org /doc /html /draft -ietf -netconf -tls -client -server -28 - [RFC3319]
-
Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, DOI 10
.17487 , , <https:///RFC3319 www >..rfc -editor .org /info /rfc3319 - [RFC7707]
-
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10
.17487 , , <https:///RFC7707 www >..rfc -editor .org /info /rfc7707 - [RFC7824]
-
Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Considerations for DHCPv6", RFC 7824, DOI 10
.17487 , , <https:///RFC7824 www >..rfc -editor .org /info /rfc7824
Appendix A. Data Tree Examples
This section contains XML examples of data trees for the different DHCPv6 elements.¶
A.1. DHCPv6 Server Configuration Examples
The following example shows a basic configuration for a server. The configuration defines:¶
The following example configuration snippet shows a static host reservation within an address pool. The host's lease timers are configured to be longer than hosts from the pool with dynamically assigned addresses.¶
The following example configuration snippet shows a network range and pool to be used for delegating prefixes to clients. In this example, each client will receive a /56 prefix.¶
The 'max
The next example configuration snippet shows a set of options that may be returned to clients, depending on the contents of a received DHCP request message. The option set ID is '1', which will be referenced by other places in the configuration (e.g., address pool configuration) as the available options for clients that request them.¶
The example shows how the option definitions can be
extended via augmentation. In this case, "OPTION
A.2. DHCPv6 Relay Configuration Example
The following example shows a basic configuration for a
single DHCP relay interface and its interaction with the
ietf-interfaces module. The configuration shows two XML
documents, one for ietf-interfaces and a second for
ietf
A.3. DHCPv6 Client Configuration Example
The following example shows a basic configuration for a
DHCP client and its interaction with the
ietf-interfaces module. The configuration shows two XML
documents, one for ietf-interfaces and a second for
ietf
Appendix B. Example of Augmenting Additional DHCPv6 Option Definitions
The following section provides an example of how the DHCPv6 option definitions can be extended to include additional options. It is expected that additional specification documents will be published for this in the future.¶
The example defines YANG modules for OPTION
The module is constructed as follows:¶
Below the groupings for option definitions, augment statements are used to add the option definitions for use in the relevant DHCP element's module (server, relay, and/or client).¶
The correct location to augment the new option definition(s)
will vary according to the specific rules defined for the
use of that specific option. For example, for options that
will be augmented into the ietf
'
so that they can be defined within option sets. However, there are some options that are only applicable for specific deployment scenarios, and in these cases, it may be more logical to augment the option group to a location relevant for the option.¶
One example for this could be OPTION
'
Appendix C. Example Vendor-Specific Server Configuration Module
This section shows how to extend the server YANG module defined in this document with vendor-specific configuration nodes, e.g., configuring access to a lease storage database.¶
The example module defines additional server attributes, such as name and description. Storage for leases is configured using a lease-storage container. It allows storing leases in one of three options: memory (memfile), MySQL, and PostgreSQL. For each case, the necessary configuration parameters are provided.¶
For simplicity, this example module assumes that the DHCPv6 server is colocated with the MySQL or PostgreSQL database server and can serve traffic securely on the localhost without additional cryptographic protection. In a production deployment, these functions would likely not be colocated and thus use TLS to secure the database connection between the DHCPv6 server and database server. A YANG module for configuring TLS is defined in [GROUPINGS-TLS].¶
At the end, there is an augment statement that adds the vendor-specific
configuration defined in "dhcpv6
Appendix D. Example Definition of Class-Selector Configuration
The module "ietf
The example module defines "client
At the end of the example, augment statements are used to add the defined class selector rules into the overall DHCPv6 addressing hierarchy. This is done in two main parts:¶
The mechanism is as follows: class is associated to a client
based on rules, and then a client is allowed to get
an address(es) or a prefix(es) from a given allocation
Acknowledgments
The authors would like to thank Qi Sun, Lishan Li, Hao Wang, Tomek Mrugalski, Marcin Siodelski, Bernie Volz, Ted Lemon, Bing Liu, Tom Petch, Acee Lindem, Benjamin Kaduk, Kris Lambrechts, and Paul Dumitru for their valuable comments and contributions to this work.¶
Contributors
The following individuals are coauthors of this document:¶