Huawei Technologies Co., Ltd

Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China jiangsheng@huawei.com

Huawei Technologies Co., Ltd

Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China duzongpeng@huawei.com

Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand brian.e.carpenter@gmail.com

China Telecom

No.118, Xizhimennei Street Beijing 100035 P. R. China sunqiong@ctbri.com.cn

Operations and Management ANIMA WG Autonomic Networking, Prefix Management This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure.

The original purpose of this document was to validate the design of the Autonomic Networking Infrastructure (ANI) for a realistic use case. It shows how the ANI can be applied to IP prefix delegation and it outlines approaches to build a system to do this. A fully standardized solution would require more details, so this document is informational in nature. This document defines two autonomic technical objectives for IPv6 prefix management in large-scale networks, with an extension to support IPv4 prefixes. The background to Autonomic Networking (AN) is described in and . The GeneRic Autonomic Signaling Protocol (GRASP) is specified by and can make use of the proposed technical objectives to provide a solution for autonomic prefix management. An important purpose of the present document is to use it for validation of the design of GRASP and other components of the autonomic networking infrastructure described in . This document is not a complete functional specification of an autonomic prefix management system and it does not describe all detailed aspects of the GRASP objective parameters and Autonomic Service Agent (ASA) procedures necessary to build a complete system. Instead, it describes the architectural framework utilizing the components of the ANI, outlines the different deployment options and aspects, and defines GRASP objectives for use in building the system. It also provides some basic parameter examples. This document is not intended to solve all cases of IPv6 prefix management. In fact, it assumes that the network's main infrastructure elements already have addresses and prefixes. The document is dedicated to how to make IPv6 prefix management at the edges of large-scale networks as autonomic as possible. It is specifically written for service provider (ISP) networks. Although there are similarities between ISPs and large enterprise networks, the requirements for the two use cases differ. In any case, the scope of the solution is expected to be limited, like any autonomic network, to a single management domain. However, the solution is designed in a general way. Its use for a broader scope than edge prefixes, including some or all infrastructure prefixes, is left for future discussion. A complete solution has many aspects that are not discussed here. Once prefixes have been assigned to routers, they need to be communicated to the routing system as they are brought into use. Similarly, when prefixes are released, they need to be removed from the routing system. Different operators may have different policies about prefix lifetimes, and they may prefer to have centralized or distributed pools of spare prefixes. In an autonomic network, these are properties decided by the design of the relevant ASAs. The GRASP objectives are simply building blocks. A particular risk of distributed prefix allocation in large networks is that over time, it might lead to fragmentation of the address space and an undesirable increase in the interior routing protocol tables. The extent of this risk depends on the algorithms and policies used by the ASAs. Mitigating this risk might even become an autonomic function in itself.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses terminology defined in .

The autonomic networking use case considered here is autonomic IPv6 prefix management at the edge of large-scale ISP networks. Although DHCPv6 Prefix Delegation supports automated delegation of IPv6 prefixes from one router to another, prefix management still largely depends on human planning. In other words, there is no basic information or policy to support autonomic decisions on the prefix length that each router should request or be delegated, according to its role in the network. Roles could be defined separately for individual devices or could be generic (edge router, interior router, etc.). Furthermore, IPv6 prefix management by humans tends to be rigid and static after initial planning. The problem to be solved by autonomic networking is how to dynamically manage IPv6 address space in large-scale networks, so that IPv6 addresses can be used efficiently. Here, we limit the problem to assignment of prefixes at the edge of the network, close to access routers that support individual fixed-line subscribers, mobile customers, and corporate customers. We assume that the core infrastructure of the network has already been established with appropriately assigned prefixes. The AN approach discussed in this document is based on the assumption that there is a generic discovery and negotiation protocol that enables direct negotiation between intelligent IP routers. GRASP is intended to be such a protocol.

The intended experience is, for the administrators of a large-scale network, that the management of IPv6 address space at the edge of the network can be run with minimum effort, as devices at the edge are added and removed and as customers of all kinds join and leave the network. In the ideal scenario, the administrators only have to specify a single IPv6 prefix for the whole network and the initial prefix length for each device role. As far as users are concerned, IPv6 prefix assignment would occur exactly as it does in any other network. The actual prefix usage needs to be logged for potential offline management operations including audit and security incident tracing.

