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