draft-ietf-opsawg-automated-network-configuration-00.txt   draft-ietf-opsawg-automated-network-configuration-01.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: August 12, 2011 Jacobs University Bremen Expires: December 2, 2011 Jacobs University Bremen
Y. Shi Y. Shi
Hangzhou H3C Tech. Co., Ltd. Hangzhou H3C Tech. Co., Ltd.
T. Taylor, Ed. T. Taylor, Ed.
Huawei Technologies Huawei Technologies
February 8, 2011 G. Yang
China Telecom
May 31, 2011
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-00 draft-ietf-opsawg-automated-network-configuration-01
Abstract Abstract
This memo discusses the steps required to bring network devices in a This memo discusses the steps required to bring network devices in a
service provider network into service in an automated fashion. The service provider network into service in an automated fashion. The
memo identifies known solutions where they exist, but notes some gaps memo identifies known solutions where they exist, but notes some gaps
that require further specification. that require further specification.
Status of this Memo Status of this Memo
skipping to change at page 1, line 44 skipping to change at page 1, line 46
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 12, 2011. This Internet-Draft will expire on December 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 35 skipping to change at page 2, line 37
5.3. Finding the Configuration Server . . . . . . . . . . . . . 7 5.3. Finding the Configuration Server . . . . . . . . . . . . . 7
5.4. Establishing a Secure Channel to the Configuration 5.4. Establishing a Secure Channel to the Configuration
Server . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Initial Configuration and Configuration Updates . . . . . . . 10 6. Initial Configuration and Configuration Updates . . . . . . . 10
7. Configuration Auditing . . . . . . . . . . . . . . . . . . . . 13 7. Configuration Auditing . . . . . . . . . . . . . . . . . . . . 13
8. Missing Specifications . . . . . . . . . . . . . . . . . . . . 13 8. Missing Specifications . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. Informative References . . . . . . . . . . . . . . . . . . . . 15 12. Informative References . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
New service provider networks are being deployed that entail the New service provider 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 and the configuration of these network devices to the networks and the configuration of these network devices to the
maximum extent possible. A certain amount of the information needed maximum extent possible. A certain amount of the information needed
to operate them must be pre-configured by the vendor or service to operate them must be pre-configured by the vendor or service
skipping to change at page 7, line 29 skipping to change at page 7, line 29
to be available in the general case. to be available in the general case.
5.2. Acquisition of IP Addresses and Basic Routing Information 5.2. Acquisition of IP Addresses and Basic Routing Information
For IPv4, DHCPv4 [RFC2131] is widely deployed and the usual way to For IPv4, DHCPv4 [RFC2131] is widely deployed and the usual way to
obtain an IPv4 address, the IPv4 address of a link-local router and obtain an IPv4 address, the IPv4 address of a link-local router and
the IPv4 address of a DNS server. For IPv6, a choice has to be made the IPv4 address of a DNS server. For IPv6, a choice has to be made
between stateful DHCPv6 [RFC3315] versus stateless DHCPv6 [RFC3736] between stateful DHCPv6 [RFC3315] versus stateless DHCPv6 [RFC3736]
combined with stateless address autoconfiguration [RFC4862]. In the combined with stateless address autoconfiguration [RFC4862]. In the
latter case, DHCPv6 is needed to configure parameters such as DNS latter case, DHCPv6 is needed to configure parameters such as DNS
server addresses. An experimental routing advertisement option to server addresses. A routing advertisement option to configure the
configure the IPv6 address of a DNS server as part of the stateless IPv6 address of a DNS server as part of the stateless address
address autoconfiguration is defined in [RFC5006] and may become a autoconfiguration is defined in [RFC6106].
standards-track specification.
Some security protection is provided in this stage by using DHCP Some security protection is provided in this stage by using DHCP
authentication [RFC3118]. However, security of the configuration authentication [RFC3118]. However, security of the configuration
process as a whole has to be assured by other means. This is process as a whole has to be assured by other means. This is
discussed further below. discussed further below.
Currently the lack of a stable identifier for use in DHCPv6 messaging Currently the lack of a stable identifier for use in DHCPv6 messaging
is an impediment to authentication of the joining device. is an impediment to authentication of the joining device.
[I-D.ietf-dhc-duid-uuid] discusses the problems with the current [I-D.ietf-dhc-duid-uuid] discusses the problems with the current
DHCPv6 identifiers (DUIDs) and proposes a new form that could be a DHCPv6 identifiers (DUIDs) and proposes a new form that could be a
more stable alternative. more stable alternative.
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 SRV records [RFC2782]. o DNS service discovery using 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.
Pre-configuration of a Uniform Resource Identifier (URI) or fully Pre-configuration of a Uniform Resource Identifier (URI) or fully
qualified domain name (FQDN) is a better approach. One variant that qualified domain name (FQDN) is a better approach. One variant that
has been suggested is to burn the URI of a vendor server into the has been suggested is to burn the URI of a vendor server into the
device's firmware along with a device identifier, and have that device's firmware along with a device identifier, and have that
server redirect to the URI of the service provider's configuration server redirect to the URI of the service provider's configuration
skipping to change at page 10, line 43 skipping to change at page 10, line 40
carry device identity, due to lack of specifications allowing the use carry device identity, due to lack of specifications allowing the use
of SubjectAltName to carry MAC addresses. This issue needs to be of SubjectAltName to carry MAC addresses. This issue needs to be
investigated further if another form of device unique identity is investigated further if another form of device unique identity is
used, as discussed above. used, as discussed above.
Middleboxes such as NATs or firewalls may impose restriction on which Middleboxes such as NATs or firewalls may impose restriction on which
party is able to initiate communication. In the common case of NATs party is able to initiate communication. In the common case of NATs
in IPv4 access networks, communication can only be established from in IPv4 access networks, communication can only be established from
the device to the configuration server. Not all secure transports, the device to the configuration server. Not all secure transports,
in particular those where authentication is not symmetric, support in particular those where authentication is not symmetric, support
this "call home" mode of operation. this "call home" mode of operation. A recent proposal to reverse the
establishment of the TCP connection for SSH can be found in
[I-D.kwatsen-reverse-ssh].
6. Initial Configuration and Configuration Updates 6. Initial Configuration and Configuration Updates
As mentioned at the beginning, the configuration data being As mentioned at the beginning, the configuration data being
downloaded may be a combination of software and configuration downloaded may be a combination of software and configuration
parameters. Some of the data will be vendor-specific, not subject to parameters. Some of the data will be vendor-specific, not subject to
standardization. It appears that there is a continuing debate on standardization. It appears that there is a continuing debate on
whether the configuration data should be pushed to the joining device whether the configuration data should be pushed to the joining device
or whether the device should pull the configuration data down. In or whether the device should pull the configuration data down. In
the latter case, the device needs to know about the existence of the the latter case, the device needs to know about the existence of the
skipping to change at page 15, line 23 skipping to change at page 15, line 23
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.
10. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Contributors 11. Contributors
Thanks to Mehmet Ersue, Yiu Lee, and Cathy Zhou Ersue for help in Thanks to Mehmet Ersue, Yiu Lee, and Cathy Zhou for their help in
preparing this memo. preparing this memo.
12. Informative References 12. Informative References
[I-D.ietf-dhc-duid-uuid] [I-D.ietf-dhc-duid-uuid]
Narten, T. and J. Johnson, "Definition of the UUID-based Narten, T. and J. Johnson, "Definition of the UUID-based
DHCPv6 Unique Identifier (DUID-UUID)", DHCPv6 Unique Identifier (DUID-UUID)",
draft-ietf-dhc-duid-uuid-02 (work in progress), draft-ietf-dhc-duid-uuid-03 (work in progress),
December 2010. February 2011.
[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]
Watsen, K., "Reverse Secure Shell (Reverse SSH)",
draft-kwatsen-reverse-ssh-00 (work in progress), May 2011.
[I-D.sarikaya-core-sbootstrapping] [I-D.sarikaya-core-sbootstrapping]
Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security
Bootstrapping of Resource-Constrained Devices", Bootstrapping of Resource-Constrained Devices",
draft-sarikaya-core-sbootstrapping-01 (work in progress), draft-sarikaya-core-sbootstrapping-01 (work in progress),
January 2011. January 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",
skipping to change at page 18, line 9 skipping to change at page 18, line 14
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 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.
[RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Option for DNS Configuration",
RFC 5006, 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.
skipping to change at page 18, line 51 skipping to change at page 18, line 52
Notifications", RFC 5676, October 2009. Notifications", RFC 5676, October 2009.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009. STD 69, RFC 5730, August 2009.
[RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)", Model for the Simple Network Management Protocol (SNMP)",
RFC 5953, August 2010. RFC 5953, August 2010.
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
Options for Network Boot", RFC 5970, June 2010. Options for Network Boot", RFC 5970, September 2010.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, Residential IPv6 Internet Service", RFC 6092,
January 2011. January 2011.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
[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. Open Issues
The document should discuss the usage of VPNs in the Inter-domain
scenario.
Authors' Addresses Authors' Addresses
Tina Tsou Tina Tsou
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
P.R. China P.R. China
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. Hangzhou H3C Tech. Co., Ltd.
Beijing R&D Center of H3C, Digital Technology Plaza, Beijing R&D Center of H3C, Digital Technology Plaza,
NO.9 Shangdi 9th Street, Haidian District, No. 9 Shangdi 9th Street, Haidian District
Beijing Beijing 100085
China(100085) P.R. China
Phone: +86 010 82775276 Phone: +86 010 82775276
Email: young@h3c.com Email: young@h3c.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
China Telecom
No. 109 Zhongshan Ave. (West),Tianhe District
Guangzhou
P.R. China
Phone: +86 020 38639615
Email: yanggl@gsta.com
 End of changes. 20 change blocks. 
29 lines changed or deleted 29 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/