For specific purposes of address management, a few parameters are involved on each edge device (some of them can be pre-configured before they are connected). They include: Identity, authentication and authorization of this device. This is expected to use the autonomic networking secure bootstrap process , following which the device could safely take part in autonomic operations. Role of this device. Some example roles are discussed in . An IPv6 prefix length for this device. An IPv6 prefix that is assigned to this device and its downstream devices. A few parameters are involved in the network as a whole. They are: Identity of a trust anchor, which is a certification authority (CA) maintained by the network administrators, used during the secure bootstrap process. Total IPv6 address space available for edge devices. It is a pool of one or several IPv6 prefixes. The initial prefix length for each device role.

This section identifies those of the above parameters that do not need external information in order for the devices concerned to set them to a reasonable default value after bootstrap or after a network disruption. There are few of these: Default role of this device. Default IPv6 prefix length for this device. Cryptographic identity of this device, as needed for secure bootstrapping . The device may be shipped from the manufacturer with pre-configured role and default prefix length, which could be modified by an autonomic mechanism. Its cryptographic identity will be installed by its manufacturer.

This section identifies those parameters that might need operational input in order for the devices concerned to set them to a non-default value. Non-default value for the IPv6 prefix length for this device. This needs to be decided based on the role of this device. The initial prefix length for each device role. Whether to allow the device to request more address space. The policy when to request more address space, for example, if the address usage reaches a certain limit or percentage.

This section briefly compares the above use case with current solutions. Currently, the address management is still largely dependent on human planning. It is rigid and static after initial planning. Address requests will fail if the configured address space is used up. Some autonomic and dynamic address management functions may be achievable by extending the existing protocols, for example, extending DHCPv6-PD (DHCPv6 Prefix Delegation, ) to request IPv6 prefixes according to the device role. However, defining uniform device roles may not be a practical task. Some functions are not suitable to be achieved by any existing protocols. Using a generic autonomic discovery and negotiation protocol instead of specific solutions has the advantage that additional parameters can be included in the autonomic solution without creating new mechanisms. This is the principal argument for a generic approach.

This section identifies those of the above parameters that need external information from neighbor devices (including the upstream devices). In many cases, two-way dialogue with neighbor devices is needed to set or optimize them. Identity of a trust anchor. The device will need to discover a device, from which it can acquire IPv6 address space. The initial prefix length for each device role, particularly for its own downstream devices. The default value of the IPv6 prefix length may be overridden by a non-default value. The device will need to request and acquire one or more IPv6 prefixes that can be assigned to this device and its downstream devices. The device may respond to prefix delegation requests from its downstream devices. The device may require to be assigned more IPv6 address space, if it used up its assigned IPv6 address space.

This section discusses what role devices should play in monitoring, fault diagnosis, and reporting. The actual address assignments need to be logged for potential offline management operations. In general, the usage situation of address space should be reported to the network administrators, in an abstract way, for example, statistics or visualized report. A forecast of address exhaustion should be reported.

This section introduces the building blocks for an autonomic edge prefix management solution. As noted in , this is not a complete description of a solution, which will depend on the detailed design of the relevant Autonomic Service Agents. It uses the generic discovery and negotiation protocol defined by . The relevant GRASP objectives are defined in . The procedures described below are carried out by an Autonomic Service Agent (ASA) in each device that participates in the solution. We will refer to this as the PrefixManager ASA.

If the device containing a PrefixManager ASA has used up its address pool, it can request more space according to its requirements. It should decide the length of the requested prefix and request it by the mechanism described in . Note that although the device's role may define certain default allocation lengths, those defaults might be changed dynamically, and the device might request more, or less, address space due to some local operational heuristic. A PrefixManager ASA that needs additional address space should firstly discover peers that may be able to provide extra address space. The ASA should send out a GRASP Discovery message that contains a PrefixManager Objective option (see ) in order to discover peers also supporting that option. Then it should choose one such peer, most likely the first to respond. If the GRASP discovery Response message carries a divert option pointing to an off-link PrefixManager ASA, the requesting ASA may initiate negotiation with that ASA diverted device to find out whether it can provide the requested length prefix. In any case, the requesting ASA will act as a GRASP negotiation initiator by sending a GRASP Request message with a PrefixManager Objective option. The ASA indicates in this option the length of the requested prefix. This starts a GRASP negotiation process. During the subsequent negotiation, the ASA will decide at each step whether to accept the offered prefix. That decision, and the decision to end negotiation, is an implementation choice. The ASA could alternatively initiate rapid mode GRASP discovery with an embedded negotiation request, if it is implemented.

