Internet DRAFT - draft-fa-netconf-dhcpv6-option
draft-fa-netconf-dhcpv6-option
Network Configuration WG I. Farrer
Internet-Draft Deutsche Telekom AG
Intended status: Standards Track M. Abrahamsson
Expires: April 21, 2014 T-Systems
October 20, 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 21, 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
Farrer & Abrahamsson Expires April 21, 2014 [Page 1]
Internet-Draft NETCONF DHCPv6 Option October 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. NETCONF DHCPv6 Container Option . . . . . . . . . . . . . . . 2
2.1. NETCONF over SSH Sub-Option . . . . . . . . . . . . . . . 3
2.2. NETCONF over TLS Sub-Option . . . . . . . . . . . . . . . 4
3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 4
3.1. Priorities . . . . . . . . . . . . . . . . . . . . . . . . 5
4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
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
Farrer & Abrahamsson Expires April 21, 2014 [Page 2]
Internet-Draft NETCONF DHCPv6 Option October 2013
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) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Farrer & Abrahamsson Expires April 21, 2014 [Page 3]
Internet-Draft NETCONF DHCPv6 Option October 2013
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) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
o If OPTION_NETCONF_CONT does not contain a transport sub-option
implemented by the client, then it MUST be discarded by the
client.
Farrer & Abrahamsson Expires April 21, 2014 [Page 4]
Internet-Draft NETCONF DHCPv6 Option October 2013
o 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.
o 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
Farrer & Abrahamsson Expires April 21, 2014 [Page 5]
Internet-Draft NETCONF DHCPv6 Option October 2013
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 2, 4
Authors' Addresses
Ian Farrer
Deutsche Telekom AG
Bonn,
Germany
Email: ian.farrer@telekom.de
Farrer & Abrahamsson Expires April 21, 2014 [Page 6]
Internet-Draft NETCONF DHCPv6 Option October 2013
Mikael Abrahamsson
T-Systems
Stockholm,
Sweden
Email: mikael.abrahamsson@t-systems.se
Farrer & Abrahamsson Expires April 21, 2014 [Page 7]
