Document: draft-ietf-dhc-dhcpv6-yang-19 Reviewer: Acee Lindem Review Date: May 5, 2021 Review Type: Early Review Intended Status: Standards Track Summary: On the right track - Issues and questions need to be resolved. Modules: ietf-dhcpv6-server@2021-03-17.yang ietf-dhcpv6-relay@2021-03-17.yang ietf-dhcpv6-client@2021-03-17.yang ietf-dhcpv6-common@2021-03-17.yang Tech Summary: The document contains the base configuration and operational YANG model for the DHCPv6 protocol. The basic structure is very good but the major issues need to be addressed prior to WG last call. Major Comments: 1. Should the DHCP server, relay, and client functions be enabled by default? It seems they are require specific configuration to be viable. 2. The threshold type in the ietf-dhcpv6-common is strange. It is a union with an enumeration to disable the threshold. Normally, if there is no threshold, you would simply not specify it. However, the data nodes of this type are mandatory. I'd make it a simple type and remove the mandatory designations for the data nodes. Also, the range should not start at 0% since this % makes no sense. 3. There are examples of augmenting the ietf-dhcpv6-server module but no "Module Usage Examples" as specified in section 3.12 of RFC 8407. Minor Comments: 1. While not required by RFC 8407, many YANG RFCs explcitly call out the interaction with imported YANG modules in a separate section. 2. No sense in maintaining all the intermediate revisions in the modules. Just update the one that is the initial version and update the date. 3. The module prefixes are very descriptive but a bit long. Given the examples of augmentations, this will be especially true for DHCPv6 server augmentations. Perhaps, dhc6-serv, dhc6-rly, and dhc6-clnt would be better. 4. Can host-reservation prefixes overlap with holes? If so, reserved-prefix may not be unique. If not, no problem. 5. For nodes with patterns, describe what the pattern allows in the description with an example or two. This applies to link-address, duid-base, duid-llt, duid-en, duid-ll, duid-unstructured, and sub-option-data. 6. With respect to link-address, what type of address is this? If it is an IPv6 link-local address, there is an ipv6-adddress type in RFC 6021. Nits: 1. IETF documents should use US English - not UK English. I've changed in suggested edits. 2. Description format - Sometimes starting right have "description" and sometimes starting on the next line. 3. sol-max-rt-option-group and inf-max-rt-option-group should spell out the words in the description rather than just repeating the short abreviations. 4. In ietf-dhcpv6-client, for ia_ta and ia_pd, spell our acronyms in the descriptions rather than just repeating them (which is useless).Is "ia" "interface address"? Don't make the reader go to the DHCPv6 RFC to know what you mean. What is "ia_ta"? 5. See diffs below: ACEE-M-3B86:Desktop acee$ diff -c draft-ietf-dhc-dhcpv6-yang-19.txt.orig draft-ietf-dhc-dhcpv6-yang-19.txt *** draft-ietf-dhc-dhcpv6-yang-19.txt.orig 2021-05-04 13:13:40.000000000 -0400 --- draft-ietf-dhc-dhcpv6-yang-19.txt 2021-05-05 16:46:30.000000000 -0400 *************** *** 100,106 **** DHCPv6 [RFC8415] is widely 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 'element' (servers, relays and clients) using the Network Configuration Protocol (NETCONF [RFC6241]) or RESTCONF [RFC8040] protocols. --- 100,106 ---- DHCPv6 [RFC8415] is widely 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 'element' (servers, relays, and clients) using the Network Configuration Protocol (NETCONF [RFC6241]) or RESTCONF [RFC8040] protocols. *************** *** 123,129 **** 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 play a part in the normal DHCPv6 message flow. The YANG modules in this document adopt the Network Management Datastore Architecture (NMDA) [RFC8342]. --- 123,130 ---- 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]. *************** *** 136,157 **** options. The YANG modules contained in this document do not attempt to capture all of these extensions and additions, rather to model the DHCPv6 functions and options covered in [RFC8415]. A focus has also ! been given on the extensibility of the modules so that it is easy to ! augment in 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. The level of variance between implementations is too great to attempt to ! standardize in a way that is useful without being restrictive. ! However, it is recognized that implementation specific configuration and management is also an essential part of DHCP deployment and operations. To resolve this, Appendix B contains an example YANG ! module for the configuration of implementation specific functions, illustrating how this functionality can be augmented into the main 'ietf-dhcpv6-server.yang' module. --- 137,158 ---- options. The YANG modules contained in this document do not attempt to capture all of these extensions and additions, rather to 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. The level of variance between implementations is too great to attempt to ! standardize them in a way that is useful without being restrictive. ! However, it is recognized that implementation-specific configuration and management is also an essential part of DHCP deployment and operations. To resolve this, Appendix B contains an example YANG ! module for the configuration of implementation-specific functions, illustrating how this functionality can be augmented into the main 'ietf-dhcpv6-server.yang' module. *************** *** 161,167 **** provisioning information can be supplied. For example, 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, research has been carried out into a --- 162,168 ---- provisioning information can be supplied. For example, 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, a number of vendor's class selection *************** *** 170,181 **** Internet-Draft DHCPv6 YANG Model March 2021 ! number of vendor's class selection implementations 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 module. Appendix C provides an example of this, to demonstrate how this is can be integrated with the main 'ietf-dhcpv6-server.yang' module. --- 171,182 ---- Internet-Draft DHCPv6 YANG Model March 2021 ! 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 C provides an example of this, to demonstrate how this is can be integrated with the main 'ietf-dhcpv6-server.yang' module. *************** *** 188,202 **** [RFC8415] are included in this document. Of these, only the options that require operator configuration are ! modelled. E.g. 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 which 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 in the option, so ! it is not modelled. ! The following table shows the DHCPv6 options that are modelled, the element(s) they are sent by, and the relevant YANG module name: +---------------------+------+-----+------+-------------------------+ --- 189,203 ---- [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 which 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 sent by, and the relevant YANG module name: +---------------------+------+-----+------+-------------------------+ *************** *** 268,274 **** | Option | | | | | +---------------------+------+-----+------+-------------------------+ ! Table 1: Modelled DHCPv6 Options --- 269,275 ---- | Option | | | | | +---------------------+------+-----+------+-------------------------+ ! Table 1: Modeled DHCPv6 Options *************** *** 282,289 **** Internet-Draft DHCPv6 YANG Model March 2021 ! Further options definitions can be added using additional YANG ! modules via augmentation into the relevant element modules from this document. Appendix A 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 --- 283,290 ---- Internet-Draft DHCPv6 YANG Model March 2021 ! Further option definitions can be added using additional YANG ! modules via augmentation of the relevant element modules from this document. Appendix A 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 *************** *** 291,297 **** 1.3. Terminology ! The reader should be familiar with the YANG data modelling language defined in [RFC7950]. The YANG modules in this document adopt the Network Management --- 292,298 ---- 1.3. Terminology ! The reader should be familiar with the YANG data modeling language defined in [RFC7950]. The YANG modules in this document adopt the Network Management *************** *** 594,600 **** * server-duid: Each server must have a DUID (DHCP Unique Identifier) to identify itself to clients. A DUID consists of a two-octet ! type field and an arbitrary length (of no more than 128-bytes) content field. Currently there are four defined types of DUIDs in [RFC8415] and [RFC6355]. The DUID may be configured using the format for one of these types, or using the 'unstructured' format. --- 595,601 ---- * server-duid: Each server must have a DUID (DHCP Unique Identifier) to identify itself to clients. A DUID consists of a two-octet ! type field and an arbitrary length (1-128 octets) content field. Currently there are four defined types of DUIDs in [RFC8415] and [RFC6355]. The DUID may be configured using the format for one of these types, or using the 'unstructured' format. *************** *** 603,609 **** are referenced for the relevant DUID 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 B for an example of such a module. --- 604,610 ---- are referenced for the relevant DUID 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 B for an example of such a module. *************** *** 637,643 **** this. * network-ranges: A hierarchical model is used for the allocation of ! addresses and prefixes. At the top level 'network-ranges' holds global configuration parameters. Under this, a list of 'network- ranges' can be defined. Inside 'network-rages', 'address-pools' (for IA_NA and IA_TA allocations), and 'prefix-pools' (for IA_PD --- 638,644 ---- this. * network-ranges: A hierarchical model is used for the allocation of ! addresses and prefixes. At the top level, 'network-ranges' holds global configuration parameters. Under this, a list of 'network- ranges' can be defined. Inside 'network-rages', 'address-pools' (for IA_NA and IA_TA allocations), and 'prefix-pools' (for IA_PD *************** *** 651,662 **** Information about notifications: * address/prefix-pool-utilization-threshold-exceeded: Raised when ! number of leased addresses or prefixes exceeds the configured usage threshold. * invalid-client-detected: Raised when the server detects an invalid ! client. A description of the error that has generated the ! notification can be included. * decline-received: Raised when a DHCPv6 Decline message is received from a client. --- 652,663 ---- Information about notifications: * address/prefix-pool-utilization-threshold-exceeded: Raised when ! the number of leased addresses or prefixes exceeds the configured usage threshold. * invalid-client-detected: 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: Raised when a DHCPv6 Decline message is received from a client. *************** *** 775,781 **** * enabled: Globally enables/disables all DHCPv6 relay functions. ! * dhcpv6-relay: This container holds the relay's DHCPv6 specific configuration. --- 776,782 ---- * enabled: Globally enables/disables all DHCPv6 relay functions. ! * dhcpv6-relay: This container holds the relay's DHCPv6-specific configuration. *************** *** 818,824 **** Information about notifications: * topology-changed: Raised when the topology of the relay agent is ! changed, e.g. a client facing interface is reconfigured. Information about RPCs --- 819,825 ---- Information about notifications: * topology-changed: Raised when the topology of the relay agent is ! changed, e.g., a client facing interface is reconfigured. Information about RPCs *************** *** 846,852 **** The tree diagram in Figure 3 provides an overview of the DHCPv6 client module. The tree also includes the common functions module ! Section 3.4. module: ietf-dhcpv6-client +--rw dhcpv6-client --- 847,853 ---- 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 3.4. module: ietf-dhcpv6-client +--rw dhcpv6-client *************** *** 999,1006 **** * client-duid: Each client must have a DUID (DHCP Unique Identifier) to identify itself to servers and relays. A DUID consists of a ! two-octet type field and an arbitrary length (of no more than ! 128-bytes) content field. Currently there are four defined types of DUIDs in [RFC8415] and [RFC6355]. The DUID may be configured --- 1000,1007 ---- * client-duid: Each client must have a DUID (DHCP Unique Identifier) to identify itself to servers and relays. A DUID consists of a ! two-octet type field and an arbitrary length (1-128 octets) ! content field. Currently there are four defined types of DUIDs in [RFC8415] and [RFC6355]. The DUID may be configured *************** *** 1024,1030 **** * ia-na, ia-ta, ia-pd: Contains configuration nodes relevant for requesting one or more of each of the lease types. Read-only ! nodes related to the active lease are also located here. Information about notifications: --- 1025,1032 ---- * ia-na, ia-ta, ia-pd: Contains 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. Information about notifications: *************** *** 1216,1222 **** path "/dhcpv6-server/option-sets/option-set/option-set-id"; } description "The ID field of relevant set of DHCPv6 options ! (option-set) to be provisioned to clients of this network-range."; } leaf valid-lifetime { --- 1218,1224 ---- path "/dhcpv6-server/option-sets/option-set/option-set-id"; } description "The ID field of relevant set of DHCPv6 options ! (option-set) to be provisioned to clients of the using network-range."; } leaf valid-lifetime { *************** *** 1246,1252 **** reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 4.2"; } ! leaf preferred-lifetime { type dhcpv6-common:timer-seconds32; description "Preferred lifetime for the Identity Association (IA)."; --- 1248,1254 ---- reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 4.2"; } ! leaf preferred-lifetime { type dhcpv6-common:timer-seconds32; description "Preferred lifetime for the Identity Association (IA)."; *************** *** 1587,1594 **** in order to identify and classify incoming client messages so that they can be given the correct configuration. The mechanisms used for implementing this function vary ! greatly between different implementations such that they ! are not possible to include in this module. This container provides a location for server implementors to augment their own class-selector YANG."; } --- 1589,1596 ---- in order to identify and classify incoming client messages so that they can be given the correct configuration. The mechanisms used for implementing this function vary ! greatly between different implementations such it is ! not possible to include them in this module. This container provides a location for server implementors to augment their own class-selector YANG."; } *************** *** 1647,1658 **** leaf start-address { type inet:ipv6-address-no-zone; mandatory true; ! description "Start IPv6 address for the pool."; } leaf end-address { type inet:ipv6-address-no-zone; mandatory true; ! description "End IPv6 address for the pool."; } leaf max-address-utilization { type dhcpv6-common:threshold; --- 1649,1660 ---- leaf start-address { type inet:ipv6-address-no-zone; mandatory true; ! description "Starting IPv6 address for the pool."; } leaf end-address { type inet:ipv6-address-no-zone; mandatory true; ! description "Ending IPv6 address for the pool."; } leaf max-address-utilization { type dhcpv6-common:threshold; *************** *** 1762,1768 **** from the prefix pool."; list prefix-reservation { key reserved-prefix; ! description "reserved prefix reservation"; leaf client-duid { type dhcpv6-common:duid; description "Client DUID for the reservation."; --- 1764,1770 ---- from the prefix pool."; list prefix-reservation { key reserved-prefix; ! description "Reserved prefix reservation"; leaf client-duid { type dhcpv6-common:duid; description "Client DUID for the reservation."; *************** *** 1780,1786 **** } container active-leases { config false; ! description "Holds state related to for active client prefix leases."; leaf total-count { type uint64; --- 1782,1788 ---- } container active-leases { config false; ! description "Holds state related to active client prefix leases."; leaf total-count { type uint64; *************** *** 1890,1896 **** description "Maximum number of prefixes that can be simultaneously allocated from the pool. This value may be less than count of total prefixes. Calculated as the ! max-precfix-utilization (percentage) of the total-pool-prefixes, rounded up."; } leaf allocated-prefixes-count { --- 1892,1898 ---- description "Maximum number of prefixes that can be simultaneously allocated from the pool. This value may be less than count of total prefixes. Calculated as the ! max-prefix-utilization (percentage) of the total-pool-prefixes, rounded up."; } leaf allocated-prefixes-count { *************** *** 1947,1953 **** } leaf description { type string; ! description "Description of the event (e.g. and error code or log message)."; } } --- 1949,1955 ---- } leaf description { type string; ! description "Description of the event (e.g., and error code or log message)."; } } *************** *** 2008,2015 **** rpc delete-address-lease { nacm:default-deny-all; description "Deletes a client's active address lease from the ! server's lease database. Note, this will not cause the address ! to be revoked from the client, and the lease may be refreshed --- 2010,2017 ---- rpc delete-address-lease { nacm:default-deny-all; description "Deletes a client's active address lease from the ! server's lease database. Note that this will not cause the ! address to be revoked from the client, and the lease may be *************** *** 2018,2033 **** Internet-Draft DHCPv6 YANG Model March 2021 ! or renewed by the client."; input { leaf lease-address-to-delete { type leafref { path "../../dhcpv6-server/network-ranges/network-range" + ! "/address-pools/address-pool/active-leases/active-lease" ! + ! "/leased-address"; } ! mandatory true; description "IPv6 address of an active lease that will be deleted from the server."; } --- 2020,2034 ---- Internet-Draft DHCPv6 YANG Model March 2021 ! refreshed or renewed by the client."; input { leaf lease-address-to-delete { type leafref { path "../../dhcpv6-server/network-ranges/network-range" + ! "/address-pools/address-pool/active-leases" + ! "/active-lease/leased-address"; } ! mandatory true; description "IPv6 address of an active lease that will be deleted from the server."; } *************** *** 2271,2277 **** } leaf client-peer-address { type inet:ipv6-address; ! description "Peer-address of the client."; } leaf client-duid { type dhcpv6-common:duid; --- 2272,2278 ---- } leaf client-peer-address { type inet:ipv6-address; ! description "Peer-address of the leasing client."; } leaf client-duid { type dhcpv6-common:duid; *************** *** 2449,2455 **** container dhcpv6-relay { description "This container contains the configuration data nodes for ! the relay."; reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 19"; leaf enabled { --- 2450,2456 ---- container dhcpv6-relay { description "This container contains the configuration data nodes for ! the relay."; reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 19"; leaf enabled { *************** *** 2483,2490 **** type inet:ipv6-address; description "Each DHCPv6 relay agent may be configured with a list of destination addresses for relayed messages. ! The list may include unicast addresses, multicast addresses ! or other valid addresses."; } leaf link-address { type string { --- 2484,2491 ---- type inet:ipv6-address; description "Each DHCPv6 relay agent may be configured with a list of destination addresses for relayed messages. ! The list may include unicast addresses, multicast ! addresses, or other valid addresses."; } leaf link-address { type string { *************** *** 2495,2502 **** } container relay-options { description "Definitions for DHCPv6 options that can be sent ! by the relay are augmented to this location from other YANG ! modules as required."; uses dhcpv6-common:auth-option-group; uses dhcpv6-common:status-code-option-group; uses interface-id-option-group; --- 2496,2503 ---- } container relay-options { description "Definitions for DHCPv6 options that can be sent ! by the relay. This container can be augmented from other ! YANG modules as required."; uses dhcpv6-common:auth-option-group; uses dhcpv6-common:status-code-option-group; uses interface-id-option-group; *************** *** 2559,2567 **** input { leaf lease-prefix { type leafref { ! path "/dhcpv6-relay/relay-if/prefix-delegation/pd-leases/" ! + ! "ia-pd-prefix"; } mandatory true; description "IPv6 prefix of an active lease entry that will --- 2560,2567 ---- input { leaf lease-prefix { type leafref { ! path "/dhcpv6-relay/relay-if/prefix-delegation/" + ! "pd-leases/ia-pd-prefix"; } mandatory true; description "IPv6 prefix of an active lease entry that will *************** *** 2594,2600 **** leaf client-duid { type dhcpv6-common:duid; mandatory true; ! description "DUID of the client ."; } } output { --- 2594,2600 ---- leaf client-duid { type dhcpv6-common:duid; mandatory true; ! description "DUID of the client."; } } output { *************** *** 2981,2988 **** } list client-if { key if-name; ! description "The list of interfaces that the client will be ! requesting DHCPv6 configuration for."; leaf if-name { type if:interface-ref; mandatory true; --- 2981,2988 ---- } list client-if { key if-name; ! description "The list of interfaces for which the client will ! be requesting DHCPv6 configuration."; leaf if-name { type if:interface-ref; mandatory true; *************** *** 3002,3008 **** IPv6 (DHCPv6), Section 11"; } container client-configured-options { ! description " Definitions for DHCPv6 options that can be be sent by the client. Additional option definitions can be augmented to this location from other YANG modules as required."; --- 3002,3008 ---- IPv6 (DHCPv6), Section 11"; } container client-configured-options { ! description "Definitions for DHCPv6 options that can be be sent by the client. Additional option definitions can be augmented to this location from other YANG modules as required."; *************** *** 3048,3059 **** leaf preferred-lifetime { type dhcpv6-common:timer-seconds32; description "The preferred lifetime for the leased ! address expressed in units of seconds."; } leaf valid-lifetime { type dhcpv6-common:timer-seconds32; description "The valid lifetime for the leased address ! expressed in units of seconds."; } leaf lease-t1 { type dhcpv6-common:timer-seconds32; --- 3048,3059 ---- leaf preferred-lifetime { type dhcpv6-common:timer-seconds32; description "The preferred lifetime for the leased ! address expressed in seconds."; } leaf valid-lifetime { type dhcpv6-common:timer-seconds32; description "The valid lifetime for the leased address ! expressed in seconds."; } leaf lease-t1 { type dhcpv6-common:timer-seconds32; *************** *** 3118,3129 **** leaf preferred-lifetime { type dhcpv6-common:timer-seconds32; description "The preferred lifetime for the leased ! address expressed in units of seconds."; } leaf valid-lifetime { type dhcpv6-common:timer-seconds32; description "The valid lifetime for the leased address ! expressed in units of seconds."; } leaf allocation-time { type yang:date-and-time; --- 3118,3129 ---- leaf preferred-lifetime { type dhcpv6-common:timer-seconds32; description "The preferred lifetime for the leased ! address expressed in seconds."; } leaf valid-lifetime { type dhcpv6-common:timer-seconds32; description "The valid lifetime for the leased address ! expressed in seconds."; } leaf allocation-time { type yang:date-and-time; *************** *** 3150,3160 **** } } list ia-pd { ! key iaid; description "Configuration relevant for an IA_PD."; reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 13.3"; ! leaf iaid { type uint32; description "The unique identifier for this IA_PD."; reference "RFC 8415: Dynamic Host Configuration Protocol --- 3150,3160 ---- } } list ia-pd { ! key ia-id; description "Configuration relevant for an IA_PD."; reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 13.3"; ! leaf ia-id { type uint32; description "The unique identifier for this IA_PD."; reference "RFC 8415: Dynamic Host Configuration Protocol *************** *** 3230,3244 **** notification invalid-ia-address-detected { description "Notification sent when an address received ! in an identity association option can be proved to be invalid. Possible conditions include a duplicate or otherwise illegal address."; reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 18.2.10.1"; ! leaf iaid { type uint32; mandatory true; ! description "IAID"; } leaf ia-na-t1-timer { type uint32; --- 3230,3244 ---- notification invalid-ia-address-detected { description "Notification sent when an address received ! in an identity association option is determined invalid. Possible conditions include a duplicate or otherwise illegal address."; reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 18.2.10.1"; ! leaf ia-id { type uint32; mandatory true; ! description "IA-ID"; } leaf ia-na-t1-timer { type uint32; *************** *** 3250,3262 **** Internet-Draft DHCPv6 YANG Model March 2021 ! description "The value of the T1 time field for non-tempory address allocations (OPTION_IA_NA)."; } leaf ia-na-t2-timer { type uint32; description "The value of the preferred-lifetime field for ! non-tempory address allocations (OPTION_IA_NA)."; } leaf invalid-address { type inet:ipv6-address; --- 3250,3262 ---- Internet-Draft DHCPv6 YANG Model March 2021 ! description "The value of the T1 time field for non-temporary address allocations (OPTION_IA_NA)."; } leaf ia-na-t2-timer { type uint32; description "The value of the preferred-lifetime field for ! non-temporary address allocations (OPTION_IA_NA)."; } leaf invalid-address { type inet:ipv6-address; *************** *** 3280,3286 **** } leaf description { type string; ! description "Description of the event."; } } --- 3280,3287 ---- } leaf description { type string; ! description "Description of the invalid Identity ! Association (IA) detection error."; } } *************** *** 3375,3381 **** notification server-duid-changed { description "Notification sent when the client receives a lease from a server with different DUID to the one currently stored ! by the client, e.g. in response to a Rebind message."; reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 18.2.5"; leaf new-server-duid { --- 3376,3382 ---- notification server-duid-changed { description "Notification sent when the client receives a lease from a server with different DUID to the one currently stored ! by the client, e.g., in response to a Rebind message."; reference "RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 18.2.5"; leaf new-server-duid { *************** *** 3559,3565 **** } description "Each DHCP server and client has a DUID (DHCP Unique Identifier). The DUID consists of a two-octet ! type field and an arbitrary length (between 1 and 128 octets) content field. Currently, there are four defined types of DUIDs in RFC 8415 and RFC 6355 - DUID-LLT, DUID-EN, DUID-LL and DUID-UUID. DUID-unstructured represents DUIDs which --- 3560,3566 ---- } description "Each DHCP server and client has a DUID (DHCP Unique Identifier). The DUID consists of a two-octet ! type field and an arbitrary length (1-128 octets) content field. Currently, there are four defined types of DUIDs in RFC 8415 and RFC 6355 - DUID-LLT, DUID-EN, DUID-LL and DUID-UUID. DUID-unstructured represents DUIDs which *************** *** 3742,3748 **** leaf status-message { type string; description "A UTF-8 encoded text string suitable for ! display to an end user. MUST NOT be null-terminated."; } } } --- 3743,3749 ---- leaf status-message { type string; description "A UTF-8 encoded text string suitable for ! display to an end-user. It MUST NOT be null-terminated."; } } } *************** *** 3775,3781 **** Information Option container."; list vendor-specific-information-option-instances { key enterprise-number; ! description "The vendor specific information option allows for multiple instances in a single message. Each list entry defines the contents of an instance of the option."; leaf enterprise-number { --- 3776,3782 ---- Information Option container."; list vendor-specific-information-option-instances { key enterprise-number; ! description "The vendor-specific information option allows for multiple instances in a single message. Each list entry defines the contents of an instance of the option."; leaf enterprise-number { *************** *** 3873,3880 **** rogue DHCPv6 server. * Various attacks based on re-configuring the contents of DHCPv6 ! options. E.g., changing the address of a the DNS server supplied ! in a DHCP option to point to a rogue server. An attacker who is able to access the DHCPv6 relay can undertake various attacks, such as: --- 3874,3881 ---- rogue DHCPv6 server. * Various attacks based on re-configuring the contents of DHCPv6 ! options. For example, changing the address of a the DNS server ! advertised in a DHCP option to point to a rogue server. An attacker who is able to access the DHCPv6 relay can undertake various attacks, such as: *************** *** 3893,3899 **** data nodes can be misused to track the activity of a host: * Information the server holds about clients with active leases: ! (dhcpv6-server/network-ranges/network-range/ address-pools/ address-pool/active-leases) * Information the relay holds about clients with active leases: --- 3894,3900 ---- data nodes can be misused to track the activity of a host: * Information the server holds about clients with active leases: ! (dhcpv6-server/network-ranges/network-range/address-pools/ address-pool/active-leases) * Information the relay holds about clients with active leases: *************** *** 3958,3965 **** 6. Acknowledgments The authors would like to thank Qi Sun, Lishan Li, Hao Wang, Tomek ! Mrugalski, Marcin Siodelski, Bernie Volz, Ted Lemon, Bing Liu, and ! Tom Petch for their valuable comments and contributions to this work. 7. Contributors --- 3959,3967 ---- 6. 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, and Acee Lindem for their valuable comments and contributions ! to this work. 7. Contributors *************** *** 4300,4306 **** (DHCPv6) Options for Session Initiation Protocol (SIP) Servers"; container sip-server-domain-name-list-option { ! description "OPTION_SIP_SERVER_D (21) SIP Servers Domain Name List container."; list sip-server { key sip-serv-id; --- 4302,4308 ---- (DHCPv6) Options for Session Initiation Protocol (SIP) Servers"; container sip-server-domain-name-list-option { ! description "OPTION_SIP_SERVER_D (21) SIP Servers Domain-Name List container."; list sip-server { key sip-serv-id; *************** *** 4374,4386 **** 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. E.g. for options which will be augmented into the ! ietf-dhcpv6-server module, in many cases, these will be augmented to: ! '/dhcpv6-server:dhcpv6-server/dhcpv6-server:option-sets/\ dhcpv6- ! server:option-set' ! so that they can be defined within option sets. However, there are some options which 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. --- 4376,4389 ---- 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. Fpr example, for options which will be augmented ! into the ietf-dhcpv6-server module, in many cases, these will be ! augmented to: ! '/dhcpv6-server:dhcpv6-server/dhcpv6-server:option-sets/ ! dhcpv6-server:option-set' ! So that they can be defined within option sets. However, there are some options which 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. *************** *** 4390,4404 **** specific prefix. In this case, the following location for the augmentation may be more suitable: ! '/dhcpv6-server:dhcpv6-server/dhcpv6-server:network-ranges/\ dhcpv6- ! server:network-range/dhcpv6-server:prefix-pools/\ dhcpv6- ! server:prefix-pool" ! Appendix B. 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- --- 4393,4407 ---- specific prefix. In this case, the following location for the augmentation may be more suitable: ! '/dhcpv6-server:dhcpv6-server/dhcpv6-server:network-ranges/ ! dhcpv6-server:network-range/dhcpv6-server:prefix-pools/ ! dhcpv6-server:prefix-pool' ! Appendix B. 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- *************** *** 4454,4460 **** description "This YANG module defines components for the configuration and management of vendor/implementation specific DHCPv6 server functionality. As this functionality varies ! greatly between different implementations, the module provided as an example only. Copyright (c) 2021 IETF Trust and the persons identified as --- 4457,4463 ---- description "This YANG module defines components for the configuration and management of vendor/implementation specific DHCPv6 server functionality. As this functionality varies ! greatly between different implementations, the module is provided as an example only. Copyright (c) 2021 IETF Trust and the persons identified as *************** *** 4569,4576 **** case interface-list { leaf-list interfaces { type if:interface-ref; ! description "List of interfaces that the server will ! listen for incoming messages on. Messages addressed to any valid IPv6 address (unicast and multicast) will be received."; } --- 4572,4579 ---- case interface-list { leaf-list interfaces { type if:interface-ref; ! description "List of interfaces on which the server will ! listen for incoming DHCPv6 messages Messages addressed to any valid IPv6 address (unicast and multicast) will be received."; } *************** *** 4578,4585 **** case address-list { leaf-list address-list { type inet:ipv6-address; ! description "List of IPv6 address(es) that the server ! will listen for incoming messages on."; } } } --- 4581,4588 ---- case address-list { leaf-list address-list { type inet:ipv6-address; ! description "List of IPv6 address(es) on which the server ! will listen for incoming DHCPv6 messages."; } } } *************** *** 4594,4601 **** Internet-Draft DHCPv6 YANG Model March 2021 ! description "A leaf list to denote which one or more ! interfaces the server should listen on."; } container lease-storage { description "Configures how the server will stores leases."; --- 4597,4604 ---- Internet-Draft DHCPv6 YANG Model March 2021 ! description "A leaf list of interfaces on which the server ! should listen."; } container lease-storage { description "Configures how the server will stores leases."; *************** *** 4603,4610 **** description "The type storage that will be used for lease information."; case memfile { ! description "Configuration for storing leases information ! in a CSV file."; leaf memfile-name { type string; description "Specifies the absolute location --- 4606,4613 ---- description "The type storage that will be used for lease information."; case memfile { ! description "Configuration for storing lease information ! in a Common-Separated Valu (CSV) file."; leaf memfile-name { type string; description "Specifies the absolute location *************** *** 4630,4637 **** type inet:domain-name; default "localhost"; description "If the database is located on a ! different system to the DHCPv6 server, the ! domain name can be specified."; } } case mysql-server-address { --- 4633,4640 ---- type inet:domain-name; default "localhost"; description "If the database is located on a ! different system than the DHCPv6 server, the ! domain name can be specified."; } } case mysql-server-address { *************** *** 4766,4786 **** } ! Appendix C. Example definition of class selector configuration The module "ietf-example-dhcpv6-class-selector" provides an example ! of how vendor specific class selection configuration can be modelled and integrated with the "ietf-dhcpv6-server" module defined in this document. The example module defines "client-class-names" with associated matching rules. A client can be classified based on "client-id", ! "interface-id" (ingress interface of the client's messages), packets source or destination address, relay link address, relay link interface-id and more. Actually, there are endless methods for classifying clients. So this standard does not try to provide full specification for class selection, it only shows an example how it ! can be defined. At the end of the example augment statements are used to add the defined class selector rules into the overall DHCPv6 addressing --- 4769,4789 ---- } ! Appendix C. Example definition of class-selector configuration The module "ietf-example-dhcpv6-class-selector" provides an example ! of how vendor-specific class selection configuration can be modeled and integrated with the "ietf-dhcpv6-server" module defined in this document. The example module defines "client-class-names" with associated matching rules. A client can be classified based on "client-id", ! "interface-id" (ingress interface of the client's messages), packet's source or destination address, relay link address, relay link interface-id and more. Actually, there are endless methods for classifying clients. So this standard does not try to provide full specification for class selection, it only shows an example how it ! could be defined. At the end of the example augment statements are used to add the defined class selector rules into the overall DHCPv6 addressing *************** *** 4843,4854 **** Author: Michal Nowikowski "; description "This YANG module defines components for the ! definition and configuration of the client class selector functio ! n ! for a DHCPv6 server. As this functionality varies greatly betwee ! n ! different implementations, the module provided as an example ! only. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. --- 4846,4855 ---- Author: Michal Nowikowski "; description "This YANG module defines components for the ! definition and configuration of the client class selector ! function for a DHCPv6 server. As this functionality varies ! greatly between different implementations, the module is ! provided only as an example. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved.