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

Abstract

This document defines DHCPv6 options for bootstrapping the NETCONF protocol on devices.

Requirements Language

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].

Status of This Memo

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 Notice

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.


Table of Contents

1. Introduction

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.

2. NETCONF DHCPv6 Container Option

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

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

2.1. NETCONF over SSH Sub-Option

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

option-code
OPTION_NETCONF_SSH (TBA2)
option-len
Variable
priority
8-bit integer. Described in Section 3.1
dest-port
16-bit integer to be used by the client as the destination layer 4 port to initiate the SSH connection to.
server-fqdn
List of FQDNs to use for the NETCONF server, formatted according to Section 8 of [RFC3315].

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.

2.2. NETCONF over TLS Sub-Option

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

option-code
OPTION_NETCONF_TLS (TBA3)
option-len
Variable
priority
8-bit integer. Described in Section 3.1
dest-port
16-bit integer to be used by the client as the destination layer 4 port for initiating the TLS connection
server-fqdn
List of FQDNs to use for the NETCONF server, formatted according to Section 8 of [RFC3315].

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.

3. DHCPv6 Client Behavior

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.

3.1. Priorities

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.

4. DHCPv6 Server Behavior

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.

5. Security Considerations

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.

6. IANA Considerations

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

7. Acknowledgements

Many thanks to everyone.

8. References

8.1. Normative References

[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.

8.2. Informative References

[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.

Index

4
4.1

Authors' Addresses

Ian Farrer Deutsche Telekom AG Bonn, Germany EMail: ian.farrer@telekom.de
Mikael Abrahamsson T-Systems Stockholm, Sweden EMail: mikael.abrahamsson@t-systems.se