diff options
Diffstat (limited to 'doc/rfc/rfc8992.txt')
| -rw-r--r-- | doc/rfc/rfc8992.txt | 1018 |
1 files changed, 1018 insertions, 0 deletions
diff --git a/doc/rfc/rfc8992.txt b/doc/rfc/rfc8992.txt new file mode 100644 index 0000000..712ae28 --- /dev/null +++ b/doc/rfc/rfc8992.txt @@ -0,0 +1,1018 @@ + + + + +Internet Engineering Task Force (IETF) S. Jiang, Ed. +Request for Comments: 8992 Huawei Technologies Co., Ltd +Category: Informational Z. Du +ISSN: 2070-1721 China Mobile + B. Carpenter + Univ. of Auckland + Q. Sun + China Telecom + May 2021 + + + Autonomic IPv6 Edge Prefix Management in Large-Scale Networks + +Abstract + + 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 this + document is to use it for validation of the design of various + components of the Autonomic Networking Infrastructure. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8992. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Problem Statement + 3.1. Intended User and Administrator Experience + 3.2. Analysis of Parameters and Information Involved + 3.2.1. Parameters Each Device Can Define for Itself + 3.2.2. Information Needed from Network Operations + 3.2.3. Comparison with Current Solutions + 3.3. Interaction with Other Devices + 3.3.1. Information Needed from Other Devices + 3.3.2. Monitoring, Diagnostics, and Reporting + 4. Autonomic Edge Prefix Management Solution + 4.1. Behavior of a Device Requesting a Prefix + 4.2. Behavior of a Device Providing a Prefix + 4.3. Behavior after Successful Negotiation + 4.4. Prefix Logging + 5. Autonomic Prefix Management Objectives + 5.1. Edge Prefix Objective Option + 5.2. IPv4 Extension + 6. Prefix Management Parameters + 6.1. Example of Prefix Management Parameters + 7. Security Considerations + 8. IANA Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Appendix A. Deployment Overview + A.1. Address and Prefix Management with DHCP + A.2. Prefix Management with ANI/GRASP + Acknowledgements + Authors' Addresses + +1. Introduction + + 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 is + described in [RFC7575] and [RFC7576]. The GeneRic Autonomic + Signaling Protocol (GRASP) is specified by [RFC8990] and can make use + of the 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 ANI as described in [RFC8993]. + + 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. This + 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 Internet 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 + regarding prefix lifetimes, and they may prefer to have centralized + or distributed pools of spare prefixes. In an Autonomic Network, + these are properties decided upon 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 size of 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. + +2. Terminology + + 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 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + This document uses terminology defined in [RFC7575]. + +3. Problem Statement + + The Autonomic Networking use case considered here is autonomic IPv6 + prefix management at the edge of large-scale ISP networks. + + Although DHCPv6-PD (DHCPv6 Prefix Delegation) [RFC8415] 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 Autonomic Networking 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 [RFC8990] is + intended to be such a protocol. + +3.1. Intended User and Administrator Experience + + 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. + +3.2. Analysis of Parameters and Information Involved + + For specific purposes of address management, each edge device will + implement several parameters. (Some of them can be preconfigured + before they are connected.) They include the following: + + * Identity, authentication, and authorization of this device. This + is expected to use the Autonomic Networking secure bootstrap + process [RFC8995], following which the device could safely take + part in autonomic operations. + + * Role of this device. Some example roles are discussed in + Section 6.1. + + * An IPv6 prefix length for this device. + + * An IPv6 prefix that is assigned to this device and its downstream + devices. + + The network as a whole will implement the following parameters: + + * 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. + +3.2.1. Parameters Each Device Can Define for Itself + + 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. They are as follows: + + * Default role of this device. + + * Default IPv6 prefix length for this device. + + * Cryptographic identity of this device, as needed for secure + bootstrapping [RFC8995]. + + The device may be shipped from the manufacturer with a preconfigured + role and default prefix length, which could be modified by an + autonomic mechanism. Its cryptographic identity will be installed by + its manufacturer. + +3.2.2. Information Needed from Network Operations + + 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 regarding when to request more address space -- for + example, if the address usage reaches a certain limit or + percentage. + +3.2.3. Comparison with Current Solutions + + 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 [RFC8415] to request IPv6 prefixes according to + the device role. However, defining uniform device roles may not be a + practical task, as some functions cannot be configured on the basis + of role using existing prefix delegation 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. + +3.3. Interaction with Other Devices + +3.3.1. Information Needed from Other Devices + + 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. + + * Information regarding the identity of a trust anchor is needed. + + * The device will need to discover another device from which it can + acquire IPv6 address space. + + * Information regarding the initial prefix length for the role of + each device is needed, 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 the assignment of more IPv6 address space + if it used up its assigned IPv6 address space. + +3.3.2. Monitoring, Diagnostics, and Reporting + + 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 regarding address space should be + reported to the network administrators in an abstract way -- for + example, statistics or a visualized report. + + * A forecast of address exhaustion should be reported. + +4. Autonomic Edge Prefix Management Solution + + This section introduces the building blocks for an autonomic edge + prefix management solution. As noted in Section 1, this is not a + complete description of a solution, which will depend on the detailed + design of the relevant Autonomic Service Agents (ASAs). It uses the + generic discovery and negotiation protocol defined by [RFC8990]. The + relevant GRASP objectives are defined in Section 5. + + The procedures described below are carried out by an ASA in each + device that participates in the solution. We will refer to this as + the PrefixManager ASA. + +4.1. Behavior of a Device Requesting a Prefix + + 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 via + the mechanism described in Section 6. 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 Section 2 of [RFC8650] + and Section 5.1) 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 of the 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 the negotiation, are implementation choices. + + The ASA could alternatively initiate GRASP discovery in rapid mode + with an embedded negotiation request, if it is implemented. + +4.2. Behavior of a Device Providing a Prefix + + At least one device on the network must be configured with the + initial pool of available prefixes mentioned in Section 3.2. Apart + from that requirement, any device may act as a provider of prefixes. + + 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 [RFC8990]. When this ASA receives a + subsequent Request message, it should conduct a GRASP negotiation + sequence, using Negotiate, Confirm Waiting, and Negotiation End + 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 [RFC8990], + negotiation will continue until either end stops it with a + Negotiation End message. If the negotiation succeeds, the ASA that + provides the prefix will remove the negotiated prefix from its pool, + and the requesting ASA will add it. If the negotiation fails, the + party sending the Negotiation End 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 the + negotiation, are implementation choices. + + The ASA could alternatively negotiate in response to GRASP discovery + in rapid mode, 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 provides 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 redirection 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 + resources 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 used to choose which prefixes to assign on the devices + that provide prefixes is an implementation choice. + +4.3. Behavior after Successful Negotiation + + Upon receiving a GRASP Negotiation End 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 [RFC8415] 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 can be used on the edge of the domain to + clients (non-ANI devices). Another similar use case would be ANI/ + GRASP inside the domain, with RADIUS [RFC2865] providing prefixes to + client devices. + +4.4. Prefix Logging + + Within the autonomic prefix management system, all prefix assignments + are done by devices without human intervention. It may be required + that all prefix assignment history be recorded -- 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. + +5. Autonomic Prefix Management Objectives + + This section defines the GRASP technical objective options that are + used to support autonomic prefix management. + +5.1. Edge Prefix Objective Option + + The PrefixManager Objective option is a GRASP Objective option + conforming to the GRASP specification [RFC8990]. Its name is + "PrefixManager" (see Section 8), 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) + [RFC8949], the format of the PrefixManager Objective option is + described in the Concise Data Definition Language (CDDL) [RFC8610] as + follows: + + objective = ["PrefixManager", objective-flags, loop-count, + [length, ?prefix]] + + loop-count = 0..255 ; as in the GRASP 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 + information about the corresponding negotiation, to no real benefit + -- the requesting ASA cannot base any decisions on the result of a + successful dry-run negotiation. + +5.2. IPv4 Extension + + This section presents an extended version of the PrefixManager + objective that supports IPv4 by adding an extra flag: + + objective = ["PrefixManager", objective-flags, loop-count, prefval] + + loop-count = 0..255 ; as in the GRASP specification + objective-flags /= ; as in the GRASP specification + + prefval /= pref6val + pref6val = [version6, length, ?prefix] + version6 = 6 + length = 0..128 ; requested or offered prefix length + prefix = bytes .size 16 ; offered prefix in binary format + + prefval /= pref4val + pref4val = [version4, length4, ?prefix4] + version4 = 4 + length4 = 0..32 ; requested or offered prefix length + prefix4 = bytes .size 4 ; offered prefix in binary format + + Prefix and address management for IPv4 is considerably more difficult + than for IPv6, due to the prevalence of NAT, ambiguous addresses + [RFC1918], and address sharing [RFC6346]. These complexities might + require further extending the objective with additional fields that + are not defined by this document. + +6. Prefix Management Parameters + + 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 Section 4.1, 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) [RFC8994]. The objective is + defined in CDDL as follows: + + objective = ["PrefixManager.Params", objective-flags, any] + + loop-count = 0..255 ; as in the GRASP specification + objective-flags /= ; as in the GRASP specification + + 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. + +6.1. Example of Prefix Management Parameters + + 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 a Radio Network Controller Site Gateway (RSG) as 34, + the prefix length of an Aggregation Site Gateway (ASG) as 44, and the + prefix length of a Cell Site Gateway (CSG) as 56. This could be + described in the value of the PrefixManager.Params objective as: + + [ + [["role", "RSG"],["prefix_length", 34]], + [["role", "ASG"],["prefix_length", 44]], + [["role", "CSG"],["prefix_length", 56]] + ] + + This example is expressed in JSON [RFC8259], which is easy to + represent in CBOR. + + An alternative would be to express the parameters in YANG [RFC7950] + using the YANG-to-CBOR mapping [CORE-YANG-CBOR]. + + For clarity, the background of the example is introduced below and + can also be regarded as a use case for the mechanism defined in this + document. + + An IPRAN is used for mobile backhaul, including radio stations, RNCs + (Radio Network Controllers) (in 3G) or the packet core (in LTE), and + the IP network between them, as shown in Figure 1. The eNB (Evolved + Node B) entities, the RNC, the SGW (Serving Gateway), and the MME + (Mobility Management Entity) are mobile network entities defined in + 3GPP. The CSGs, ASGs, and RSGs 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 an 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. + + +------+ +------+ + | eNB1 |---| CSG1 |\ + +------+ +------+ \ +-------+ +------+ +-------+ + | \ | ASG1 |-------| RSG1 |-----------|SGW/MME| + | Ring2 +-------+ +------+ \ /+-------+ + +------+ +------+ / | | \ / + | eNB2 |---| CSG2 | \ / | Ring1 | \/ + +------+ +------+ \ Ring3| | /\ + / \ | | / \ + +------+ +------+ / \ +-------+ +------+/ \+-------+ + | eNB3 |---| CSG3 |--------| ASG2 |------| RSG2 |---------| RNC | + +------+ +------+ +-------+ +------+ +-------+ + + Figure 1: IPRAN Topology Example + + If ANI/GRASP is supported in the IPRAN, 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 a 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. + +7. Security Considerations + + Relevant security issues are discussed in [RFC8990]. The preferred + security model is that devices are trusted following the secure + bootstrap procedure [RFC8995] and that a secure Autonomic Control + Plane (ACP) [RFC8994] is in place. + + It is RECOMMENDED that DHCPv6-PD, if used, should be implemented + using DHCPv6 authentication or Secure DHCPv6. + +8. IANA Considerations + + This document defines two new GRASP Objective option names: + "PrefixManager" and "PrefixManager.Params". The IANA has added these + to the "GRASP Objective Names" registry defined by [RFC8990]. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + <https://www.rfc-editor.org/info/rfc7950>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, + <https://www.rfc-editor.org/info/rfc8259>. + + [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., + Richardson, M., Jiang, S., Lemon, T., and T. Winters, + "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 8415, DOI 10.17487/RFC8415, November 2018, + <https://www.rfc-editor.org/info/rfc8415>. + + [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data + Definition Language (CDDL): A Notational Convention to + Express Concise Binary Object Representation (CBOR) and + JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, + June 2019, <https://www.rfc-editor.org/info/rfc8610>. + + [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic + Autonomic Signaling Protocol (GRASP)", RFC 8990, + DOI 10.17487/RFC8990, May 2021, + <https://www.rfc-editor.org/info/rfc8990>. + + [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An + Autonomic Control Plane (ACP)", RFC 8994, + DOI 10.17487/RFC8994, May 2021, + <https://www.rfc-editor.org/info/rfc8994>. + + [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., + and K. Watsen, "Bootstrapping Remote Secure Key + Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, + May 2021, <https://www.rfc-editor.org/info/rfc8995>. + +9.2. Informative References + + [CORE-YANG-CBOR] + Veillette, M., Ed., Petrov, I., Ed., and A. Pelov, "CBOR + Encoding of Data Modeled with YANG", Work in Progress, + Internet-Draft, draft-ietf-core-yang-cbor-15, 24 January + 2021, <https://tools.ietf.org/html/draft-ietf-core-yang- + cbor-15>. + + [DHCP-YANG-MODEL] + Liu, B., Ed., Lou, K., and C. Chen, "Yang Data Model for + DHCP Protocol", Work in Progress, Internet-Draft, draft- + liu-dhc-dhcp-yang-model-07, 12 October 2018, + <https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang- + model-07>. + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. + J., and E. Lear, "Address Allocation for Private + Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, + February 1996, <https://www.rfc-editor.org/info/rfc1918>. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, DOI 10.17487/RFC2865, June 2000, + <https://www.rfc-editor.org/info/rfc2865>. + + [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", + RFC 3046, DOI 10.17487/RFC3046, January 2001, + <https://www.rfc-editor.org/info/rfc3046>. + + [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. + Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, + DOI 10.17487/RFC6221, May 2011, + <https://www.rfc-editor.org/info/rfc6221>. + + [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to + the IPv4 Address Shortage", RFC 6346, + DOI 10.17487/RFC6346, August 2011, + <https://www.rfc-editor.org/info/rfc6346>. + + [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., + Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic + Networking: Definitions and Design Goals", RFC 7575, + DOI 10.17487/RFC7575, June 2015, + <https://www.rfc-editor.org/info/rfc7575>. + + [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap + Analysis for Autonomic Networking", RFC 7576, + DOI 10.17487/RFC7576, June 2015, + <https://www.rfc-editor.org/info/rfc7576>. + + [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and + A. Bierman, "Dynamic Subscription to YANG Events and + Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, + November 2019, <https://www.rfc-editor.org/info/rfc8650>. + + [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object + Representation (CBOR)", STD 94, RFC 8949, + DOI 10.17487/RFC8949, December 2020, + <https://www.rfc-editor.org/info/rfc8949>. + + [RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, + L., and J. Nobre, "A Reference Model for Autonomic + Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, + <https://www.rfc-editor.org/info/rfc8993>. + +Appendix A. Deployment Overview + + This appendix includes logical deployment models and explanations of + the target deployment models. Its purpose is to help in + understanding the mechanism described in this document. + + This appendix includes two subsections: Appendix A.1 for the two most + common DHCP deployment models and Appendix A.2 for the PD deployment + model described in this document. It should be noted that these are + just examples, and there are many more deployment models. + +A.1. Address and Prefix Management with DHCP + + Edge DHCP server deployment requires every edge router connecting to + a Customer Premises Equipment (CPE) device to be a DHCP server + assigning IPv4/IPv6 addresses to CPEs -- and, optionally, IPv6 + prefixes via DHCPv6-PD for IPv6-capable CPEs that are routers and + have LANs behind them. + + edge + dynamic, "NETCONF/YANG" interfaces + <---------------> +-------------+ + +------+ <- 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 the "config server" in Figure 2): 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 prefixes that are too + fine-grained are used, this will result in large routing tables + across the domain shown in the figure. If prefixes that are too + coarse-grained 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 that describes 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 data 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 + data model for controlling DHCP server operations is still being + developed [DHCP-YANG-MODEL]. + + Due to these and other problems related to the above model, the more + common DHCP deployment model is as follows: + + +------+ edge + |config| initial, "CLI" interfaces + |server| ----------------> +-------------+ + +------+ | 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 an "edge interface" and/or subscriber- + identifying options into DHCP requests from CPEs (e.g., [RFC3046] + [RFC6221]), and the DHCP server has complete policies for address + assignments and prefixes usable 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; these routes are then to be + distributed by the IGP (or BGP) inside the domain to make the CPE and + LANs reachable across the domain shown in the figure. + + There is no comprehensive standardization of these solutions. For + example, [RFC8415], Section 19.1.3 simply refers to "a [non-defined] + protocol or other out-of-band communication to configure routing + information for delegated prefixes on any router through which the + client may forward traffic." + +A.2. Prefix Management with ANI/GRASP + + Using the ANI and prefix management ASAs (PM-ASAs) using GRASP, the + deployment model is intended to look as follows: + + |<............ ANI domain / ACP............>| (...) ........-> + + 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: Deployment Model Using ANI/GRASP + + The network runs an ANI domain with an ACP [RFC8994] between some + central device (e.g., a router or an 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 [RFC8990] not only for peer-to-peer communication but also for + distribution/flooding. + + The central devices and edge routers run software in the form of ASAs + to support this document's autonomic IPv6 edge prefix management. + PM-ASAs as discussed below together comprise the Autonomic Prefix + Management Function. + + Edge routers can have different roles based on the type and number of + CPEs 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 related to the deployment model are 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 that apply to its own + role to locally configure preexisting addressing functions. + Because the 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 each + (host) CPE that requires an address. The PM-ASA sets up for + each such interface a DHCP requesting router (according to + [RFC8415]) 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 Router Advertisements (RAs), 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 [RFC8415]) 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 or GRASP parameters, and the PM-ASA sets + up a DHCP relay function to pass on requests to the central + DHCP server as in point 1.a. + + 2. In a solution without a central DHCP server, the PM-ASA on the + edge routers not only learns parameters from PrefixManager.Params + but also utilizes GRASP to request/negotiate actual IPv6 prefix + delegation via the GRASP PrefixManager objective, as described in + more detail below. In the simplest 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 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 point + 1.a) to assign addresses via DHCP to the CPEs from the prefixes + it received. This includes both host CPEs requesting IPv6 + addresses and 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 previous IPv6 DHCP + deployment model without a central DHCP server, and ANI/ACP/GRASP + and the PM-ASA do provide the automation to make this approach + work more easily than is possible today. + + 3. The address pools from which prefixes are allocated do not all + need to be taken from one central location. An edge-router + PM-ASA that received a big (short) prefix from a central PM-ASA + could offer smaller sub-prefixes to a 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 aggregation to be maximized: a PM-ASA + would only request further smaller prefixes when it exhausts its + own pool (from the central location) and cannot get further large + prefixes from that central location anymore. Because the + overflow prefixes taken from a topologically 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-ASAs can be built (indicated in Figure 4 via a + dotted intermediate router). This would require additional + parameters in the PrefixManager objective to allow the creation + of a hierarchy of PM-ASAs across which the prefixes can be + delegated. + + 5. In cases where CPEs are also part of the ANI domain (e.g., + "managed CPEs"), then GRASP will extend into the actual customer + sites and can also 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 major changes being that (a) a CPE router will + most likely not need to run DHCPv6-PD itself, but only DHCP + address assignment and (b) the edge routers to which the CPE + connects would most likely become ideal places on which to run a + hierarchical instance of PD-ASAs, as outlined in point 1. + +Acknowledgements + + 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. + +Authors' Addresses + + Sheng Jiang (editor) + Huawei Technologies Co., Ltd + Q14, Huawei Campus + No. 156 Beiqing Road + Hai-Dian District, Beijing + 100095 + China + + Email: jiangsheng@huawei.com + + + Zongpeng Du + China Mobile + 32 Xuanwumen West St + Xicheng District, Beijing + 100053 + China + + Email: duzongpeng@chinamobile.com + + + Brian Carpenter + University of Auckland + School of Computer Science + PB 92019 + Auckland 1142 + New Zealand + + Email: brian.e.carpenter@gmail.com + + + Qiong Sun + China Telecom + 118 Xizhimennei St + Beijing + 100035 + China + + Email: sunqiong@chinatelecom.cn |