idnits 2.17.1 draft-jiang-anima-prefix-management-02.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 438: '... It is RECOMMENDED that DHCPv6 PD, i...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2015) is 3113 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-01 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-01 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG S. Jiang, Ed. 3 Internet-Draft Z. Du 4 Intended status: Informational Huawei Technologies Co., Ltd 5 Expires: April 20, 2016 B. Carpenter 6 Univ. of Auckland 7 Q. Sun 8 China Telecom 9 October 18, 2015 11 Autonomic Prefix Management in Large-scale Networks 12 draft-jiang-anima-prefix-management-02 14 Abstract 16 This document describes an autonomic solution for prefix management 17 in large-scale networks. 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 April 20, 2016. 36 Copyright Notice 38 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Intended User and Administrator Experience . . . . . . . 3 56 2.2. Analysis of Parameters and Information Involved . . . . . 3 57 2.2.1. Parameters each device can decide for itself . . . . 4 58 2.2.2. Information needed from policy intent . . . . . . . . 4 59 2.2.3. Comparison with current solutions . . . . . . . . . . 5 60 2.3. Interaction with other devices . . . . . . . . . . . . . 5 61 2.3.1. Information needed from other devices . . . . . . . . 5 62 2.3.2. Monitoring, diagnostics and reporting . . . . . . . . 6 63 3. Autonomic Prefix Management Solution . . . . . . . . . . . . 6 64 3.1. Behaviors to discover prefix providing device . . . . . . 6 65 3.2. Behaviors on prefix providing device . . . . . . . . . . 6 66 3.3. Prefix Requests Behaviors . . . . . . . . . . . . . . . . 7 67 3.4. Prefix log . . . . . . . . . . . . . . . . . . . . . . . 8 68 4. Autonomic Prefix Management Options . . . . . . . . . . . . . 8 69 4.1. Prefix Objective option . . . . . . . . . . . . . . . . . 8 70 5. Prefix Management Intent . . . . . . . . . . . . . . . . . . 8 71 5.1. Example of Prefix Management Intent . . . . . . . . . . . 9 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 75 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 10 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 This document proposes an autonomic solution for prefix management in 82 large-scale networks. The background to Autonomic Network (AN) is 83 described in [RFC7575] and [RFC7576]. A generic autonomic signaling 84 protocol (GRASP) is proposed by [I-D.ietf-anima-grasp], which would 85 be used by the proposed autonomic prefix management solution. 87 This document is dedicated to how to make IPv6 prefix management in 88 pure IPv6 large-scale networks as autonomic as possible. This 89 document for now is only considering service provider (ISP) networks. 90 Although there are similarities with large enterprise networks, the 91 requirements are a little different for the two use cases. 93 Note in draft: This version is preliminary. In particular, many 94 design details may be subject to change until the anima 95 specifications become agreed. 97 2. Problem Statement 99 The autonomic networking use case considered here is autonomic IP 100 address management in large-scale networks. 102 Although DHCPv6 Prefix Delegation [RFC3633] has supported automated 103 delegation of IPv6 prefixes, prefix management is still largely 104 depending on human planning. In other words, there is no basic 105 information or policy to support autonomic decisions on the prefix 106 length that each router should request or be delegated, according to 107 its role in the network. Roles could be locally defined or could be 108 generic (edge router, interior router, etc.). Furthermore, the 109 current IPv6 prefix management by humans is rigid and static after 110 initial planning. 112 The problem to be solved by AN is how to dynamically and 113 autonomically manage IPv6 address space in large-scale networks, so 114 that IPv6 addresses can be used efficiently. The AN approach 115 discussed in this document is based on the assumption that there is a 116 generic discovery and negotiation protocol that enables direct 117 negotiation between intelligent IP routers. [I-D.ietf-anima-grasp] 118 is one of the attempts at such a protocol. 120 2.1. 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 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 The actual address usage needs to be logged for potential offline 130 management operations including audit and security incident tracing. 132 2.2. Analysis of Parameters and Information Involved 134 For specific purposes of address management, a few parameters are 135 involved on each device (some of them can be pre-configured before 136 they are connected). They include: 138 o Identity of this device. It can be verified by the certification 139 authority (CA) that is maintained by the network administrator(s). 141 o Identity of a trust anchor which is certification authority (CA) 142 that is maintained by the network administrator(s). 144 o Role of this device. 146 o An IPv6 prefix length for this device. 148 o An IPv6 prefix that is assigned to this device and its downstream 149 devices. 151 A few parameters are involved in the network as a whole. They are: 153 o Identity of a trust anchor which is a certification authority (CA) 154 that is maintained by the network administrator(s). 156 o Total IPv6 address space. It is one (or several) IPv6 prefix(es). 158 o The initial prefix length for each device role. 160 2.2.1. Parameters each device can decide for itself 162 This section identifies those of the above parameters that do not 163 need external information in order for the devices concerned to set 164 them to a reasonable value after bootstrap or after a network 165 disruption. There are few of these: 167 o Role of this device. 169 o Default IPv6 prefix length for this device. 171 o Identity of this device. 173 The device may be shipped from the manufacture with pre-configured 174 role and default prefix length. 176 2.2.2. Information needed from policy intent 178 This section identifies those parameters that need external 179 information about policy intent in order for the devices concerned to 180 set them to a non-default value. 182 o Non-default value for the IPv6 prefix length for this device. 183 This needs to be decided based on the role of this device. 185 o The initial prefix length for each device role. 187 o Identity of a trust anchor. 189 o Whether to allow the device request more address space. 191 o The policy when to request more address space, for example, the 192 address usage reaches a certain limit or percentage. 194 2.2.3. Comparison with current solutions 196 This section briefly compares the above use case with current 197 solutions. Currently, the address management is still largely 198 depending on human planning. It is rigid and static after initial 199 planning. The address requests will fail if the configured address 200 space is used up. 202 Some functions, for autonomic and dynamic address management, may be 203 achievable by extending the existing protocols, for example, 204 extending DHCPv6-PD to request IPv6 address according to the device 205 role. However, defining uniform device roles may not be a practical 206 task. Some functions are not suitable to be achieved by any existing 207 protocols. 209 However, using a generic autonomic discovery and negotiation protocol 210 instead of specific solutions has the advantage that additional 211 parameters can be included in the autonomic solution without creating 212 new mechanisms. This is the principal argument for a generic 213 approach. 215 2.3. Interaction with other devices 217 2.3.1. Information needed from other devices 219 This section identifies those of the above parameters that need 220 external information from neighbor devices (including the upstream 221 devices). In many cases, two-way dialogue with neighbor devices is 222 needed to set or optimize them. 224 o Identity of a trust anchor. 226 o The device will need to discover a device, from which it can 227 acquire IPv6 address space. 229 o The initial prefix length for each device role, particularly for 230 its own downstream devices. 232 o The default value of the IPv6 prefix length may be overridden by a 233 non-default value. 235 o The device will need to request and acquire IPv6 prefix that is 236 assigned to this device and its downstream devices. 238 o The device may respond to prefix delegation request from its 239 downstream devices. 241 o The device may require to be assigned more IPv6 address space, if 242 it used up its assigned IPv6 address space. 244 2.3.2. Monitoring, diagnostics and reporting 246 This section discusses what role devices should play in monitoring, 247 fault diagnosis, and reporting. 249 o The actual address assignments need to be logged for the potential 250 offline management operations. 252 o In general, the usage situation of address space should be 253 reported to the network administrators, in an abstract way, for 254 example, statistics or visualized report. 256 o A forecast of address exhaustion should be reported. 258 3. Autonomic Prefix Management Solution 260 This section introduces an autonomic prefix management solution. It 261 extends the generic discovery and negotiation protocol defined by 262 [I-D.ietf-anima-grasp]. The relevant options are defined in 263 Section 4. 265 3.1. Behaviors to discover prefix providing device 267 A device should decide the length of request prefix by the intent- 268 based mechanism, described in Section 5. If it used up its current 269 address resource, it could request more, which is not necessary to be 270 on the same scale as its initial resource. 272 A prefix requesting device that needs new or more address space 273 should firstly discover peer devices that may be able to provide 274 extra address space. The device should send out a GRASP Discovery 275 message that contains a Prefix Objective option Section 4.1, in which 276 the device also indicates whether it supports the DHCPv6 Prefix 277 Delegation (PD) [RFC3633] function and the length of requested 278 prefix. 280 3.2. Behaviors on prefix providing device 282 A peer device receiving a Discovery message with a Prefix Objective 283 option, if it is able to provide such a prefix, should respond with a 284 GRASP Response message. The Response message also carries a Prefix 285 Objective option, which also indicate whether the peer device 286 supports the PD function and the available prefix length matching the 287 request. If the peer device does not have enough resource, it may 288 silently drop the Discovery message or return a GRASP Response 289 message, which contains a longer prefix length (smaller address 290 space) that it can provide. A divert option may also be added into 291 the GRASP Response message. This divert option indicates another 292 device that may provide the prefix. The diverted device is typically 293 an upstream gateway router, but it could in theory be any device that 294 might have unused prefix space. 296 A gateway router in a hierarchical network topology is normally 297 responsible to provide prefixes for routers within its subnet. In 298 the case that it does not have enough resource for the downstream 299 requesting router, it should return a GRASP Response message, which 300 contains a longer prefix length (smaller address space) that this 301 gateway router may provide. In this case too, a divert option may be 302 added into the GRASP Response message. The diverted device is 303 typically another upstream gateway router. 305 A resource shortage may cause the gateway router to request more 306 resource from its upstream device. This would be another independent 307 GND discovery and negotiation process. During the processing time, 308 the gateway router should send a Confirm-waiting Message to the 309 initial requesting router. When the new resource becomes available, 310 the gateway router responds with a GRASP Response message with the 311 prefix length matching the request. 313 The algorithm to choose which prefixes to assign on the prefix 314 providing devices is an implementation choice out of document scope. 316 3.3. Prefix Requests Behaviors 318 Upon receiving the GRASP Response message that indicates the 319 requesting prefix length is accepted, the requesting device may 320 request the prefix using DHCPv6 PD, if both itself and the response 321 device support PD. 323 Upon receiving the GRASP Response message that indicates the 324 requesting prefix length is not possible, but a longer prefix length 325 is available, the requesting device may request the longer prefix 326 using DHCPv6 PD, if both itself and the response device support PD. 328 If the GRASP Response message carries a divert option, the requesting 329 device may sent an unicast GRASP Discovery message to the diverted 330 device to find out whether that device can provide the requested 331 length prefix. 333 [Author's note: undecided whether we should support prefix delegation 334 using the GRASP protocol. This would have some partial overlap with 335 DHCPv6 PD. But it seems more consistent as a solution.] 337 3.4. Prefix log 339 Within the autonomic prefix management, all the prefix assignment is 340 done by devices without human intervention. It is even more 341 important to record all the prefix assignment history. However, the 342 logging and reporting process is out of document scope. 344 4. Autonomic Prefix Management Options 346 This section defines the GRASP options that are used to support 347 autonomic prefix management. 349 4.1. Prefix Objective option 351 The Prefix Objective option carries the PD support flag and the 352 prefix length. The format of the Prefix Objective option is 353 described as follows: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Prefix_Obj_Option | option-len | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 |PD_Support_Flag| Prefix_Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 option-code Prefix_Obj_Option (TBA1). 365 option-len 2, length of option content in octets. 367 PD_Support_Flag Indicates whether the message sender supports 368 DHCPv6 Prefix Delegation function, 1 for support, 369 0 for no support, as client or server accordingly. 370 This flag must not be set to any other values. 372 Prefix_Length Indicate the prefix length that the message sender 373 requests or is willing to provide. 375 5. Prefix Management Intent 377 With in a single administrative domain, the network operator could 378 manage all their devices with role set. If so, there is possibility 379 to configure/manage the prefix length for every device in a simple 380 way. 382 The network operator could only manage the default prefix length for 383 each type of role. A prefix management intent, which contains all 384 mapping information of device roles and their default prefix lengths, 385 should be flooded in the network, through the Autonomic Control Plane 386 (ACP) [I-D.ietf-anima-autonomic-control-plane]. The intent flooding 387 mechanism is out of document scope. 389 Upon receiving the prefix management intent, every device can decide 390 its default prefix length by matching its own role. 392 5.1. Example of Prefix Management Intent 394 The prefix management intent in this document is used to carry 395 mapping information of device roles and their default prefix lengths 396 in an autonomic domain. For example, an IPRAN operator wants to 397 configure the prefix length of RNC Site Gateway (RSG) as 34, the 398 prefix length of Aggregation Site Gateway (ASG) as 44, and the prefix 399 length of Cell Site Gateway (CSG) as 56. She/he may input the 400 following intent into the autonomic network: 402 {"autonomic_intent": 403 [ 404 {"model_version": "1.0"}, 405 {"intent_type": "Network management"}, 406 {"autonomic_domain": "Customer_X_intranet"}, 407 {"intent_name": "Prefix management"}, 408 {"intent_version": 73}, 409 {"Timestamp": "20150606 00:00:00"}, 410 {"Lifetime": "Permanent"}, 411 {"signature": "XXXXXXXXXXXXXXXXXXX"}, 412 {"content": 413 [ 414 {"role": [{"role_name": "RSG"}, 415 {"role_characteristic": 416 [{"prefix_length": "34"}]} 417 ]}, 418 {"role": [{"role_name": "ASG"}, 419 {"role_characteristic": 420 [{"prefix_length": "44"}]} 421 ]}, 422 {"role": [{"role_name": "CSG"}, 423 {"role_characteristic": 424 [{"prefix_length": "56"}]} 425 ]} 426 ] 427 } 428 ] 429 } 431 6. Security Considerations 433 Relevant security issues are discussed in [I-D.ietf-anima-grasp]. 434 The security mechanism in this document is established on a Public 435 Key Infrastructure (PKI) system [RFC3647] that is maintained by the 436 network administrator(s). 438 It is RECOMMENDED that DHCPv6 PD, if used, should be operated using 439 DHCPv6 authentication or Secure DHCPv6. 441 7. IANA Considerations 443 This document defines one new GRASP option. The IANA is requested to 444 assign a value for this option from the GRASP Option Codes table of 445 the GRASP Parameters registry as defined by [I-D.ietf-anima-grasp] 446 (if approved). 448 o The Prefix Objective option (TBA1), described in Section 4.1. 450 8. Acknowledgements 452 Valuable comments were received from Michael Behringer and Chongfeng 453 Xie. 455 This document was produced using the xml2rfc tool [RFC2629]. 457 9. Change log [RFC Editor: Please remove] 459 draft-jiang-anima-prefix-management-00: original version, 2014-10-25. 461 draft-jiang-anima-prefix-management-01: add intent example and 462 coauthor Zongpeng Du, 2015-05-04. 464 draft-jiang-anima-prefix-management-02: update references and the 465 format of the prefix management intent, 2015-10-14. 467 10. References 469 [I-D.ietf-anima-autonomic-control-plane] 470 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 471 Autonomic Control Plane", draft-ietf-anima-autonomic- 472 control-plane-01 (work in progress), October 2015. 474 [I-D.ietf-anima-grasp] 475 Bormann, C., Carpenter, B., and B. Liu, "A Generic 476 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 477 grasp-01 (work in progress), October 2015. 479 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 480 DOI 10.17487/RFC2629, June 1999, 481 . 483 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 484 Host Configuration Protocol (DHCP) version 6", RFC 3633, 485 DOI 10.17487/RFC3633, December 2003, 486 . 488 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 489 Wu, "Internet X.509 Public Key Infrastructure Certificate 490 Policy and Certification Practices Framework", RFC 3647, 491 DOI 10.17487/RFC3647, November 2003, 492 . 494 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 495 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 496 Networking: Definitions and Design Goals", RFC 7575, 497 DOI 10.17487/RFC7575, June 2015, 498 . 500 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 501 Analysis for Autonomic Networking", RFC 7576, 502 DOI 10.17487/RFC7576, June 2015, 503 . 505 Authors' Addresses 507 Sheng Jiang (editor) 508 Huawei Technologies Co., Ltd 509 Q14, Huawei Campus, No.156 Beiqing Road 510 Hai-Dian District, Beijing, 100095 511 P.R. China 513 Email: jiangsheng@huawei.com 515 Zongpeng Du 516 Huawei Technologies Co., Ltd 517 Q14, Huawei Campus, No.156 Beiqing Road 518 Hai-Dian District, Beijing, 100095 519 P.R. China 521 Email: duzongpeng@huawei.com 522 Brian Carpenter 523 Department of Computer Science 524 University of Auckland 525 PB 92019 526 Auckland 1142 527 New Zealand 529 Email: brian.e.carpenter@gmail.com 531 Qiong Sun 532 China Telecom 533 No.118, Xizhimennei Street 534 Beijing 100035 535 P. R. China 537 Email: sunqiong@ctbri.com.cn