NETCONF DHCPv6 Option

NETCONF combined with the YANG data modeling language provides an extensible mechanism for configuring and monitoring networked devices. One of the advantages that NETCONF/YANG offers over other network management protocols is that it is flexible enough to be adapted for use with almost any service on any device. The Dynamic Host Configuration Protocol for IPv6 is widely in use for the configuration of network devices. This document describes a DHCPv6 option which can be used for provisioning the necessary parameters to bootstrap NETCONF connectivity so that a device can then obtain further configuration. An example device suitable for this type of configuration process would be a managed home gateway router. This document uses the terms "client" and "server" to describe the hosts at either end of a NETCONF connection. "Client" should be understood to be the host that is actively initiating the NETCONF connection to the "Server". These definitions are used to align with the terminology in the DHCPv6 message flow.

The following section describes the format of the NETCONF configuration container option. A container approach has been taken so that different NETCONF transport protocols can be supported. Currently only two transport protocols have been defined, NETCONF over SSH and NETCONF over TLS . If necessary in the future, the option could be extended to support additional transport protocols through the definition of new sub-options.

OPTION_NETCONF_CONT (TBA1) Variable Contains one or more NETCONF configuration sub-options (described below).

Clients which implement NETCONF transport over Secure Shell (SSH) use the following sub-option to obtain configuration necessary to establish a connection. The procedure for establishing NETCONF connectivity over SSH, is described in .

OPTION_NETCONF_SSH (TBA2) Variable 8-bit integer. Described in Section 3.1 16-bit integer to be used by the client as the destination layer 4 port to initiate the SSH connection to. List of FQDNs to use for the NETCONF server, formatted according to Section 8 of . In case the client receives more than one server address in the server-fqdn field, the client SHOULD initiate connections to the addresses in the order they are listed in the server-fqdn field, attempting to establish a connection to each server until one is successfully established.

Clients which implement NETCONF transport over Transport Layer Security (TLS) use the following sub-option to obtain configuration necessary to establish a connection. The procedure for establishing NETCONF connectivity over TLS, is described in .

OPTION_NETCONF_TLS (TBA3) Variable 8-bit integer. Described in Section 3.1 16-bit integer to be used by the client as the destination layer 4 port for initiating the TLS connection List of FQDNs to use for the NETCONF server, formatted according to Section 8 of . In case the client receives more than one server FQDN in the server-fqdn field, the client SHOULD initiate connections to the addresses in the order they are listed in the server-fqdn field, attempting to establish a connection to each server until one is successfully established.

When a device which implements both NETCONF functionality and the DHCP option described in this document creates a DHCPv6 SOLICIT message, it SHOULD include OPTION_NETCONF_CONT (TBD) within the ORO field. On receipt of an DHCP ADVERTISE response message including the OPTION_NETCONF_CONT option, the client evaluates the sub-options which it contains as follows: If OPTION_NETCONF_CONT does not contain a transport sub-option implemented by the client, then it MUST be discarded by the client. If OPTION_NETCONF_CONT contains a single NETCONF transport protocol sub-option implemented by the client, then the client SHOULD attempt establish a NETCONF session using the configured transport protocol. If OPTION_NETCONF_CONT contains multiple NETCONF transport protocol sub-options supported by the client, then the client SHOULD follow the procedure described below to establish a connection to the NETCONF server.

As NETCONF is not limited to on specific transport protocol, the NETCONF client and/or server may have been deployed with support for more than one NETCONF transport protocol. The 'priority' field contained within the transport protocol specific sub-options give the service provider a method of indicating to the client the order in which to attempt using the different supported protocols to establish NETCONF connectivity. A client which supports two (or more) NETCONF transport protocols, and receives configuration parameters for at least two protocols SHOULD inspect the values of the priority field. The sub-option with the highest priority value SHOULD be used as the first NETCONF protocol to attempt for establishing connectivity. In the event that this connection attempt is not successful, then the client SHOULD attempt to establish connectivity using the NETCONF transport protocol sub-option with the second highest priority, then the third highest priority, and so on until either a successful connection has been established, or there are no more In the event that the client receives two options with the same priority, the client SHOULD implement a mechanism for prioritising one mechanism over the other. This mechanism is implementation specific.

When a DHCPv6 server receives a client SOLICIT message containing the OPTION_NETCONF_CONT option code within the ORO field, it SHOULD respond with an ADVERTISE message containing the sub-options If the operator has deployed their NETCONF infrastructure with support for more than one NETCONF transport protocol and has a preference for clients to use one transport protocol over another, then the 'priorities' field SHOULD be used within the NETCONF transport protocol sub-options to indicate to the client the order to attempt using the protocols for connectivity as described in Section 3.1.

The NETCONF protocol relies on the underlying transport protocol to provide security. Security considerations described in and are also applicable to this document.

IANA is kindly asked to allocate DHCPv6 option codes for OPTION_NETCONF_CONT, OPTION_NETCONF_SSH and OPTION_NETCONF_TLS.

Many thanks to everyone.