draft-ietf-opsawg-automated-network-configuration-02.txt   draft-ietf-opsawg-automated-network-configuration-03.txt 
Internet Engineering Task Force T. Tsou Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational J. Schoenwaelder, Ed. Intended status: Informational J. Schoenwaelder, Ed.
Expires: May 3, 2012 Jacobs University Bremen Expires: September 13, 2012 Jacobs University Bremen
Y. Shi Y. Shi
Hangzhou H3C Tech. Co., Ltd.
T. Taylor, Ed. T. Taylor, Ed.
Huawei Technologies Huawei Technologies
G. Yang G. Yang
China Telecom China Telecom
October 31, 2011 March 12, 2012
Problem Statement for the Automated Configuration of Large IP Networks Problem Statement for the Automated Configuration of Large IP Networks
draft-ietf-opsawg-automated-network-configuration-02 draft-ietf-opsawg-automated-network-configuration-03
Abstract Abstract
This memo discusses the steps required to bring a large number of This memo discusses the steps required to bring a large number of
devices into service in IP networks in an automated fashion. The devices into service in IP networks in an automated fashion. The
goal of this document is to list known solutions where they exist and goal of this document is to list known solutions where they exist and
to identify gaps that require further specifications. to identify gaps that require further specifications.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on September 13, 2012.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Intra-domain and Inter-domain Scenarios . . . . . . . . . . . 4 2. Intra-domain and Inter-domain Scenarios . . . . . . . . . . . 5
3. Model of the Automated Configuration Process . . . . . . . . . 6 3. Model of the Automated Configuration Process . . . . . . . . . 6
4. Phase 1: Pre-configuration . . . . . . . . . . . . . . . . . . 7 4. Phase 1: Pre-configuration . . . . . . . . . . . . . . . . . . 7
5. Phase 2: Bootstrapping . . . . . . . . . . . . . . . . . . . . 7 5. Phase 2: Bootstrapping . . . . . . . . . . . . . . . . . . . . 7
5.1. Establishment of Link Layer Connectivity . . . . . . . . . 8 5.1. Establishment of Link Layer Connectivity . . . . . . . . . 8
5.2. Acquisition of IP Addresses and Basic Routing 5.2. Acquisition of IP Addresses and Basic Routing
Information . . . . . . . . . . . . . . . . . . . . . . . 8 Information . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Finding the Configuration Server . . . . . . . . . . . . . 8 5.3. Finding the Configuration Server . . . . . . . . . . . . . 9
5.4. Establishing a Secure Channel to the Configuration 5.4. Establishing a Secure Channel to the Configuration
Server . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Phase 3: Initial Configuration . . . . . . . . . . . . . . . . 12 6. Phase 3: Initial Configuration . . . . . . . . . . . . . . . . 12
7. Phase 4: Configuration Auditing . . . . . . . . . . . . . . . 15 7. Phase 4: Configuration Auditing . . . . . . . . . . . . . . . 15
8. Phase 5: Configuration Update . . . . . . . . . . . . . . . . 15 8. Phase 5: Configuration Update . . . . . . . . . . . . . . . . 15
9. Missing Specifications . . . . . . . . . . . . . . . . . . . . 16 9. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
13. Informative References . . . . . . . . . . . . . . . . . . . . 17 13. Informative References . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes since -01 . . . . . . . . . . . . . . . . . . 22 Appendix A. Changes since -02 . . . . . . . . . . . . . . . . . . 22
Appendix B. Changes since -01 . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Many large IP networks are being deployed that entail the Many large IP networks are being deployed that entail the
installation of tens of thousands of new network devices. To keep installation of tens of thousands of new network devices. To keep
costs down, it is desirable to automate the establishment of such costs down, it is desirable to automate the establishment of such
networks to the maximum extent possible. This naturally raises the networks to the maximum extent possible. This naturally raises the
question how new devices can pick up the configuration information question how new devices can pick up the configuration information
they need to operate properly in an automated fashion. The goal of they need to operate properly in an automated fashion. The goal of
skipping to change at page 3, line 47 skipping to change at page 3, line 47
The Broadband Forum has defined a CPE WAN Management Protocol The Broadband Forum has defined a CPE WAN Management Protocol
(running over SOAP/HTTP/TLS) to manage customer premise equipment (running over SOAP/HTTP/TLS) to manage customer premise equipment
(CPE) terminating broadband access networks (typically DSL access (CPE) terminating broadband access networks (typically DSL access
networks) [TR_069]. CPE devices locate and connect to an Auto- networks) [TR_069]. CPE devices locate and connect to an Auto-
Configuration Server (ACS), which provides configuration data and Configuration Server (ACS), which provides configuration data and
software/firmware images and modules. The ACS also performs status software/firmware images and modules. The ACS also performs status
and performance monitoring and diagnostic functions. CPE devices use and performance monitoring and diagnostic functions. CPE devices use
DHCP to locate an ACS and since both peers, the ACS and CPE, can DHCP to locate an ACS and since both peers, the ACS and CPE, can
initiate connections, the protocol can work across network address initiate connections, the protocol can work across network address
translators (NATs). translators (NATs). The DHCP exchange uses vendor-specific options
defined by the Broadband Forum (number 3561 in the IANA Enterprise
Numbers registry).
Next to service provider networks, many large enterprise networks Next to service provider networks, many large enterprise networks
face the same challenge to roll out a large number of network face the same challenge to roll out a large number of network
devices, which often connect to a 3rd party network provider. The devices, which often connect to a 3rd party network provider. The
current development of IP-based home automation and utility current development of IP-based home automation and utility
monitoring technologies might carry the problem to roll out large monitoring technologies might carry the problem to roll out large
numbers of devices that need to automatically configure themselves to numbers of devices that need to automatically configure themselves to
private households. private households.
IETF work on automated configuration goes back to BOOTP [RFC0951], IETF work on automated configuration goes back to BOOTP [RFC0951],
skipping to change at page 4, line 26 skipping to change at page 4, line 28
the distribution of policy information in the network. [RFC3139] the distribution of policy information in the network. [RFC3139]
provides a good insight into this period. More recently, the network provides a good insight into this period. More recently, the network
configuration protocol NETCONF [RFC6241] was devised as an configuration protocol NETCONF [RFC6241] was devised as an
alternative to SNMP, but the development of standard NETCONF alternative to SNMP, but the development of standard NETCONF
configuration data models is just beginning. configuration data models is just beginning.
Recent IETF work closest in spirit to the 3GPP self-organizing Recent IETF work closest in spirit to the 3GPP self-organizing
network effort cited above is embodied in CAPWAP [RFC5415]. Like the network effort cited above is embodied in CAPWAP [RFC5415]. Like the
3GPP work, CAPWAP focusses on the configuration of edge nodes, in a 3GPP work, CAPWAP focusses on the configuration of edge nodes, in a
Wi-Fi rather than cellular network. The CAPWAP work goes beyond that Wi-Fi rather than cellular network. The CAPWAP work goes beyond that
of 3GPP by specifying the process of AC (Access Controller) discovery of 3GPP by specifying the process of Access Controller (AC) discovery
rather than leaving discovery out of scope. With regard to the rather than leaving discovery out of scope. A CAPWAP Wireless
configuration process itself, CAPWAP provides for the download of new Termination Point (WTP) may use broadcasts and multicasts to discover
images to the WTP (Wireless Termination Point). In contrast, local ACs, it may use CAPWAP DHCP options [RFC5417] to obtain IP
[TS_32_500] assumes that this has already been completed for the addresses of ACs, or it may utilize CAPWAP DNS SRV records if a
eNodeB. domain name is known. With regard to the configuration process
itself, CAPWAP provides for the download of new images to the WTP
(Wireless Termination Point). In contrast, [TS_32_500] assumes that
this has already been completed for the eNodeB.
As can seen, standards for the automated configuration of devices in
IP networks have so far been primarily developed for specific network
access technologies (3GPP, Broadband, 802.11 WLANs) and the various
solutions make different assumptions about the services that are
available and they are designed to support a configuration protocol
that is specific to a certain access technology. The aim of this
document is to analyse the various phases of an automated
configuration process and to identify gaps that are currently not
covered in standard and general purpose configuration management
protocols of the IETF.
2. Intra-domain and Inter-domain Scenarios 2. Intra-domain and Inter-domain Scenarios
There are two different scenarios to consider. In the first There are two different scenarios to consider. In the first
scenario, called the Intra-domain Scenario, the new network device N scenario, called the Intra-domain Scenario, the new network device N
is attached to the network operated by the service provider which is is attached to the network operated by the service provider which is
also operating the new device. In the second scenario, called the also operating the new device. In the second scenario, called the
Inter-domain Scenario, the new device N is attached to a third party Inter-domain Scenario, the new device N is attached to a third party
network providing connectivity to the network of the service provider network providing connectivity to the network of the service provider
operating the new device. operating the new device.
skipping to change at page 9, line 4 skipping to change at page 9, line 14
5.3. Finding the Configuration Server 5.3. Finding the Configuration Server
Four alternatives are available for finding the configuration server: Four alternatives are available for finding the configuration server:
o pre-configuration; o pre-configuration;
o DHCP configuration; o DHCP configuration;
o Service Location Protocol [RFC2608]; or o Service Location Protocol [RFC2608]; or
o DNS service discovery using DNS SRV records [RFC2782]. o DNS service discovery using DNS SRV records [RFC2782].
Pre-configuration of an IP address is brittle and not recommended. Pre-configuration of an IP address is brittle and not recommended
unless the IP address is used as an anycast address. In the case of
an IP anycast address, the routing system will select one out of an
anycast cluster of configuration servers the devices connects to.
For this to work well, all configuration servers in the anycast
cluster should provide the same configuration data.
The pre-configuration of a Uniform Resource Identifier (URI) or fully The pre-configuration of a Uniform Resource Identifier (URI) or fully
qualified domain name (FQDN) is a slightly better approach since this qualified domain name (FQDN) is a slightly better approach than pre-
allows for a limited dynamic mapping of the name to an IP address. configuring non-anycast IP addresses since this allows for a limited
One variant that has been suggested is to burn the URI of a vendor dynamic mapping of the name to an IP address. One variant that has
server into the device's firmware along with a device identifier, and been suggested is to burn the URI of a vendor server into the
have that server redirect to the URI of the service provider's device's firmware along with a device identifier, and have that
configuration server based on the device identity. Such an approach server redirect to the URI of the service provider's configuration
requires that the device vendor's redirection server is always server based on the device identity. Such an approach requires that
reachable, that the device vendor offers such a redirection service the device vendor's redirection server is always reachable, that the
for the lifetime of their devices and that service providers are able device vendor offers such a redirection service for the lifetime of
to update the URI of the service provider's redirection server. their devices and that service providers are able to update the URI
Furthermore, this approach can lead to problems if certificates are of the service provider's redirection server. Furthermore, this
used to authenticate the involved parties if a service provider tries approach can lead to problems if certificates are used to
to prevent the usage of a vendor's redirection service. Finally, authenticate the involved parties if a service provider tries to
this approach also requires a trust relationship between the vendor prevent the usage of a vendor's redirection service. Finally, this
and the service provider and agreement on a protocol to update the approach also requires a trust relationship between the vendor and
the service provider and agreement on a protocol to update the
redirect information on the vendor's server. As a consequence of redirect information on the vendor's server. As a consequence of
these considerations, using this approach is not recommended. these considerations, using this approach is not recommended.
DHCP configuration can use the usual DHCP options and is technically DHCP configuration can use the usual DHCP options and is technically
straightforward since DHCP is widely used by end user devices to straightforward since DHCP is widely used by end user devices to
obtain basic configuration information. There is, however, no obtain basic configuration information. There is, however, no
standardized DHCP option to communicate the address of a standardized DHCP option to communicate the address of a
configuration server. configuration server.
The Service Location Protocol (SLP) has seen some usage to locate The Service Location Protocol (SLP) has seen some usage to locate
skipping to change at page 10, line 44 skipping to change at page 11, line 12
This leaves the mutual authentication process itself. This has two This leaves the mutual authentication process itself. This has two
aspects: the security protocol used to perform authentication, and aspects: the security protocol used to perform authentication, and
initial keying methodology. The security protocol is tied together initial keying methodology. The security protocol is tied together
with the choice of configuration data transport, but the basic with the choice of configuration data transport, but the basic
choices are: choices are:
o IP Security (IPsec) [RFC4301]; o IP Security (IPsec) [RFC4301];
o Transport Layer Security (TLS) [RFC5246]; o Transport Layer Security (TLS) [RFC5246];
o Datagram Transport Layer Security (DTLS) [RFC4347]; o Datagram Transport Layer Security (DTLS) [RFC6347];
o Secure Shell (SSH) [RFC4251], [RFC4252], [RFC4253], and [RFC4254]; o Secure Shell (SSH) [RFC4251], [RFC4252], [RFC4253], and [RFC4254];
and and
o SNMPv3's User-based Security Model (USM) [RFC3414]. o SNMPv3's User-based Security Model (USM) [RFC3414].
For initial keying methodology, the two basic choices are between For initial keying methodology, the two basic choices are between
pre-shared secrets and certificates. All of the security protocols pre-shared secrets and certificates. All of the security protocols
listed above except USM support both methods. USM supports pre- listed above except USM support both methods. USM supports pre-
shared secrets only. shared secrets only.
skipping to change at page 13, line 16 skipping to change at page 13, line 33
limited flexibility and they differ in their degree of integration limited flexibility and they differ in their degree of integration
with SSH. with SSH.
o The Control And Provisioning of Wireless Access Points (CAPWAP) o The Control And Provisioning of Wireless Access Points (CAPWAP)
protocol [RFC5415] can be used to control the download of images. protocol [RFC5415] can be used to control the download of images.
CAPWAP can be secured by running CAPWAP over DTLS. CAPWAP can be secured by running CAPWAP over DTLS.
In the second class, we find the following configuration protocols: In the second class, we find the following configuration protocols:
o Version 3 of the Simple Network Management Protocol (SNMPv3) o Version 3 of the Simple Network Management Protocol (SNMPv3)
[RFC3411]-[RFC3418] can be used to manipulate MIB objects and to [RFC3411] can be used to manipulate MIB objects and to carry event
carry event notifications. It has its own security protocol (USM) notifications. SNMPv3 has its own security protocol (USM)
but can also run over SSH [RFC5592], TLS, or DTLS [RFC6353]. [RFC3414] but can also run over the secure transports SSH
[RFC5592], TLS, or DTLS [RFC6353].
o The Common Open Policy Service for Policy Provisioning protocol o The Common Open Policy Service for Policy Provisioning protocol
(COPS-PR) [RFC3084] was designed to provision structured policy (COPS-PR) [RFC3084] was designed to provision structured policy
information from a Policy Decision Point (PDP) to a Policy information from a Policy Decision Point (PDP) to a Policy
Enforcement Point (PEP). The COPS protocol [RFC2748] provides an Enforcement Point (PEP). The COPS protocol [RFC2748] provides an
integrity object that can achieve authentication, message integrity object that can achieve authentication, message
integrity, and replay prevention. Optionally, COPS and COPS-PR integrity, and replay prevention. Optionally, COPS and COPS-PR
can run over TLS. can run over TLS.
o The NETCONF protocol [RFC6241] provides mechanisms to install, o The NETCONF protocol [RFC6241] provides mechanisms to install,
skipping to change at page 15, line 30 skipping to change at page 15, line 40
SNMP modules into YANG modules [I-D.ietf-netmod-smi-yang]. SNMP modules into YANG modules [I-D.ietf-netmod-smi-yang].
Another important auditing activity is the analysis of system events. Another important auditing activity is the analysis of system events.
The SYSLOG protocol [RFC5424] is widely used for this purpose but The SYSLOG protocol [RFC5424] is widely used for this purpose but
SNMPv3 and NETCONF can ship event notifications as well. SNMPv3 and NETCONF can ship event notifications as well.
Translations of SNMP notifications into structured SYSLOG messages Translations of SNMP notifications into structured SYSLOG messages
and vice versa do exist [RFC5675] [RFC5676]. NETCONF can carry and vice versa do exist [RFC5675] [RFC5676]. NETCONF can carry
SYSLOG content as well [RFC5277]. SYSLOG content as well [RFC5277].
NETCONF provides generic notifications that help with tracking NETCONF provides generic notifications that help with tracking
configuration changes [I-D.ietf-netconf-system-notifications]. configuration changes [RFC6470]. Similar standardized configuration
Similar standardized configuration change notifications do not exist change notifications do not exist for SNMP or SYSLOG.
for SNMP or SYSLOG.
8. Phase 5: Configuration Update 8. Phase 5: Configuration Update
Configuration updates can in principle be handled with the same Configuration updates can in principle be handled with the same
protocol that delivered the initial configuration. However, in some protocol that delivered the initial configuration. However, in some
deployments, the mechanism used for initial configuration might be deployments, the mechanism used for initial configuration might be
different. different.
An advantage of NETCONF over SNMPv3 and CAPWAP in the context of An advantage of NETCONF over SNMPv3 and CAPWAP in the context of
configuration updates is the support of concurrent updates through configuration updates is the support of concurrent updates through
explicit locking mechanisms and the support of network wide explicit locking mechanisms and the support of network wide
configuration change transactions through the confirmed commit configuration change transactions through the confirmed commit
capability. capability.
9. Missing Specifications 9. Gap Analysis
This document discussed the automated configuration of devices in This document discussed the automated configuration of devices in
service provider networks. Several gaps were identified requiring large IP networks. Several gaps were identified requiring further
further specification: specification:
G1: Definition of a DHCP option to provide the IPv4/IPv6 address of G1: Definition of a DHCP option to provide the IPv4/IPv6 address of
a configuration server. Such an option allows a joining device a configuration server. Such an option allows a joining device
to pickup the configuration server's address as part of the DHCP to pickup the configuration server's address as part of the DHCP
exchange. This is particularly interesting for Intra-domain exchange. This is particularly interesting for Intra-domain
Scenarios. Scenarios.
G2: Definition of DNS SRV records for locating configuration G2: Definition of DNS SRV records for locating configuration
servers. Such an option allows a joining device to lookup the servers. Using SRV records, a joining device can lookup the
configuration server's in the DNS; this is particularly useful configuration server's address in the DNS. This is particularly
in an Inter-domain Scenario. useful in an Inter-domain Scenario.
G3: Definition of a SLP template for discovering configuration G3: Definition of a SLP template for discovering configuration
servers. Such a template is useful only in environments where servers. Such a template is useful only in environments where
SLP is used also for other purposes. SLP is used also for other purposes.
G4: Definition of NETCONF data models to support the download / G4: Definition of NETCONF data models to support the download /
update of software images through NETCONF. update of software images through NETCONF.
G5: Definition of NETCONF data models for collecting basic system G5: Definition of NETCONF data models for collecting basic system
information and integrity information (e.g., checksums of information and integrity information (e.g., checksums of
skipping to change at page 17, line 26 skipping to change at page 17, line 33
Finally, [RFC6092] discusses security capabilities for customer Finally, [RFC6092] discusses security capabilities for customer
premises equipment providing residential IPv6 Internet service. premises equipment providing residential IPv6 Internet service.
11. IANA Considerations 11. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
12. Acknowledgements 12. Acknowledgements
Thanks to Mehmet Ersue, Wesley George, Yiu Lee, Kent Watsen, and Thanks to Mehmet Ersue, Wesley George, Yiu Lee, Christopher
Cathy Zhou for their help in preparing this memo. Liljenstolpe, Kent Watsen, and Cathy Zhou for their help in preparing
this memo.
13. Informative References 13. Informative References
[I-D.ietf-netconf-system-notifications]
Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications",
draft-ietf-netconf-system-notifications-06 (work in
progress), October 2011.
[I-D.ietf-netmod-smi-yang] [I-D.ietf-netmod-smi-yang]
Schoenwaelder, J., "Translation of SMIv2 MIB Modules to Schoenwaelder, J., "Translation of SMIv2 MIB Modules to
YANG Modules", draft-ietf-netmod-smi-yang-01 (work in YANG Modules", draft-ietf-netmod-smi-yang-04 (work in
progress), July 2011. progress), January 2012.
[I-D.ietf-secsh-filexfer] [I-D.ietf-secsh-filexfer]
Galbraith, J. and O. Saarenmaa, "SSH File Transfer Galbraith, J. and O. Saarenmaa, "SSH File Transfer
Protocol", draft-ietf-secsh-filexfer-13 (work in Protocol", draft-ietf-secsh-filexfer-13 (work in
progress), July 2006. progress), July 2006.
[I-D.kwatsen-reverse-ssh] [I-D.kwatsen-reverse-ssh]
Watsen, K., "Reverse Secure Shell (Reverse SSH)", Watsen, K., "Reverse Secure Shell (Reverse SSH)",
draft-kwatsen-reverse-ssh-01 (work in progress), draft-kwatsen-reverse-ssh-01 (work in progress),
June 2011. June 2011.
[I-D.sarikaya-core-sbootstrapping] [I-D.sarikaya-core-sbootstrapping]
Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. Sarikaya, B., Cragie, R., Moskowitz, R., Ohba, Y., and Z.
Cragie, "Security Bootstrapping of Resource-Constrained Cao, "Security Bootstrapping of Resource-Constrained
Devices", draft-sarikaya-core-sbootstrapping-02 (work in Devices", draft-sarikaya-core-sbootstrapping-03 (work in
progress), June 2011. progress), October 2011.
[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985. September 1985.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985. STD 9, RFC 959, October 1985.
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992. RFC 1350, July 1992.
skipping to change at page 19, line 32 skipping to change at page 19, line 34
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, December 2002.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003. Management Workshop", RFC 3535, May 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
October 2005. October 2005.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
skipping to change at page 20, line 12 skipping to change at page 20, line 9
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006. Transport Layer Protocol", RFC 4253, January 2006.
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Connection Protocol", RFC 4254, January 2006. Connection Protocol", RFC 4254, January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008. Notifications", RFC 5277, July 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
Provisioning of Wireless Access Points (CAPWAP) Protocol Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification", RFC 5415, March 2009. Specification", RFC 5415, March 2009.
[RFC5417] Calhoun, P., "Control And Provisioning of Wireless Access
Points (CAPWAP) Access Controller DHCP Option", RFC 5417,
March 2009.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009. Protocol (SNMP)", RFC 5592, June 2009.
[RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network
Management Protocol (SNMP) Notifications to SYSLOG Management Protocol (SNMP) Notifications to SYSLOG
Messages", RFC 5675, October 2009. Messages", RFC 5675, October 2009.
skipping to change at page 21, line 23 skipping to change at page 21, line 22
January 2011. January 2011.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010. RFC 6106, November 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011. RFC 6241, June 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)", Model for the Simple Network Management Protocol (SNMP)",
RFC 6353, July 2011. RFC 6353, July 2011.
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based
DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,
August 2011. August 2011.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, February 2012.
[TR_069] Blackford, J., Ed., Kirksey, H., Ed., and W. Lupton, Ed., [TR_069] Blackford, J., Ed., Kirksey, H., Ed., and W. Lupton, Ed.,
"CPE WAN Management Protocol", Broadband Forum TR-069, "CPE WAN Management Protocol", Broadband Forum TR-069,
November 2010. November 2010.
[TS_32_500] [TS_32_500]
3rd Generation Partnership Project, "3rd Generation 3rd Generation Partnership Project, "3rd Generation
Partnership Project; Technical Specification Group Partnership Project; Technical Specification Group
Services and System Aspects; Telecommunication Management; Services and System Aspects; Telecommunication Management;
Self-Organizing Networks (SON); Concepts and requirements Self-Organizing Networks (SON); Concepts and requirements
(Release 9)", 3GPP TS 32.500, 2010. (Release 9)", 3GPP TS 32.500, 2010.
[TS_36_300] [TS_36_300]
3rd Generation Partnership Project, "3rd Generation 3rd Generation Partnership Project, "3rd Generation
Partnership Project; Technical Specification Group Radio Partnership Project; Technical Specification Group Radio
Access Network; Evolved Universal Terrestrial Radio Access Access Network; Evolved Universal Terrestrial Radio Access
(E-UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access
Network (E-UTRAN); Overall description; Stage 2 (Release Network (E-UTRAN); Overall description; Stage 2 (Release
9)", 3GPP TS 36.300, 2010. 9)", 3GPP TS 36.300, 2010.
Appendix A. Changes since -01 Appendix A. Changes since -02
Incorporated feedback from Christopher Liljenstolpe concerning
anycasts.
Added additional text to the introduction in order to better
clarify the purpose of this document.
Editorial improvements, updated references, etc.
Appendix B. Changes since -01
Incorporated feedback from Kent Watsen and Wesley George. Incorporated feedback from Kent Watsen and Wesley George.
Editorial improvements, updated references, etc. Editorial improvements, updated references, etc.
Authors' Addresses Authors' Addresses
Tina Tsou Tina Tsou
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
skipping to change at page 22, line 28 skipping to change at page 23, line 4
Email: tena@huawei.com Email: tena@huawei.com
Juergen Schoenwaelder (editor) Juergen Schoenwaelder (editor)
Jacobs University Bremen Jacobs University Bremen
Campus Ring 1 Campus Ring 1
Bremen 28759 Bremen 28759
Germany Germany
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
Yang Shi Yang Shi
Hangzhou H3C Tech. Co., Ltd. Huawei Technologies
Beijing R&D Center of H3C, Digital Technology Plaza, 156, Beiqing Road, Zhongguancun, Haidian District
No. 9 Shangdi 9th Street, Haidian District Beijing
Beijing 100085
P.R. China P.R. China
Phone: +86 010 82775276 Phone: +86 10 60614043
Email: young@h3c.com Email: shiyang1@huawei.com
Tom Taylor (editor) Tom Taylor (editor)
Huawei Technologies Huawei Technologies
1852 Lorraine Ave. 1852 Lorraine Ave.
Ottawa K1H 6Z8 Ottawa K1H 6Z8
Canada Canada
Email: tom111.taylor@bell.net Email: tom111.taylor@bell.net
Guoliang Yang Guoliang Yang
China Telecom China Telecom
No. 109 Zhongshan Ave. (West),Tianhe District No. 109 Zhongshan Ave. (West), Tianhe District
Guangzhou Guangzhou
P.R. China P.R. China
Phone: +86 020 38639615 Phone: +86 020 38639615
Email: yanggl@gsta.com Email: iamyanggl@gmail.com
 End of changes. 40 change blocks. 
87 lines changed or deleted 113 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/