idnits 2.17.1 draft-jiang-auto-addr-management-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 28, 2014) is 3650 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-00 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-00 == Outdated reference: A later version (-02) exists of draft-jiang-config-negotiation-protocol-01 == Outdated reference: A later version (-03) exists of draft-jiang-config-negotiation-ps-02 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AN Use Case BOF S. Jiang, Ed. 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Informational B. Carpenter 5 Expires: October 30, 2014 Univ. of Auckland 6 Q. Sun 7 China Telecom 8 April 28, 2014 10 Autonomic Networking Use Case for Auto Address Management 11 draft-jiang-auto-addr-management-00 13 Abstract 15 This document describes a use case for autonomic address management 16 in large-scale networks. It is one of a series of use cases intended 17 to illustrate requirements for autonomic networking. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 30, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Intended User and Administrator Experience . . . . . . . . . 3 56 4. Analysis of Parameters and Information Involved . . . . . . . 3 57 4.1. Parameters each device can decide for itself . . . . . . 4 58 4.2. Information needed from policy intent . . . . . . . . . . 5 59 5. Interaction with other devices . . . . . . . . . . . . . . . 5 60 5.1. Information needed from other devices . . . . . . . . . . 5 61 5.2. Monitoring, diagnostics and reporting . . . . . . . . . . 6 62 6. Comparison with current solutions . . . . . . . . . . . . . . 6 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document is one of a set of use cases being developed to clarify 73 the requirements for discovery and negotiation protocols for 74 autonomic networking (AN). The background to AN is described in 75 [I-D.irtf-nmrg-autonomic-network-definitions] and 76 [I-D.irtf-nmrg-an-gap-analysis]. A problem statement and outline 77 requirements for the negotiation protocol are given in 78 [I-D.jiang-config-negotiation-ps]. 80 This document is dedicated to how to make IP address management in 81 large-scale networks as autonomic as possible, including operator 82 (ISP) networks and large enterprise networks. Although this document 83 is targeting pure IPv6 networks, autonomically sharing public IPv4 84 addresses among the Address Family Transition Routers (AFTRs) 85 [RFC6333] or NAT64 [RFC6146] devices is also discussed. 87 Note in draft: This version is preliminary. In particular, opinions 88 may vary about how concrete vs how abstract a use case should be. 90 2. Problem Statement 92 The autonomic networking use case considered here is autonomic IP 93 address management in large-scale networks. 95 Although DHCPv6 Prefix Delegation [RFC3633] has supported automated 96 delegation of IPv6 prefixes, the prefix management is still largely 97 depending on human planning. In other words, there is no basic 98 information or policies to support autonomic decisions on the prefix 99 length that each router should request or be delegated, according to 100 its role in the network. Roles could be locally defined or could be 101 generic (edge router, interior router, etc.). Furthermore, the 102 current IPv6 prefix management by humans is rigid and static after 103 initial planning. 105 Additionally, the management of public IPv4 addresses on AFTRs or 106 NAT64 devices is similarly rigid and static. The utilisation rate of 107 addresses depends on the initial plan. Efficient utilisation of 108 public IPv4 addresses is the most important requirement since they 109 are a limited resource during the IPv4 exhaustion period. 111 The problem to be solved by AN is how to dynamically and 112 autonomically manage IPv6 address space and public IPv4 addresses on 113 AFTRs or NAT64 devices in large-scale networks, so that IP addresses 114 can be used efficiently. The AN approach discussed in this document 115 is based on the assumption that there was a generic dicovery and 116 negotiation protocol that enables direct negotiation between 117 intelligent IP routers. [I-D.jiang-config-negotiation-protocol] is 118 one of the attempts at such a protocol. 120 3. Intended User and Administrator Experience 122 The intended experience is, for the administrator(s) of a large-scale 123 network, that the management of IPv6 address space can be run with 124 minimum efforts, for both the network and network device initiation 125 stage and during running time. In the most ideal scenario, the 126 administrator(s) only have to configure a single IPv6 prefix for the 127 whole network and the initial prefix length for each device role. 129 Where applicable, another intended experience is dynamically and 130 autonomically sharing public IPv4 addresses on AFTRs or NAT64 devices 131 without human intervention. The administrator only has to configure 132 the total available IPv4 address range. 134 The actual address usage needs to be logged for the potential offline 135 management operations including audit and security incident tracing. 137 4. Analysis of Parameters and Information Involved 139 For specific purposes of address management, a few parameters are 140 involved on each device (some of them can be pre-configured before 141 they are connected). They include: 143 o Identity of this device. It can be verified by the certification 144 authority (CA) that is maintained by the network administrator(s). 146 o Identity of a trust anchor which is certification authority (CA) 147 that is maintained by the network administrator(s). 149 o Role of this device. 151 o An IPv6 prefix length for this device. 153 o An IPv6 prefix that is assigned to this device and its downstream 154 devices. 156 o A public IPv4 address pool if the device acts as an AFTR or NAT64 157 device. 159 A few parameters are involved in the network as a whole. They are: 161 o Identity of a trust anchor which is a certification authority (CA) 162 that is maintained by the network administrator(s). 164 o Total IPv6 address space. It is one (or several) IPv6 prefix(es). 166 o A public IPv4 address pool if the network provides IPv4 over IPv6 167 access or IPv4/IPv6 transition services. 169 o The initial prefix length for each device role. 171 4.1. Parameters each device can decide for itself 173 This section identifies those of the above parameters that do not 174 need external information in order for the devices concerned to set 175 them to a reasonable value after bootstrap or after a network 176 disruption. There are few of these: 178 o Role of this device, this includes whether this device acts as an 179 AFTR or NAT64 device. 181 o Default IPv6 prefix length for this device. 183 o Identity of this device. 185 The device may be shipped from the manufacture with pre-configured 186 role and default prefix length. 188 4.2. Information needed from policy intent 190 This section identifies those parameters that need external 191 information about policy intent in order for the devices concerned to 192 set them to a non-default value. 194 o Non-default value for the IPv6 prefix length for this device. 195 This needs to be decided based on the role of this device. 197 o The initial prefix length for each device role. 199 o Identity of a trust anchor. 201 o Whether to allow the device request more address space. 203 o Whether to allow the device to request or share public IPv4 204 address. 206 o The policy when to request more address space, for example, the 207 address usage reaches a certain limit or percentage. 209 5. Interaction with other devices 211 5.1. Information needed from other devices 213 This section identifies those of the above parameters that need 214 external information from neighbor devices (including the upstream 215 devices). In many cases, two-way dialogue with neighbor devices is 216 needed to set or optimise them. 218 o Identity of a trust anchor. 220 o The device will need to discover their neighbors, particularly, 221 the upstream device, from which it can acquire IPv6 address space. 223 o The initial prefix length for each device role, particularly for 224 its own downstream devices. 226 o The default value of the IPv6 prefix length may be overridden by a 227 non-default value. 229 o The device will need to request and acquire IPv6 prefix that is 230 assigned to this device and its downstream devices. 232 o The device may respond to prefix delegation request from its 233 downstream devices. 235 o The device may require to be assigned more IPv6 address space, if 236 it used up its assigned IPv6 address space. 238 o An AFTR or NAT64 device will need to request and acquire an 239 initial public IPv4 address pool. 241 o An AFTR or NAT64 device will need to discover its neighbors, from 242 which it may acquire spare public IPv4 addresses. 244 o An AFTR or NAT64 device may acquire spare public IPv4 addresses 245 with their associated available period. 247 5.2. Monitoring, diagnostics and reporting 249 This section discusses what role devices should play in monitoring, 250 fault diagnosis, and reporting. 252 o The actual address assignments need to be logged for the potential 253 offline management operations. 255 o In general, the usage situation of address space should be 256 reported to the network administrators, in an abstract way, for 257 example, statistics or visualized report. 259 o A forecast of address exhaustion should be reported. 261 6. Comparison with current solutions 263 This section briefly compares the above use case with current 264 solutions. Currently, the address management is still largely 265 depending on human planning. It is rigid and static after initial 266 planning. The address requests will fail if the configured address 267 space is used up. 269 Some functions, for autonomic and dynamic address management, may be 270 achievable by extending the existing protocols, for example, 271 extending DHCPv6-PD to request IPv6 address according to the device 272 role. However, defining uniform device roles may not be a practical 273 task. Some functions are not suitable to be achieved by any existing 274 protocols, such as dynamically negotiating the sharing of public IPv4 275 addresses. 277 However, using a generic autonomic discovery and negotiation protocol 278 instead of specific solutions has the advantage that additional 279 parameters can be included in the autonomic solution without creating 280 new mechanisms. This is the principal argument for a generic 281 approach. 283 7. Security Considerations 285 Relevant security issues are discussed in 286 [I-D.irtf-nmrg-autonomic-network-definitions], 287 [I-D.jiang-config-negotiation-ps]. The security mechanism in this 288 document is established on a Public Key Infrastructure (PKI) system 289 [RFC3647] that is maintained by the network administrator(s). 291 8. IANA Considerations 293 This document requests no action by IANA. 295 9. Acknowledgements 297 Valuable comments were received from Michael Behringer and Chongfeng 298 Xie. 300 This document was produced using the xml2rfc tool [RFC2629]. 302 10. Change log [RFC Editor: Please remove] 304 draft-jiang-auto-addr-management-00: original version, 2014-04-28. 306 11. References 308 [I-D.irtf-nmrg-an-gap-analysis] 309 Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis 310 for Autonomic Networking", draft-irtf-nmrg-an-gap- 311 analysis-00 (work in progress), April 2014. 313 [I-D.irtf-nmrg-autonomic-network-definitions] 314 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 315 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 316 Networking - Definitions and Design Goals", draft-irtf- 317 nmrg-autonomic-network-definitions-00 (work in progress), 318 December 2013. 320 [I-D.jiang-config-negotiation-protocol] 321 Jiang, S., Carpenter, B., Liu, B., and Y. Yin, 322 "Configuration Negotiation Protocol for Network Devices", 323 draft-jiang-config-negotiation-protocol-01 (work in 324 progress), April 2014. 326 [I-D.jiang-config-negotiation-ps] 327 Jiang, S., Yin, Y., and B. Carpenter, "Network 328 Configuration Negotiation Problem Statement and 329 Requirements", draft-jiang-config-negotiation-ps-02 (work 330 in progress), January 2014. 332 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 333 June 1999. 335 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 336 Host Configuration Protocol (DHCP) version 6", RFC 3633, 337 December 2003. 339 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 340 Wu, "Internet X.509 Public Key Infrastructure Certificate 341 Policy and Certification Practices Framework", RFC 3647, 342 November 2003. 344 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 345 NAT64: Network Address and Protocol Translation from IPv6 346 Clients to IPv4 Servers", RFC 6146, April 2011. 348 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 349 Stack Lite Broadband Deployments Following IPv4 350 Exhaustion", RFC 6333, August 2011. 352 Authors' Addresses 354 Sheng Jiang (editor) 355 Huawei Technologies Co., Ltd 356 Q14, Huawei Campus, No.156 Beiqing Road 357 Hai-Dian District, Beijing, 100095 358 P.R. China 360 Email: jiangsheng@huawei.com 362 Brian Carpenter 363 Department of Computer Science 364 University of Auckland 365 PB 92019 366 Auckland 1142 367 New Zealand 369 Email: brian.e.carpenter@gmail.com 371 Qiong 372 China Telecom 373 No.118, Xizhimennei Street 374 Beijing 100035 375 P. R. China 377 Email: sunqiong@ctbri.com.cn