| Network Configuration WG | I. Farrer |
| Internet-Draft | Deutsche Telekom AG |
| Intended status: Standards Track | M. Abrahamsson |
| Expires: April 24, 2014 | T-Systems |
| October 21, 2013 |
NETCONF DHCPv6 Option
draft-fa-netconf-dhcpv6-option-00
This 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 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014.
Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
NETCONF [RFC6241] combined with the YANG [RFC6020] 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 [RFC3315] 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 [RFC6242] and NETCONF over TLS [RFC5539]. If necessary in the future, the option could be extended to support additional transport protocols through the definition of new sub-options.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NETCONF_CONT | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-options | | (variable) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NETCONF DHCPv6 Option Format
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 [RFC6242].
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NETCONF_SSH | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | priority | dest-port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | server fqdn(s) | | (variable length) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NETCONF over SSH Sub-Option Format
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 [RFC5539].
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NETCONF_TLS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | priority | dest-port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | server-fqdn(s) | | (variable length) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NETCONF over TLS Sub-Option Format
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:
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 [RFC5539] and [RFC6242] 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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. |
| [RFC6241] | Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. |
| [RFC5539] | Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009. |
| [RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. |
| [RFC6242] | Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011. |
| 4 | |
| 4.1 |