At least one device on the network must be configured with the initial pool of available prefixes mentioned in . Apart from that requirement, any device may act as a prefix providing device. A device that receives a Discovery message with a PrefixManager Objective option should respond with a GRASP Response message if it contains a PrefixManager ASA. Further details of the discovery process are described in . When this ASA receives a subsequent Request message, it should conduct a GRASP negotiation sequence, using Negotiate, Confirm-waiting, and Negotiation-ending messages as appropriate. The Negotiate messages carry a PrefixManager Objective option, which will indicate the prefix and its length offered to the requesting ASA. As described in , negotiation will continue until either end stops it with a Negotiation-ending message. If the negotiation succeeds, the prefix providing ASA will remove the negotiated prefix from its pool, and the requesting ASA will add it. If the negotiation fails, the party sending the Negotiation-ending message may include an error code string. During the negotiation, the ASA will decide at each step how large a prefix to offer. That decision, and the decision to end negotiation, is an implementation choice. The ASA could alternatively negotiate in response to rapid mode GRASP discovery, if it is implemented. This specification is independent of whether the PrefixManager ASAs are all embedded in routers, but that would be a rather natural scenario. In a hierarchical network topology, a given router typically provide prefixes for routers below it in the hierarchy, and it is also likely to contain the first PrefixManager ASA discovered by those downstream routers. However, the GRASP discovery model, including its Redirect feature, means that this is not an exclusive scenario, and a downstream PrefixManager ASA could negotiate a new prefix with a device other than its upstream router. A resource shortage may cause the gateway router to request more resource in turn from its own upstream device. This would be another independent GRASP discovery and negotiation process. During the processing time, the gateway router should send a Confirm-waiting Message to the initial requesting router, to extend its timeout. When the new resource becomes available, the gateway router responds with a GRASP Negotiate message with a prefix length matching the request. The algorithm to choose which prefixes to assign on the prefix providing devices is an implementation choice.

Upon receiving a GRASP Negotiation-ending message that indicates that an acceptable prefix length is available, the requesting device may use the negotiated prefix without further messages. There are use cases where the ANI/GRASP based prefix management approach can work together with DHCPv6-PD as a complement. For example, the ANI/GRASP based method can be used intra-domain, while the DHCPv6-PD method works inter-domain (i.e., across an administrative boundary). Also, ANI/GRASP can be used inside the domain, and DHCP/DHCPv6-PD be used on the edge of the domain to client (non-ANI devices). Another similar use case would be ANI/GRASP inside the domain, with RADIUS providing prefixes to client devices.

Within the autonomic prefix management, all the prefix assignment is done by devices without human intervention. It may be required to record all the prefix assignment history, for example to detect or trace lost prefixes after outages, or to meet legal requirements. However, the logging and reporting process is out of scope for this document.

This section defines the GRASP technical objective options that are used to support autonomic prefix management.

The PrefixManager Objective option is a GRASP objective option conforming to . Its name is "PrefixManager" (see ) and it carries the following data items as its value: the prefix length, and the actual prefix bits. Since GRASP is based on CBOR (Concise Binary Object Representation ), the format of the PrefixManager Objective option is described as follows in CBOR data definition language (CDDL) :

specification objective-flags /= ; as in the GRASP specification length = 0..128 ; requested or offered prefix length prefix = bytes .size 16 ; offered prefix in binary format ]]>

The use of the 'dry run' mode of GRASP is NOT RECOMMENDED for this objective, because it would require both ASAs to store state about the corresponding negotiation, to no real benefit - the requesting ASA cannot base any decisions on the result of a successful dry run negotiation.

This section presents an extended version of the PrefixManager Objective that supports IPv4 by adding an extra flag:

Prefix and address management for IPv4 is considerably more difficult than for IPv6, due to the prevalence of NAT, ambiguous addresses , and address sharing . These complexities might require further extending the objective with additional fields which are not defined by this document.

