Draft: draft-ietf-dhc-dhcpv6-yang-20

Commentary: Changes for the published -20 version of the draft
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.
Separate modules are defined for each element.  Additionally, a
'common' module contains typedefs and groupings used by all of the
element modules.
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 play a part in the normal DHCPv6 message flow.
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.
Separate modules are defined for each element.  Additionally, a
'common' module contains typedefs and groupings used by all of the
element modules.  yang-usage-examples provides XML examples for each
of the element modules and shows their interaction.
The relay and client modules provide configuration which is
applicable device's interfaces.  This is done by importing the ietf-
interfaces module RFC8343 and using interface-refs to the relevant
interface(s).
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.
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 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.
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, vendor-specific-configuration-example
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.
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 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.
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, vendor-specific-configuration-example
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.
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, 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
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.  class-selector-example provides an
example of this, to demonstrate how this is can be integrated with
the main 'ietf-dhcpv6-server.yang' module.
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, 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.  class-selector-example provides an
example of this, to demonstrate how this is can be integrated with
the main 'ietf-dhcpv6-server.yang' module.
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.
Further options definitions can be added using additional YANG
modules via augmentation into the relevant element modules from this
document.  example-dhcp-options-extension 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.
Of these, only the options that require operator configuration are
modelled.  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 modelled.
Further options definitions can be added using additional YANG
modules via augmentation of the relevant element modules from this
document.  example-dhcp-options-extension 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.
The reader should be familiar with the YANG data modelling language
defined in RFC7950.
The reader should be familiar with the YANG data modeling language
defined in RFC7950.
The tree diagram in client-structure provides an overview of the
DHCPv6 client module.  The tree also includes the common functions
module common-module.
The tree diagram in client-structure provides an overview of the
DHCPv6 client module.  The tree also includes the common functions
module defined in common-module.