idnits 2.17.1 draft-ietf-anima-prefix-management-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 15, 2017) is 2323 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-12 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-09 == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-00 ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-05 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-05 == Outdated reference: A later version (-07) exists of draft-liu-dhc-dhcp-yang-model-06 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: June 18, 2018 B. Carpenter 6 Univ. of Auckland 7 Q. Sun 8 China Telecom 9 December 15, 2017 11 Autonomic IPv6 Edge Prefix Management in Large-scale Networks 12 draft-ietf-anima-prefix-management-07 14 Abstract 16 This document defines two autonomic technical objectives for IPv6 17 prefix management at the edge of large-scale ISP networks, with an 18 extension to support IPv4 prefixes. An important purpose of the 19 document is to use it for validation of the design of various 20 components of the autonomic networking infrastructure. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 18, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Intended User and Administrator Experience . . . . . . . 4 60 3.2. Analysis of Parameters and Information Involved . . . . . 5 61 3.2.1. Parameters each device can define for itself . . . . 5 62 3.2.2. Information needed from network operations . . . . . 6 63 3.2.3. Comparison with current solutions . . . . . . . . . . 6 64 3.3. Interaction with other devices . . . . . . . . . . . . . 7 65 3.3.1. Information needed from other devices . . . . . . . . 7 66 3.3.2. Monitoring, diagnostics and reporting . . . . . . . . 7 67 4. Autonomic Edge Prefix Management Solution . . . . . . . . . . 8 68 4.1. Behaviors on prefix requesting device . . . . . . . . . . 8 69 4.2. Behaviors on prefix providing device . . . . . . . . . . 9 70 4.3. Behavior after Successful Negotiation . . . . . . . . . . 10 71 4.4. Prefix logging . . . . . . . . . . . . . . . . . . . . . 10 72 5. Autonomic Prefix Management Objectives . . . . . . . . . . . 10 73 5.1. Edge Prefix Objective Option . . . . . . . . . . . . . . 10 74 5.2. IPv4 extension . . . . . . . . . . . . . . . . . . . . . 11 75 6. Prefix Management Parameters . . . . . . . . . . . . . . . . 11 76 6.1. Example of Prefix Management Parameters . . . . . . . . . 12 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 80 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 14 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 11.2. Informative References . . . . . . . . . . . . . . . . . 16 84 Appendix A. Deployment Overview . . . . . . . . . . . . . . . . 17 85 A.1. Address & Prefix management with DHCP . . . . . . . . . . 17 86 A.2. Prefix management with ANI/GRASP . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 89 1. Introduction 91 The original purpose of this document was to validate the design of 92 the Autonomic Networking Infrastructure (ANI) for a realistic use 93 case. It shows how the ANI can be applied to IP prefix delegation 94 and it outlines approaches to build a system to do this. A fully 95 standardized solution would require more details, so this document is 96 informational in nature. 98 This document defines two autonomic technical objectives for IPv6 99 prefix management in large-scale networks, with an extension to 100 support IPv4 prefixes. The background to Autonomic Networking (AN) 101 is described in [RFC7575] and [RFC7576]. The GeneRic Autonomic 102 Signaling Protocol (GRASP) is specified by [I-D.ietf-anima-grasp] and 103 can make use of the proposed technical objectives to provide a 104 solution for autonomic prefix management. An important purpose of 105 the present document is to use it for validation of the design of 106 GRASP and other components of the autonomic networking infrastructure 107 described in [I-D.ietf-anima-reference-model]. 109 This document is not a complete functional specification of an 110 autonomic prefix management system and it does not describe all 111 detailed aspects of the GRASP objective parameters and Autonomic 112 Service Agent (ASA) procedures necessary to build a complete system. 113 Instead, it describes the architectural framework utilizing the 114 components of the ANI, outlines the different deployment options and 115 aspects, and defines GRASP objectives for use in building the system. 116 It also provides some basic parameter examples. 118 This document is not intended to solve all cases of IPv6 prefix 119 management. In fact, it assumes that the network's main 120 infrastructure elements already have addresses and prefixes. The 121 document is dedicated to how to make IPv6 prefix management at the 122 edges of large-scale networks as autonomic as possible. It is 123 specifically written for service provider (ISP) networks. Although 124 there are similarities between ISPs and large enterprise networks, 125 the requirements for the two use cases differ. In any case, the 126 scope of the solution is expected to be limited, like any autonomic 127 network, to a single management domain. 129 However, the solution is designed in a general way. Its use for a 130 broader scope than edge prefixes, including some or all 131 infrastructure prefixes, is left for future discussion. 133 A complete solution has many aspects that are not discussed here. 134 Once prefixes have been assigned to routers, they need to be 135 communicated to the routing system as they are brought into use. 136 Similarly, when prefixes are released, they need to be removed from 137 the routing system. Different operators may have different policies 138 about prefix lifetimes, and they may prefer to have centralized or 139 distributed pools of spare prefixes. In an autonomic network, these 140 are properties decided by the design of the relevant ASAs. The GRASP 141 objectives are simply building blocks. 143 A particular risk of distributed prefix allocation in large networks 144 is that over time, it might lead to fragmentation of the address 145 space and an undesirable increase in the interior routing protocol 146 tables. The extent of this risk depends on the algorithms and 147 policies used by the ASAs. Mitigating this risk might even become an 148 autonomic function in itself. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 This document uses terminology defined in [RFC7575]. 160 3. Problem Statement 162 The autonomic networking use case considered here is autonomic IPv6 163 prefix management at the edge of large-scale ISP networks. 165 Although DHCPv6 Prefix Delegation [RFC3633] supports automated 166 delegation of IPv6 prefixes from one router to another, prefix 167 management still largely depends on human planning. In other words, 168 there is no basic information or policy to support autonomic 169 decisions on the prefix length that each router should request or be 170 delegated, according to its role in the network. Roles could be 171 defined separately for individual devices or could be generic (edge 172 router, interior router, etc.). Furthermore, IPv6 prefix management 173 by humans tends to be rigid and static after initial planning. 175 The problem to be solved by autonomic networking is how to 176 dynamically manage IPv6 address space in large-scale networks, so 177 that IPv6 addresses can be used efficiently. Here, we limit the 178 problem to assignment of prefixes at the edge of the network, close 179 to access routers that support individual fixed-line subscribers, 180 mobile customers, and corporate customers. We assume that the core 181 infrastructure of the network has already been established with 182 appropriately assigned prefixes. The AN approach discussed in this 183 document is based on the assumption that there is a generic discovery 184 and negotiation protocol that enables direct negotiation between 185 intelligent IP routers. GRASP [I-D.ietf-anima-grasp] is intended to 186 be such a protocol. 188 3.1. Intended User and Administrator Experience 190 The intended experience is, for the administrators of a large-scale 191 network, that the management of IPv6 address space at the edge of the 192 network can be run with minimum effort, as devices at the edge are 193 added and removed and as customers of all kinds join and leave the 194 network. In the ideal scenario, the administrators only have to 195 specify a single IPv6 prefix for the whole network and the initial 196 prefix length for each device role. As far as users are concerned, 197 IPv6 prefix assignment would occur exactly as it does in any other 198 network. 200 The actual prefix usage needs to be logged for potential offline 201 management operations including audit and security incident tracing. 203 3.2. Analysis of Parameters and Information Involved 205 For specific purposes of address management, a few parameters are 206 involved on each edge device (some of them can be pre-configured 207 before they are connected). They include: 209 o Identity, authentication and authorization of this device. This 210 is expected to use the autonomic networking secure bootstrap 211 process [I-D.ietf-anima-bootstrapping-keyinfra], following which 212 the device could safely take part in autonomic operations. 214 o Role of this device. Some example roles are discussed in 215 Section 6.1. 217 o An IPv6 prefix length for this device. 219 o An IPv6 prefix that is assigned to this device and its downstream 220 devices. 222 A few parameters are involved in the network as a whole. They are: 224 o Identity of a trust anchor, which is a certification authority 225 (CA) maintained by the network administrators, used during the 226 secure bootstrap process. 228 o Total IPv6 address space available for edge devices. It is a pool 229 of one or several IPv6 prefixes. 231 o The initial prefix length for each device role. 233 3.2.1. Parameters each device can define for itself 235 This section identifies those of the above parameters that do not 236 need external information in order for the devices concerned to set 237 them to a reasonable default value after bootstrap or after a network 238 disruption. There are few of these: 240 o Default role of this device. 242 o Default IPv6 prefix length for this device. 244 o Cryptographic identity of this device, as needed for secure 245 bootstrapping [I-D.ietf-anima-bootstrapping-keyinfra]. 247 The device may be shipped from the manufacturer with pre-configured 248 role and default prefix length, which could be modified by an 249 autonomic mechanism. Its cryptographic identity will be installed by 250 its manufacturer. 252 3.2.2. Information needed from network operations 254 This section identifies those parameters that might need operational 255 input in order for the devices concerned to set them to a non-default 256 value. 258 o Non-default value for the IPv6 prefix length for this device. 259 This needs to be decided based on the role of this device. 261 o The initial prefix length for each device role. 263 o Whether to allow the device to request more address space. 265 o The policy when to request more address space, for example, if the 266 address usage reaches a certain limit or percentage. 268 3.2.3. Comparison with current solutions 270 This section briefly compares the above use case with current 271 solutions. Currently, the address management is still largely 272 dependent on human planning. It is rigid and static after initial 273 planning. Address requests will fail if the configured address space 274 is used up. 276 Some autonomic and dynamic address management functions may be 277 achievable by extending the existing protocols, for example, 278 extending DHCPv6-PD (DHCPv6 Prefix Delegation, [RFC3633]) to request 279 IPv6 prefixes according to the device role. However, defining 280 uniform device roles may not be a practical task. Some functions are 281 not suitable to be achieved by any existing protocols. 283 Using a generic autonomic discovery and negotiation protocol instead 284 of specific solutions has the advantage that additional parameters 285 can be included in the autonomic solution without creating new 286 mechanisms. This is the principal argument for a generic approach. 288 3.3. Interaction with other devices 290 3.3.1. Information needed from other devices 292 This section identifies those of the above parameters that need 293 external information from neighbor devices (including the upstream 294 devices). In many cases, two-way dialogue with neighbor devices is 295 needed to set or optimize them. 297 o Identity of a trust anchor. 299 o The device will need to discover a device, from which it can 300 acquire IPv6 address space. 302 o The initial prefix length for each device role, particularly for 303 its own downstream devices. 305 o The default value of the IPv6 prefix length may be overridden by a 306 non-default value. 308 o The device will need to request and acquire one or more IPv6 309 prefixes that can be assigned to this device and its downstream 310 devices. 312 o The device may respond to prefix delegation requests from its 313 downstream devices. 315 o The device may require to be assigned more IPv6 address space, if 316 it used up its assigned IPv6 address space. 318 3.3.2. Monitoring, diagnostics and reporting 320 This section discusses what role devices should play in monitoring, 321 fault diagnosis, and reporting. 323 o The actual address assignments need to be logged for potential 324 offline management operations. 326 o In general, the usage situation of address space should be 327 reported to the network administrators, in an abstract way, for 328 example, statistics or visualized report. 330 o A forecast of address exhaustion should be reported. 332 4. Autonomic Edge Prefix Management Solution 334 This section introduces the building blocks for an autonomic edge 335 prefix management solution. As noted in Section 1, this is not a 336 complete description of a solution, which will depend on the detailed 337 design of the relevant Autonomic Service Agents. It uses the generic 338 discovery and negotiation protocol defined by [I-D.ietf-anima-grasp]. 339 The relevant GRASP objectives are defined in Section 5. 341 The procedures described below are carried out by an Autonomic 342 Service Agent (ASA) in each device that participates in the solution. 343 We will refer to this as the PrefixManager ASA. 345 4.1. Behaviors on prefix requesting device 347 If the device containing a PrefixManager ASA has used up its address 348 pool, it can request more space according to its requirements. It 349 should decide the length of the requested prefix and request it by 350 the mechanism described in Section 6. Note that although the 351 device's role may define certain default allocation lengths, those 352 defaults might be changed dynamically, and the device might request 353 more, or less, address space due to some local operational heuristic. 355 A PrefixManager ASA that needs additional address space should 356 firstly discover peers that may be able to provide extra address 357 space. The ASA should send out a GRASP Discovery message that 358 contains a PrefixManager Objective option (see Section 5.1) in order 359 to discover peers also supporting that option. Then it should choose 360 one such peer, most likely the first to respond. 362 If the GRASP discovery Response message carries a divert option 363 pointing to an off-link PrefixManager ASA, the requesting ASA may 364 initiate negotiation with that ASA diverted device to find out 365 whether it can provide the requested length prefix. 367 In any case, the requesting ASA will act as a GRASP negotiation 368 initiator by sending a GRASP Request message with a PrefixManager 369 Objective option. The ASA indicates in this option the length of the 370 requested prefix. This starts a GRASP negotiation process. 372 During the subsequent negotiation, the ASA will decide at each step 373 whether to accept the offered prefix. That decision, and the 374 decision to end negotiation, is an implementation choice. 376 The ASA could alternatively initiate rapid mode GRASP discovery with 377 an embedded negotiation request, if it is implemented. 379 4.2. Behaviors on prefix providing device 381 At least one device on the network must be configured with the 382 initial pool of available prefixes mentioned in Section 3.2. Apart 383 from that requirement, any device may act as a prefix providing 384 device. 386 A device that receives a Discovery message with a PrefixManager 387 Objective option should respond with a GRASP Response message if it 388 contains a PrefixManager ASA. Further details of the discovery 389 process are described in [I-D.ietf-anima-grasp]. When this ASA 390 receives a subsequent Request message, it should conduct a GRASP 391 negotiation sequence, using Negotiate, Confirm-waiting, and 392 Negotiation-ending messages as appropriate. The Negotiate messages 393 carry a PrefixManager Objective option, which will indicate the 394 prefix and its length offered to the requesting ASA. As described in 395 [I-D.ietf-anima-grasp], negotiation will continue until either end 396 stops it with a Negotiation-ending message. If the negotiation 397 succeeds, the prefix providing ASA will remove the negotiated prefix 398 from its pool, and the requesting ASA will add it. If the 399 negotiation fails, the party sending the Negotiation-ending message 400 may include an error code string. 402 During the negotiation, the ASA will decide at each step how large a 403 prefix to offer. That decision, and the decision to end negotiation, 404 is an implementation choice. 406 The ASA could alternatively negotiate in response to rapid mode GRASP 407 discovery, if it is implemented. 409 This specification is independent of whether the PrefixManager ASAs 410 are all embedded in routers, but that would be a rather natural 411 scenario. In a hierarchical network topology, a given router 412 typically provide prefixes for routers below it in the hierarchy, and 413 it is also likely to contain the first PrefixManager ASA discovered 414 by those downstream routers. However, the GRASP discovery model, 415 including its Redirect feature, means that this is not an exclusive 416 scenario, and a downstream PrefixManager ASA could negotiate a new 417 prefix with a device other than its upstream router. 419 A resource shortage may cause the gateway router to request more 420 resource in turn from its own upstream device. This would be another 421 independent GRASP discovery and negotiation process. During the 422 processing time, the gateway router should send a Confirm-waiting 423 Message to the initial requesting router, to extend its timeout. 424 When the new resource becomes available, the gateway router responds 425 with a GRASP Negotiate message with a prefix length matching the 426 request. 428 The algorithm to choose which prefixes to assign on the prefix 429 providing devices is an implementation choice. 431 4.3. Behavior after Successful Negotiation 433 Upon receiving a GRASP Negotiation-ending message that indicates that 434 an acceptable prefix length is available, the requesting device may 435 use the negotiated prefix without further messages. 437 There are use cases where the ANI/GRASP based prefix management 438 approach can work together with DHCPv6-PD [RFC3633] as a complement. 439 For example, the ANI/GRASP based method can be used intra-domain, 440 while the DHCPv6-PD method works inter-domain (i.e., across an 441 administrative boundary). Also, ANI/GRASP can be used inside the 442 domain, and DHCP/DHCPv6-PD be used on the edge of the domain to 443 client (non-ANI devices). Another similar use case would be ANI/ 444 GRASP inside the domain, with RADIUS [RFC2865] providing prefixes to 445 client devices. 447 4.4. Prefix logging 449 Within the autonomic prefix management, all the prefix assignment is 450 done by devices without human intervention. It may be required to 451 record all the prefix assignment history, for example to detect or 452 trace lost prefixes after outages, or to meet legal requirements. 453 However, the logging and reporting process is out of scope for this 454 document. 456 5. Autonomic Prefix Management Objectives 458 This section defines the GRASP technical objective options that are 459 used to support autonomic prefix management. 461 5.1. Edge Prefix Objective Option 463 The PrefixManager Objective option is a GRASP objective option 464 conforming to [I-D.ietf-anima-grasp]. Its name is "PrefixManager" 465 (see Section 8) and it carries the following data items as its value: 466 the prefix length, and the actual prefix bits. Since GRASP is based 467 on CBOR (Concise Binary Object Representation [RFC7049]), the format 468 of the PrefixManager Objective option is described as follows in CBOR 469 data definition language (CDDL) [I-D.ietf-cbor-cddl]: 471 objective = ["PrefixManager", objective-flags, loop-count, 472 [length, ?prefix]] 474 loop-count = 0..255 ; as in the GRASP specification 475 objective-flags /= ; as in the GRASP specification 476 length = 0..128 ; requested or offered prefix length 477 prefix = bytes .size 16 ; offered prefix in binary format 479 The use of the 'dry run' mode of GRASP is NOT RECOMMENDED for this 480 objective, because it would require both ASAs to store state about 481 the corresponding negotiation, to no real benefit - the requesting 482 ASA cannot base any decisions on the result of a successful dry run 483 negotiation. 485 5.2. IPv4 extension 487 This section presents an extended version of the PrefixManager 488 Objective that supports IPv4 by adding an extra flag: 490 objective = ["PrefixManager", objective-flags, loop-count, prefval] 492 loop-count = 0..255 ; as in the GRASP specification 493 objective-flags /= ; as in the GRASP specification 495 prefval /= pref6val 496 pref6val = [version6, length, ?prefix] 497 version6 = 6 498 length = 0..128 ; requested or offered prefix length 499 prefix = bytes .size 16 ; offered prefix in binary format 501 prefval /= pref4val 502 pref4val = [version4, length4, ?prefix4] 503 version4 = 4 504 length4 = 0..32 ; requested or offered prefix length 505 prefix4 = bytes .size 4 ; offered prefix in binary format 507 Prefix and address management for IPv4 is considerably more difficult 508 than for IPv6, due to the prevalence of NAT, ambiguous addresses 509 [RFC1918], and address sharing [RFC6346]. These complexities might 510 require further extending the objective with additional fields which 511 are not defined by this document. 513 6. Prefix Management Parameters 515 An implementation of a prefix manager MUST include default settings 516 of all necessary parameters. However, within a single administrative 517 domain, the network operator MAY change default parameters for all 518 devices with a certain role. Thus it would be possible to apply an 519 intended policy for every device in a simple way, without traditional 520 configuration files. As noted in Section 4.1, individual autonomic 521 devices may also change their own behavior dynamically. 523 For example, the network operator could change the default prefix 524 length for each type of role. A prefix management parameters 525 objective, which contains mapping information of device roles and 526 their default prefix lengths, MAY be flooded in the network, through 527 the Autonomic Control Plane (ACP) 528 [I-D.ietf-anima-autonomic-control-plane]. The objective is defined 529 in CDDL as follows: 531 objective = ["PrefixManager.Params", objective-flags, any] 533 loop-count = 0..255 ; as in the GRASP specification 534 objective-flags /= ; as in the GRASP specification 536 The 'any' object would be the relevant parameter definitions (such as 537 the example below) transmitted as a CBOR object in an appropriate 538 format. 540 This could be flooded to all nodes, and any PrefixManager ASA that 541 did not receive it for some reason could obtain a copy using GRASP 542 unicast synchronization. Upon receiving the prefix management 543 parameters, every device can decide its default prefix length by 544 matching its own role. 546 6.1. Example of Prefix Management Parameters 548 The parameters comprise mapping information of device roles and their 549 default prefix lengths in an autonomic domain. For example, suppose 550 an IPRAN (IP Radio Access Network) operator wants to configure the 551 prefix length of Radio Network Controller Site Gateway (RSG) as 34, 552 the prefix length of Aggregation Site Gateway (ASG) as 44, and the 553 prefix length of Cell Site Gateway (CSG) as 56. This could be 554 described in the value of the PrefixManager.Params objective as: 556 [ 557 [["role", "RSG"],["prefix_length", 34]], 558 [["role", "ASG"],["prefix_length", 44]], 559 [["role", "CSG"],["prefix_length", 56]] 560 ] 562 This example is expressed in JSON notation [RFC7159], which is easy 563 to represent in CBOR. 565 An alternative would be to express the parameters in YANG [RFC7950] 566 using the YANG-to-CBOR mapping [I-D.ietf-core-yang-cbor]. 568 For clarity, the background of the example is introduced below, which 569 can also be regarded as a use case of the mechanism proposed in this 570 document. 572 An IPRAN network is used for mobile backhaul, including radio 573 stations, RNC (in 3G) or the packet core (in LTE), and the IP network 574 between them as shown in Figure 1. The eNB (Evolved Node B), RNC 575 (Radio Network Controller), SGW (Service Gateway), and MME (Mobility 576 Management Entity) are mobile network entities defined in 3GPP. The 577 CSG, ASG, and RSG are entities defined in the IPRAN solution. 579 The IPRAN topology shown in Figure 1 includes Ring1 which is the 580 circle following ASG1->RSG1->RSG2->ASG2->ASG1, Ring2 following 581 CSG1->ASG1->ASG2->CSG2->CSG1, and Ring3 following 582 CSG3->ASG1->ASG2->CSG3. In a real deployment of IPRAN, there may be 583 more stations, rings, and routers in the topology, and normally the 584 network is highly dependent on human design and configuration, which 585 is neither flexible nor cost-effective. 587 +------+ +------+ 588 | eNB1 |---| CSG1 |\ 589 +------+ +------+ \ +-------+ +------+ +-------+ 590 | \ | ASG1 |-------| RSG1 |-----------|SGW/MME| 591 | Ring2 +-------+ +------+ \ /+-------+ 592 +------+ +------+ / | | \ / 593 | eNB2 |---| CSG2 | \ / | Ring1 | \/ 594 +------+ +------+ \ Ring3| | /\ 595 / \ | | / \ 596 +------+ +------+ / \ +-------+ +------+/ \+-------+ 597 | eNB3 |---| CSG3 |--------| ASG2 |------| RSG2 |---------| RNC | 598 +------+ +------+ +-------+ +------+ +-------+ 600 Figure 1: IPRAN Topology Example 602 If ANI/GRASP is supported in the IPRAN network, the network nodes 603 should be able to negotiate with each other, and make some autonomic 604 decisions according to their own status and the information collected 605 from the network. The Prefix Management Parameters should be part of 606 the information they communicate. 608 The routers should know the role of their neighbors, the default 609 prefix length for each type of role, etc. An ASG should be able to 610 request prefixes from an RSG, and an CSG should be able to request 611 prefixes from an ASG. In each request, the ASG/CSG should indicate 612 the required prefix length, or its role, which implies what length it 613 needs by default. 615 7. Security Considerations 617 Relevant security issues are discussed in [I-D.ietf-anima-grasp]. 618 The preferred security model is that devices are trusted following 619 the secure bootstrap procedure 620 [I-D.ietf-anima-bootstrapping-keyinfra] and that a secure Autonomic 621 Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane] is in 622 place. 624 It is RECOMMENDED that DHCPv6-PD, if used, should be operated using 625 DHCPv6 authentication or Secure DHCPv6. 627 8. IANA Considerations 629 This document defines two new GRASP Objective Option names, 630 "PrefixManager" and "PrefixManager.Params". The IANA is requested to 631 add these to the GRASP Objective Names Table registry defined by 632 [I-D.ietf-anima-grasp] (if approved). 634 9. Acknowledgements 636 Valuable comments were received from William Atwood, Fred Baker, 637 Michael Behringer, Ben Campbell, Laurent Ciavaglia, Toerless Eckert, 638 Joel Halpern, Russ Housley, Geoff Huston, Warren Kumari, Dan 639 Romascanu, and Chongfeng Xie. 641 10. Change log [RFC Editor: Please remove] 643 draft-jiang-anima-prefix-management-00: original version, 2014-10-25. 645 draft-jiang-anima-prefix-management-01: add intent example and 646 coauthor Zongpeng Du, 2015-05-04. 648 draft-jiang-anima-prefix-management-02: update references and the 649 format of the prefix management intent, 2015-10-14. 651 draft-ietf-anima-prefix-management-00: WG adoption, clarify scope and 652 purpose, update text to match latest GRASP spec, 2016-01-11. 654 draft-ietf-anima-prefix-management-01: minor update, 2016-07-08. 656 draft-ietf-anima-prefix-management-02: replaced intent discussion by 657 parameter setting, 2017-01-10. 659 draft-ietf-anima-prefix-management-03: corrected object format, 660 improved parameter setting example, 2017-03-10. 662 draft-ietf-anima-prefix-management-04: add more explanations about 663 the solution, add IPv4 options, removed PD flag, 2017-06-23. 665 draft-ietf-anima-prefix-management-05: selected one IPv4 option, 666 updated references, 2017-08-14. 668 draft-ietf-anima-prefix-management-06: handled IETF Last Call 669 comments, 2017-10-18. 671 draft-ietf-anima-prefix-management-07: handled IESG comments, 672 2017-12-18. 674 11. References 676 11.1. Normative References 678 [I-D.ietf-anima-autonomic-control-plane] 679 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 680 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 681 plane-12 (work in progress), October 2017. 683 [I-D.ietf-anima-bootstrapping-keyinfra] 684 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 685 S., and K. Watsen, "Bootstrapping Remote Secure Key 686 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 687 keyinfra-09 (work in progress), October 2017. 689 [I-D.ietf-anima-grasp] 690 Bormann, C., Carpenter, B., and B. Liu, "A Generic 691 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 692 grasp-15 (work in progress), July 2017. 694 [I-D.ietf-cbor-cddl] 695 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 696 definition language (CDDL): a notational convention to 697 express CBOR data structures", draft-ietf-cbor-cddl-00 698 (work in progress), July 2017. 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, 702 DOI 10.17487/RFC2119, March 1997, 703 . 705 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 706 Host Configuration Protocol (DHCP) version 6", RFC 3633, 707 DOI 10.17487/RFC3633, December 2003, 708 . 710 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 711 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 712 2014, . 714 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 715 RFC 7950, DOI 10.17487/RFC7950, August 2016, 716 . 718 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 719 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 720 May 2017, . 722 11.2. Informative References 724 [I-D.ietf-anima-reference-model] 725 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 726 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 727 Reference Model for Autonomic Networking", draft-ietf- 728 anima-reference-model-05 (work in progress), October 2017. 730 [I-D.ietf-core-yang-cbor] 731 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 732 Minaburo, "CBOR Encoding of Data Modeled with YANG", 733 draft-ietf-core-yang-cbor-05 (work in progress), August 734 2017. 736 [I-D.liu-dhc-dhcp-yang-model] 737 Liu, B., Lou, K., and C. Chen, "Yang Data Model for DHCP 738 Protocol", draft-liu-dhc-dhcp-yang-model-06 (work in 739 progress), March 2017. 741 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 742 and E. Lear, "Address Allocation for Private Internets", 743 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 744 . 746 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 747 "Remote Authentication Dial In User Service (RADIUS)", 748 RFC 2865, DOI 10.17487/RFC2865, June 2000, 749 . 751 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 752 RFC 3046, DOI 10.17487/RFC3046, January 2001, 753 . 755 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 756 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 757 DOI 10.17487/RFC6221, May 2011, 758 . 760 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 761 the IPv4 Address Shortage", RFC 6346, 762 DOI 10.17487/RFC6346, August 2011, 763 . 765 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 766 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 767 October 2013, . 769 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 770 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 771 Networking: Definitions and Design Goals", RFC 7575, 772 DOI 10.17487/RFC7575, June 2015, 773 . 775 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 776 Analysis for Autonomic Networking", RFC 7576, 777 DOI 10.17487/RFC7576, June 2015, 778 . 780 Appendix A. Deployment Overview 782 This Appendix includes logical deployment models, and explanations of 783 the target deployment models. The purpose is to help in 784 understanding the mechanism of the document. 786 This Appendix includes two sub-sections: A.1 for the two most common 787 DHCP deployment models, and A.2 for the proposed PD deployment model. 788 It should be noted that these are just examples, and there are many 789 more deployment models. 791 A.1. Address & Prefix management with DHCP 793 Edge DHCP server deployment requires every edge router connecting to 794 CPE to be a DHCP server assigning IPv4/IPv6 addresses to CPE - and 795 optionally IPv6 prefixes via DHCPv6-PD for IPv6 capable CPE that are 796 router and have LANs behind them. 798 edge 799 dynamic, "netconf/YANG" interfaces 800 <---------------> +-------------+ 801 +------+ <- telemetry | edge router/|-+ ----- +-----+ 802 |config| .... Domain ... | DHCP server | | ... | CPE |+ LANs 803 |server| +-------------+ | ----- +-----+| (---| ) 804 +------+ +--------------+ DHCP/ +-----+ 805 DHCPv6 / PD 807 Figure 2: DHCP Deployment Model without a Central DHCP Server 809 This requires various coordination functions via some backend system 810 depicted as "config server": The address prefixes on the edge 811 interfaces should be slightly larger than required for the number of 812 CPEs connected so that the overall address space is best used. 814 The config server needs to provision edge interface address prefixes 815 and DHCP parameters for every edge router. If too fine grained 816 prefixes are used, this will result in large routing tables across 817 the "Domain". If too coarse grained prefixes are used, address space 818 is wasted. (This is less of a concern for IPv6, but if the model 819 includes IPv4, it is a very serious concern.) 821 There is no standard describing algorithms for how configuration 822 servers would best perform this ongoing dynamic provisioning to 823 optimize routing table size and address space utilization. 825 There are currently no complete YANG models that a config server 826 could use to perform these actions (including telemetry of assigned 827 addresses from such distributed DHCP servers). 829 For example, a YANG model for controlling DHCP server operations is 830 still in draft [I-D.liu-dhc-dhcp-yang-model]. 832 Due to these and other problems of the above model, the more common 833 DHCP deployment model is as follows: 835 +------+ edge 836 |config| initial, "CLI" interfaces 837 |server| ----------------> +-------------+ 838 +------+ | edge router/|-+ ----- +-----+ 839 | .... Domain ... | DHCP relay | | ... | CPE |+ LANs 840 +------+ +-------------+ | ----- +-----+| (---| ) 841 |DHCP | +--------------+ DHCP/ +-----+ 842 |server| DHCPv6 / PD 843 +------+ 845 Figure 3: DHCP Deployment Model with a Central DHCP Server 847 Dynamic provisioning changes to edge routers are avoided by using a 848 central DHCP server and reducing the edge router from DHCP server to 849 DHCP relay. The "configuration" on the edge routers is static, the 850 DHCP relay function inserts "edge interface" and/or subscriber 851 identifying options into DHCP requests from CPE (e.g., [RFC3046], 852 [RFC6221]), the DHCP server has complete policies for address 853 assignments and prefixes useable on every edge-router/interface/ 854 subscriber-group. When the DHCP relay sees the DHCP reply, it 855 inserts static routes for the assigned address/address-prefix into 856 the routing table of the edge router which are then to be distributed 857 by the IGP (or BGP) inside the domain to make the CPE and LANs 858 reachable across the Domain. 860 There is no comprehensive standardization of these solutions. 861 [RFC3633] section 14, for example, simply refers to "a [non-defined] 862 protocol or other out-of-band communication to add routing 863 information for delegated prefixes into the provider edge router". 865 A.2. Prefix management with ANI/GRASP 867 With the proposed use of ANI and Prefix-management ASAs using GRASP, 868 the deployment model is intended to look as follows: 870 |<............ ANI Domain / ACP............>| (...) ........-> 872 Roles 873 | 874 v "Edge routers" 875 GRASP parameter +----------+ 876 Network wide | PM-ASA | downstream 877 parameters/policies | (DHCP- | interfaces 878 | |functions)| ------ 879 v "central device" +----------+ 880 +------+ ^ +--------+ 881 |PM-ASA| <............GRASP .... .... | CPE |-+ (LANs) 882 +------+ . v |(PM-ASA)| | ---| 883 . +........+ +----------+ +--------+ | 884 +...........+ . PM-ASA . | PM-ASA | ------ +---------+ 885 .DHCP server. +........+ | (DHCP- | SLAAC/ 886 +...........+ "intermediate |functions)| DHCP/DHCP-PD 887 router" +----------+ 889 Figure 4: Proposed Deployment Model using ANI/GRASP 891 The network runs an ANI domain with ACP 892 [I-D.ietf-anima-autonomic-control-plane] between some central device 893 (e.g., router or ANI enabled management device) and the edge routers. 894 ANI/ACP provides a secure, zero-touch communication channel between 895 the devices and enables the use of GRASP[I-D.ietf-anima-grasp] not 896 only for p2p communication, but also for distribution/flooding. 898 The central devices and edge routers run software in the form of 899 "Autonomic Service Agents" (ASA) to support this document's autonomic 900 IPv6 edge prefix management (PM). The ASAs for prefix management are 901 called PM-ASAs below, and together comprise the Autonomic Prefix 902 Management Function. 904 Edge routers can have different roles based on the type and number of 905 CPE attaching to them. Each edge router could be an RSG, ASG, or CSG 906 in mobile aggregation networks (see Section 6.1). Mechanisms outside 907 the scope of this document make routers aware of their roles. 909 Some considerations about the proposed deployment model are listed as 910 follows. 912 1. In a minimum Prefix Management solution, the central device uses 913 the "PrefixManager.Params" GRASP Objective introduced in this 914 document to disseminate network wide, per-role parameters to edge 915 routers. The PM-ASA uses the parameters applying to its role to 916 locally configure pre-existing addressing functions. Because PM-ASA 917 does not manage the dynamic assignment of actual IPv6 address 918 prefixes in this case, the following options can be considered: 920 1.a The edge router connects via downstream interfaces to (host) CPE 921 that each requires an address. The PM-ASA sets up for each such 922 interface a DHCP requesting router (according to [RFC3633]) to 923 request an IPv6 prefix for the interface. The router's address on 924 the downstream interface can be another parameter from the GRASP 925 Objective. The CPEs assign addresses in the prefix via RAs from the 926 router or the PM-ASA manages a local DHCPv6 server to assign 927 addresses to the CPEs. A central DHCP server acting as the DHCP 928 delegating router (according to [RFC3633]) is required. Its address 929 can be another parameter from the GRASP Objective. 931 1.b The edge router also connects via downstream interfaces to 932 (customer managed) CPEs that are routers and act as DHCPv6 requesting 933 routers. The need to support this could be derived from role and/or 934 GRASP parameters and the PM-ASA sets up a DHCP relay function to pass 935 on requests to the central DHCP server as in 1.a. 937 2. In a solution without a central DHCP server, the PM-ASA on the 938 edge routers not only learn parameters from "PrefixManager.Params" 939 but also utilize GRASP to request/negotiate actual IPv6 prefix 940 delegation via the GRASP "PrefixManager" objective described in more 941 detail below. In the most simple case, these prefixes are delegated 942 via this GRASP objective from the PM-ASA in the central device. This 943 device must be provisioned initially with a large pool of prefixes. 944 The delegated prefixes are then used by the PM-ASA on the edge 945 routers to edge routers to configure prefixes on their downstream 946 interfaces to assign addresses via RA/SLAAC to host CPEs. The PM-ASA 947 may also start local DHCP servers (as in 1.a) to assign addresses via 948 DHCP to CPE from the prefixes it received. This includes both host 949 CPEs requesting IPv6 addresses as well as router CPEs that request 950 IPv6 prefixes. The PM-ASA needs to manage the address pool(s) it has 951 requested via GRASP and allocate sub-address pools to interfaces and 952 the local DHCP servers it starts. It needs to monitor the address 953 utilization and accordingly request more address prefixes if its 954 existing prefixes are exhausted, or return address prefixes when they 955 are unneeded. 957 This solution is quite similar to the initial described IPv6 DHCP 958 deployment model without central DHCP server, and ANI/ACP/GRASP and 959 the PM-ASA do provide the automation to make this approach work more 960 easily than it is possible today. 962 3. The address pool(s) from which prefixes are allocated does not 963 need to be taken all from one central location. Edge router PM-ASA 964 that received a big (short) prefix from a central PM-ASA could offer 965 smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could 966 be used in such a way that the PM-ASA would find and select the 967 objective from the closest neighboring PM-ASA, therefore allowing to 968 maximize aggregation: A PM-ASA would only request further (smaller/ 969 shorter) prefixes when it exhausts its own poll (from the central 970 location) and can not get further large prefixes from that central 971 location anymore. Because the overflow prefixes taken from a 972 topological nearby PM-ASA, the number of longer prefixes that have to 973 be injected into the routing tables is limited and the topological 974 proximity increases the chances that aggregation of prefixes in the 975 IGP can most likely limit the geography in which the longer prefixes 976 need to be routed. 978 4. Instead of peer-to-peer optimization of prefix delegation, a 979 hierarchy of PM-ASA can be built (indicated in the picture via a 980 dotted intermediate router). This would require additional 981 parameters to the "PrefixManager" objective to allow creating a 982 hierarchy of PM-ASA across which the prefixes can be delegated. This 983 is not detailed further below. 985 5. In cases where CPEs are also part of the ANI Domain (e.g., 986 "Managed CPE"), then GRASP will extend into the actual customer sites 987 and can equally run a PM-ASA. All the options described in points 1 988 to 4 above would then apply to the CPE as the edge router with the 989 mayor changes being that a) a CPE router will most likley not need to 990 run DHCPv6-PD itself, but only DHCP address assignment, b) The edge 991 routers to which the CPE connect would most likely become ideal 992 places to run a hierarchical instance of PD-ASAs on as outlined in 993 point 1. 995 Authors' Addresses 997 Sheng Jiang (editor) 998 Huawei Technologies Co., Ltd 999 Q14, Huawei Campus, No.156 Beiqing Road 1000 Hai-Dian District, Beijing, 100095 1001 P.R. China 1003 Email: jiangsheng@huawei.com 1005 Zongpeng Du 1006 Huawei Technologies Co., Ltd 1007 Q14, Huawei Campus, No.156 Beiqing Road 1008 Hai-Dian District, Beijing, 100095 1009 P.R. China 1011 Email: duzongpeng@huawei.com 1013 Brian Carpenter 1014 Department of Computer Science 1015 University of Auckland 1016 PB 92019 1017 Auckland 1142 1018 New Zealand 1020 Email: brian.e.carpenter@gmail.com 1022 Qiong Sun 1023 China Telecom 1024 No.118, Xizhimennei Street 1025 Beijing 100035 1026 P. R. China 1028 Email: sunqiong@ctbri.com.cn