An implementation of a prefix manager MUST include default settings of all necessary parameters. However, within a single administrative domain, the network operator MAY change default parameters for all devices with a certain role. Thus it would be possible to apply an intended policy for every device in a simple way, without traditional configuration files. As noted in , individual autonomic devices may also change their own behavior dynamically. For example, the network operator could change the default prefix length for each type of role. A prefix management parameters objective, which contains mapping information of device roles and their default prefix lengths, MAY be flooded in the network, through the Autonomic Control Plane (ACP) . The objective is defined in CDDL as follows:

The 'any' object would be the relevant parameter definitions (such as the example below) transmitted as a CBOR object in an appropriate format. This could be flooded to all nodes, and any PrefixManager ASA that did not receive it for some reason could obtain a copy using GRASP unicast synchronization. Upon receiving the prefix management parameters, every device can decide its default prefix length by matching its own role.

The parameters comprise mapping information of device roles and their default prefix lengths in an autonomic domain. For example, suppose an IPRAN (IP Radio Access Network) operator wants to configure the prefix length of Radio Network Controller Site Gateway (RSG) as 34, the prefix length of Aggregation Site Gateway (ASG) as 44, and the prefix length of Cell Site Gateway (CSG) as 56. This could be described in the value of the PrefixManager.Params objective as:

This example is expressed in JSON notation , which is easy to represent in CBOR. An alternative would be to express the parameters in YANG using the YANG-to-CBOR mapping . For clarity, the background of the example is introduced below, which can also be regarded as a use case of the mechanism proposed in this document. An IPRAN network is used for mobile backhaul, including radio stations, RNC (in 3G) or the packet core (in LTE), and the IP network between them as shown in Figure 1. The eNB (Evolved Node B), RNC (Radio Network Controller), SGW (Service Gateway), and MME (Mobility Management Entity) are mobile network entities defined in 3GPP. The CSG, ASG, and RSG are entities defined in the IPRAN solution. The IPRAN topology shown in Figure 1 includes Ring1 which is the circle following ASG1->RSG1->RSG2->ASG2->ASG1, Ring2 following CSG1->ASG1->ASG2->CSG2->CSG1, and Ring3 following CSG3->ASG1->ASG2->CSG3. In a real deployment of IPRAN, there may be more stations, rings, and routers in the topology, and normally the network is highly dependent on human design and configuration, which is neither flexible nor cost-effective.

If ANI/GRASP is supported in the IPRAN network, the network nodes should be able to negotiate with each other, and make some autonomic decisions according to their own status and the information collected from the network. The Prefix Management Parameters should be part of the information they communicate. The routers should know the role of their neighbors, the default prefix length for each type of role, etc. An ASG should be able to request prefixes from an RSG, and an CSG should be able to request prefixes from an ASG. In each request, the ASG/CSG should indicate the required prefix length, or its role, which implies what length it needs by default.

Relevant security issues are discussed in . The preferred security model is that devices are trusted following the secure bootstrap procedure and that a secure Autonomic Control Plane (ACP) is in place. It is RECOMMENDED that DHCPv6-PD, if used, should be operated using DHCPv6 authentication or Secure DHCPv6.

This document defines two new GRASP Objective Option names, "PrefixManager" and "PrefixManager.Params". The IANA is requested to add these to the GRASP Objective Names Table registry defined by (if approved).

Valuable comments were received from William Atwood, Fred Baker, Michael Behringer, Ben Campbell, Laurent Ciavaglia, Toerless Eckert, Joel Halpern, Russ Housley, Geoff Huston, Warren Kumari, Dan Romascanu, and Chongfeng Xie.

draft-jiang-anima-prefix-management-00: original version, 2014-10-25. draft-jiang-anima-prefix-management-01: add intent example and coauthor Zongpeng Du, 2015-05-04. draft-jiang-anima-prefix-management-02: update references and the format of the prefix management intent, 2015-10-14. draft-ietf-anima-prefix-management-00: WG adoption, clarify scope and purpose, update text to match latest GRASP spec, 2016-01-11. draft-ietf-anima-prefix-management-01: minor update, 2016-07-08. draft-ietf-anima-prefix-management-02: replaced intent discussion by parameter setting, 2017-01-10. draft-ietf-anima-prefix-management-03: corrected object format, improved parameter setting example, 2017-03-10. draft-ietf-anima-prefix-management-04: add more explanations about the solution, add IPv4 options, removed PD flag, 2017-06-23. draft-ietf-anima-prefix-management-05: selected one IPv4 option, updated references, 2017-08-14. draft-ietf-anima-prefix-management-06: handled IETF Last Call comments, 2017-10-18. draft-ietf-anima-prefix-management-07: handled IESG comments, 2017-12-18.

