NETCONF DHCPv6 OptionDeutsche Telekom AGBonnGermanyian.farrer@telekom.deT-SystemsStockholmSwedenmikael.abrahamsson@t-systems.se
ops
Network Configuration WGThis document defines DHCPv6 options for bootstrapping the NETCONF
protocol on devices.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.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)VariableContains 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)Variable8-bit integer. Described in Section 3.116-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)Variable8-bit integer. Described in Section 3.116-bit integer to be used by the client as
the destination layer 4 port for initiating the TLS connectionList 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-optionsIf 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.