AN Use Case BOF S. Jiang, Ed. Internet-Draft Huawei Technologies Co., Ltd Intended status: Informational B. Carpenter Expires: October 30, 2014 Univ. of Auckland Q. Sun China Telecom April 28, 2014 Autonomic Networking Use Case for Auto Address Management draft-jiang-auto-addr-management-00 Abstract This document describes a use case for autonomic address management in large-scale networks. It is one of a series of use cases intended to illustrate requirements for autonomic networking. 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 October 30, 2014. Copyright Notice Copyright (c) 2014 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 Jiang, et al. Expires October 30, 2014 [Page 1] Internet-Draft Auto Addr Management Use case April 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 3. Intended User and Administrator Experience . . . . . . . . . 3 4. Analysis of Parameters and Information Involved . . . . . . . 3 4.1. Parameters each device can decide for itself . . . . . . 4 4.2. Information needed from policy intent . . . . . . . . . . 5 5. Interaction with other devices . . . . . . . . . . . . . . . 5 5.1. Information needed from other devices . . . . . . . . . . 5 5.2. Monitoring, diagnostics and reporting . . . . . . . . . . 6 6. Comparison with current solutions . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction This document is one of a set of use cases being developed to clarify the requirements for discovery and negotiation protocols for autonomic networking (AN). The background to AN is described in [I-D.irtf-nmrg-autonomic-network-definitions] and [I-D.irtf-nmrg-an-gap-analysis]. A problem statement and outline requirements for the negotiation protocol are given in [I-D.jiang-config-negotiation-ps]. This document is dedicated to how to make IP address management in large-scale networks as autonomic as possible, including operator (ISP) networks and large enterprise networks. Although this document is targeting pure IPv6 networks, autonomically sharing public IPv4 addresses among the Address Family Transition Routers (AFTRs) [RFC6333] or NAT64 [RFC6146] devices is also discussed. Note in draft: This version is preliminary. In particular, opinions may vary about how concrete vs how abstract a use case should be. 2. Problem Statement The autonomic networking use case considered here is autonomic IP address management in large-scale networks. Jiang, et al. Expires October 30, 2014 [Page 2] Internet-Draft Auto Addr Management Use case April 2014 Although DHCPv6 Prefix Delegation [RFC3633] has supported automated delegation of IPv6 prefixes, the prefix management is still largely depending on human planning. In other words, there is no basic information or policies to support autonomic decisions on the prefix length that each router should request or be delegated, according to its role in the network. Roles could be locally defined or could be generic (edge router, interior router, etc.). Furthermore, the current IPv6 prefix management by humans is rigid and static after initial planning. Additionally, the management of public IPv4 addresses on AFTRs or NAT64 devices is similarly rigid and static. The utilisation rate of addresses depends on the initial plan. Efficient utilisation of public IPv4 addresses is the most important requirement since they are a limited resource during the IPv4 exhaustion period. The problem to be solved by AN is how to dynamically and autonomically manage IPv6 address space and public IPv4 addresses on AFTRs or NAT64 devices in large-scale networks, so that IP addresses can be used efficiently. The AN approach discussed in this document is based on the assumption that there was a generic dicovery and negotiation protocol that enables direct negotiation between intelligent IP routers. [I-D.jiang-config-negotiation-protocol] is one of the attempts at such a protocol. 3. Intended User and Administrator Experience The intended experience is, for the administrator(s) of a large-scale network, that the management of IPv6 address space can be run with minimum efforts, for both the network and network device initiation stage and during running time. In the most ideal scenario, the administrator(s) only have to configure a single IPv6 prefix for the whole network and the initial prefix length for each device role. Where applicable, another intended experience is dynamically and autonomically sharing public IPv4 addresses on AFTRs or NAT64 devices without human intervention. The administrator only has to configure the total available IPv4 address range. The actual address usage needs to be logged for the potential offline management operations including audit and security incident tracing. 4. Analysis of Parameters and Information Involved For specific purposes of address management, a few parameters are involved on each device (some of them can be pre-configured before they are connected). They include: Jiang, et al. Expires October 30, 2014 [Page 3] Internet-Draft Auto Addr Management Use case April 2014 o Identity of this device. It can be verified by the certification authority (CA) that is maintained by the network administrator(s). o Identity of a trust anchor which is certification authority (CA) that is maintained by the network administrator(s). o Role of this device. o An IPv6 prefix length for this device. o An IPv6 prefix that is assigned to this device and its downstream devices. o A public IPv4 address pool if the device acts as an AFTR or NAT64 device. A few parameters are involved in the network as a whole. They are: o Identity of a trust anchor which is a certification authority (CA) that is maintained by the network administrator(s). o Total IPv6 address space. It is one (or several) IPv6 prefix(es). o A public IPv4 address pool if the network provides IPv4 over IPv6 access or IPv4/IPv6 transition services. o The initial prefix length for each device role. 4.1. Parameters each device can decide for itself This section identifies those of the above parameters that do not need external information in order for the devices concerned to set them to a reasonable value after bootstrap or after a network disruption. There are few of these: o Role of this device, this includes whether this device acts as an AFTR or NAT64 device. o Default IPv6 prefix length for this device. o Identity of this device. The device may be shipped from the manufacture with pre-configured role and default prefix length. Jiang, et al. Expires October 30, 2014 [Page 4] Internet-Draft Auto Addr Management Use case April 2014 4.2. Information needed from policy intent This section identifies those parameters that need external information about policy intent in order for the devices concerned to set them to a non-default value. o Non-default value for the IPv6 prefix length for this device. This needs to be decided based on the role of this device. o The initial prefix length for each device role. o Identity of a trust anchor. o Whether to allow the device request more address space. o Whether to allow the device to request or share public IPv4 address. o The policy when to request more address space, for example, the address usage reaches a certain limit or percentage. 5. Interaction with other devices 5.1. Information needed from other devices This section identifies those of the above parameters that need external information from neighbor devices (including the upstream devices). In many cases, two-way dialogue with neighbor devices is needed to set or optimise them. o Identity of a trust anchor. o The device will need to discover their neighbors, particularly, the upstream device, from which it can acquire IPv6 address space. o The initial prefix length for each device role, particularly for its own downstream devices. o The default value of the IPv6 prefix length may be overridden by a non-default value. o The device will need to request and acquire IPv6 prefix that is assigned to this device and its downstream devices. o The device may respond to prefix delegation request from its downstream devices. Jiang, et al. Expires October 30, 2014 [Page 5] Internet-Draft Auto Addr Management Use case April 2014 o The device may require to be assigned more IPv6 address space, if it used up its assigned IPv6 address space. o An AFTR or NAT64 device will need to request and acquire an initial public IPv4 address pool. o An AFTR or NAT64 device will need to discover its neighbors, from which it may acquire spare public IPv4 addresses. o An AFTR or NAT64 device may acquire spare public IPv4 addresses with their associated available period. 5.2. Monitoring, diagnostics and reporting This section discusses what role devices should play in monitoring, fault diagnosis, and reporting. o The actual address assignments need to be logged for the potential offline management operations. o In general, the usage situation of address space should be reported to the network administrators, in an abstract way, for example, statistics or visualized report. o A forecast of address exhaustion should be reported. 6. Comparison with current solutions This section briefly compares the above use case with current solutions. Currently, the address management is still largely depending on human planning. It is rigid and static after initial planning. The address requests will fail if the configured address space is used up. Some functions, for autonomic and dynamic address management, may be achievable by extending the existing protocols, for example, extending DHCPv6-PD to request IPv6 address according to the device role. However, defining uniform device roles may not be a practical task. Some functions are not suitable to be achieved by any existing protocols, such as dynamically negotiating the sharing of public IPv4 addresses. However, using a generic autonomic discovery and negotiation protocol instead of specific solutions has the advantage that additional parameters can be included in the autonomic solution without creating new mechanisms. This is the principal argument for a generic approach. Jiang, et al. Expires October 30, 2014 [Page 6] Internet-Draft Auto Addr Management Use case April 2014 7. Security Considerations Relevant security issues are discussed in [I-D.irtf-nmrg-autonomic-network-definitions], [I-D.jiang-config-negotiation-ps]. The security mechanism in this document is established on a Public Key Infrastructure (PKI) system [RFC3647] that is maintained by the network administrator(s). 8. IANA Considerations This document requests no action by IANA. 9. Acknowledgements Valuable comments were received from Michael Behringer and Chongfeng Xie. This document was produced using the xml2rfc tool [RFC2629]. 10. Change log [RFC Editor: Please remove] draft-jiang-auto-addr-management-00: original version, 2014-04-28. 11. References [I-D.irtf-nmrg-an-gap-analysis] Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis for Autonomic Networking", draft-irtf-nmrg-an-gap- analysis-00 (work in progress), April 2014. [I-D.irtf-nmrg-autonomic-network-definitions] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking - Definitions and Design Goals", draft-irtf- nmrg-autonomic-network-definitions-00 (work in progress), December 2013. [I-D.jiang-config-negotiation-protocol] Jiang, S., Carpenter, B., Liu, B., and Y. Yin, "Configuration Negotiation Protocol for Network Devices", draft-jiang-config-negotiation-protocol-01 (work in progress), April 2014. [I-D.jiang-config-negotiation-ps] Jiang, S., Yin, Y., and B. Carpenter, "Network Configuration Negotiation Problem Statement and Requirements", draft-jiang-config-negotiation-ps-02 (work in progress), January 2014. Jiang, et al. Expires October 30, 2014 [Page 7] Internet-Draft Auto Addr Management Use case April 2014 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. Authors' Addresses Sheng Jiang (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: jiangsheng@huawei.com Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand Email: brian.e.carpenter@gmail.com Qiong China Telecom No.118, Xizhimennei Street Beijing 100035 P. R. China Email: sunqiong@ctbri.com.cn Jiang, et al. Expires October 30, 2014 [Page 8]