This Appendix includes logical deployment models, and explanations of the target deployment models. The purpose is to help in understanding the mechanism of the document. This Appendix includes two sub-sections: A.1 for the two most common DHCP deployment models, and A.2 for the proposed PD deployment model. It should be noted that these are just examples, and there are many more deployment models.

Edge DHCP server deployment requires every edge router connecting to CPE to be a DHCP server assigning IPv4/IPv6 addresses to CPE - and optionally IPv6 prefixes via DHCPv6-PD for IPv6 capable CPE that are router and have LANs behind them.

+-------------+ +------+ <- telemetry | edge router/|-+ ----- +-----+ |config| .... Domain ... | DHCP server | | ... | CPE |+ LANs |server| +-------------+ | ----- +-----+| (---| ) +------+ +--------------+ DHCP/ +-----+ DHCPv6 / PD Figure 2: DHCP Deployment Model without a Central DHCP Server ]]>

This requires various coordination functions via some backend system depicted as "config server": The address prefixes on the edge interfaces should be slightly larger than required for the number of CPEs connected so that the overall address space is best used. The config server needs to provision edge interface address prefixes and DHCP parameters for every edge router. If too fine grained prefixes are used, this will result in large routing tables across the "Domain". If too coarse grained prefixes are used, address space is wasted. (This is less of a concern for IPv6, but if the model includes IPv4, it is a very serious concern.) There is no standard describing algorithms for how configuration servers would best perform this ongoing dynamic provisioning to optimize routing table size and address space utilization. There are currently no complete YANG models that a config server could use to perform these actions (including telemetry of assigned addresses from such distributed DHCP servers). For example, a YANG model for controlling DHCP server operations is still in draft . Due to these and other problems of the above model, the more common DHCP deployment model is as follows:

+-------------+ +------+ | edge router/|-+ ----- +-----+ | .... Domain ... | DHCP relay | | ... | CPE |+ LANs +------+ +-------------+ | ----- +-----+| (---| ) |DHCP | +--------------+ DHCP/ +-----+ |server| DHCPv6 / PD +------+ Figure 3: DHCP Deployment Model with a Central DHCP Server ]]>

Dynamic provisioning changes to edge routers are avoided by using a central DHCP server and reducing the edge router from DHCP server to DHCP relay. The "configuration" on the edge routers is static, the DHCP relay function inserts "edge interface" and/or subscriber identifying options into DHCP requests from CPE (e.g., , ), the DHCP server has complete policies for address assignments and prefixes useable on every edge-router/interface/subscriber-group. When the DHCP relay sees the DHCP reply, it inserts static routes for the assigned address/address-prefix into the routing table of the edge router which are then to be distributed by the IGP (or BGP) inside the domain to make the CPE and LANs reachable across the Domain. There is no comprehensive standardization of these solutions. section 14, for example, simply refers to "a [non-defined] protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router".

With the proposed use of ANI and Prefix-management ASAs using GRASP, the deployment model is intended to look as follows:

| (...) ........-> Roles | v "Edge routers" GRASP parameter +----------+ Network wide | PM-ASA | downstream parameters/policies | (DHCP- | interfaces | |functions)| ------ v "central device" +----------+ +------+ ^ +--------+ |PM-ASA| <............GRASP .... .... | CPE |-+ (LANs) +------+ . v |(PM-ASA)| | ---| . +........+ +----------+ +--------+ | +...........+ . PM-ASA . | PM-ASA | ------ +---------+ .DHCP server. +........+ | (DHCP- | SLAAC/ +...........+ "intermediate |functions)| DHCP/DHCP-PD router" +----------+ Figure 4: Proposed Deployment Model using ANI/GRASP ]]>

The network runs an ANI domain with ACP between some central device (e.g., router or ANI enabled management device) and the edge routers. ANI/ACP provides a secure, zero-touch communication channel between the devices and enables the use of GRASP not only for p2p communication, but also for distribution/flooding. The central devices and edge routers run software in the form of "Autonomic Service Agents" (ASA) to support this document's autonomic IPv6 edge prefix management (PM). The ASAs for prefix management are called PM-ASAs below, and together comprise the Autonomic Prefix Management Function. Edge routers can have different roles based on the type and number of CPE attaching to them. Each edge router could be an RSG, ASG, or CSG in mobile aggregation networks (see Section 6.1). Mechanisms outside the scope of this document make routers aware of their roles. Some considerations about the proposed deployment model are listed as follows. 1. In a minimum Prefix Management solution, the central device uses the "PrefixManager.Params" GRASP Objective introduced in this document to disseminate network wide, per-role parameters to edge routers. The PM-ASA uses the parameters applying to its role to locally configure pre-existing addressing functions. Because PM-ASA does not manage the dynamic assignment of actual IPv6 address prefixes in this case, the following options can be considered: 1.a The edge router connects via downstream interfaces to (host) CPE that each requires an address. The PM-ASA sets up for each such interface a DHCP requesting router (according to ) to request an IPv6 prefix for the interface. The router's address on the downstream interface can be another parameter from the GRASP Objective. The CPEs assign addresses in the prefix via RAs from the router or the PM-ASA manages a local DHCPv6 server to assign addresses to the CPEs. A central DHCP server acting as the DHCP delegating router (according to ) is required. Its address can be another parameter from the GRASP Objective. 1.b The edge router also connects via downstream interfaces to (customer managed) CPEs that are routers and act as DHCPv6 requesting routers. The need to support this could be derived from role and/or GRASP parameters and the PM-ASA sets up a DHCP relay function to pass on requests to the central DHCP server as in 1.a. 2. In a solution without a central DHCP server, the PM-ASA on the edge routers not only learn parameters from "PrefixManager.Params" but also utilize GRASP to request/negotiate actual IPv6 prefix delegation via the GRASP "PrefixManager" objective described in more detail below. In the most simple case, these prefixes are delegated via this GRASP objective from the PM-ASA in the central device. This device must be provisioned initially with a large pool of prefixes. The delegated prefixes are then used by the PM-ASA on the edge routers to edge routers to configure prefixes on their downstream interfaces to assign addresses via RA/SLAAC to host CPEs. The PM-ASA may also start local DHCP servers (as in 1.a) to assign addresses via DHCP to CPE from the prefixes it received. This includes both host CPEs requesting IPv6 addresses as well as router CPEs that request IPv6 prefixes. The PM-ASA needs to manage the address pool(s) it has requested via GRASP and allocate sub-address pools to interfaces and the local DHCP servers it starts. It needs to monitor the address utilization and accordingly request more address prefixes if its existing prefixes are exhausted, or return address prefixes when they are unneeded. This solution is quite similar to the initial described IPv6 DHCP deployment model without central DHCP server, and ANI/ACP/GRASP and the PM-ASA do provide the automation to make this approach work more easily than it is possible today. 3. The address pool(s) from which prefixes are allocated does not need to be taken all from one central location. Edge router PM-ASA that received a big (short) prefix from a central PM-ASA could offer smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could be used in such a way that the PM-ASA would find and select the objective from the closest neighboring PM-ASA, therefore allowing to maximize aggregation: A PM-ASA would only request further (smaller/shorter) prefixes when it exhausts its own poll (from the central location) and can not get further large prefixes from that central location anymore. Because the overflow prefixes taken from a topological nearby PM-ASA, the number of longer prefixes that have to be injected into the routing tables is limited and the topological proximity increases the chances that aggregation of prefixes in the IGP can most likely limit the geography in which the longer prefixes need to be routed. 4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy of PM-ASA can be built (indicated in the picture via a dotted intermediate router). This would require additional parameters to the "PrefixManager" objective to allow creating a hierarchy of PM-ASA across which the prefixes can be delegated. This is not detailed further below. 5. In cases where CPEs are also part of the ANI Domain (e.g., "Managed CPE"), then GRASP will extend into the actual customer sites and can equally run a PM-ASA. All the options described in points 1 to 4 above would then apply to the CPE as the edge router with the mayor changes being that a) a CPE router will most likley not need to run DHCPv6-PD itself, but only DHCP address assignment, b) The edge routers to which the CPE connect would most likely become ideal places to run a hierarchical instance of PD-ASAs on as outlined in point 1.