RFC 8992

Autonomic IPv6 Edge Prefix Management in Large-Scale Networks

📅 published May 2021, from ietf

RFC 8992: Autonomic IPv6 Edge Prefix Management in Large-Scale Networks 🎀

okay bestie, let's get into this one ✨ it's giving "ISP networking meets autonomic magic" and I'm obsessed 💅

Here's the title block tea:

  • This is RFC 8992 🦋, published in May 2021.
  • The lead author is S. Jiang, Ed. from Huawei Technologies Co., Ltd 💖
  • Co-authors: Z. Du (China Mobile), B. Carpenter (Univ. of Auckland), and Q. Sun (China Telecom) 🫶
  • It's Informational 📚 which means it's a "here's how we did it, come learn" doc and NOT a Standards Track spec. Not me saying "MUST" like a bossy standard 🙈
  • It's ISSN: 2070-1721 🌸
  • It doesn't obsolete or update anything. Clean slate, no drama 👑
The vibe: this is a validation case study for the Autonomic Networking Infrastructure (ANI). It's a proof that the ANI design actually works for a real job, which is handing out IP prefixes at the edge of big ISP networks 🧚

Abstract ✨

Okay so the abstract is giving elevator pitch 🎀. It says this doc defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, plus an extension for IPv4 prefixes too 🌈. The big purpose is to use it to test-drive the design of different ANI components 💅.

Status of This Memo ✨

Not a Standards Track spec, just published for info 📚🌸. But it IS a real IETF product with community consensus, public review, and IESG approval 🫶. Not every IESG-approved doc is a candidate for an Internet Standard, though. Section 2 of RFC 7841 has the deets 💜.

For the latest status, errata, and feedback, check https://www.rfc-editor.org/info/rfc8992 🦋.

Copyright (c) 2021 IETF Trust and the authors, all rights reserved 💖. This is governed by BCP 78 and the Trust's Legal Provisions as of publication day. Read them, because they spell out your rights 🎀. If you pull Code Components out of the doc, they need the Simplified BSD License text from Section 4.e of the Trust Legal Provisions, and that code comes with no warranty 💅.

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 ✨

Okay so the original goal of this doc was to validate the ANI design for a realistic use case 🦋. It shows how ANI can handle IP prefix delegation, and it sketches how you'd build a system to do it. A fully standardized solution would need more detail, which is why this one is informational 📚.

This doc defines two autonomic technical objectives for IPv6 prefix management in large-scale networks, plus an IPv4 prefix extension 🌈. The background on Autonomic Networking is in [RFC7575] and [RFC7576] 💜. The GeneRic Autonomic Signaling Protocol (GRASP) is specified in [RFC8990] and can use these objectives to build an autonomic prefix management solution 🧚. The whole point is validating the design of GRASP and other ANI components as described in [RFC8993] 💅.

This doc is NOT a full functional spec of an autonomic prefix management system 🙈. It doesn't cover every detail of GRASP objective parameters and Autonomic Service Agent (ASA) procedures you'd need to build a complete system. Instead, it describes the architectural framework built from ANI components, outlines different deployment options, and defines GRASP objectives you can use to build the thing 🎀. It also gives some basic parameter examples 🫶.

This doc doesn't try to solve every IPv6 prefix management case 💅. It assumes the network's main infrastructure elements already have addresses and prefixes. The focus is making IPv6 prefix management at the edges of large-scale networks as autonomic as possible 🌸. It's written specifically for Internet Service Provider (ISP) networks 👑. Enterprise networks are similar in some ways, but the requirements differ 💖. Either way, like any Autonomic Network, the scope is expected to be limited to a single management domain 🦋.

The solution is designed generally, though ✨. Using it for a broader scope than edge prefixes, including some or all infrastructure prefixes, is left for future discussion 🌈.

A complete solution has plenty of aspects this doc skips 💜. Once prefixes are assigned to routers, they need to be communicated to the routing system as they come into use. Same deal in reverse: when prefixes are released, they need to be removed from the routing system 🧚. Operators may have different policies on prefix lifetimes and may prefer centralized or distributed pools of spare prefixes 💅. In an Autonomic Network, those are properties decided by the design of the relevant ASAs. The GRASP objectives are just building blocks 🫶.

One particular risk with distributed prefix allocation in large networks: over time it might fragment the address space and make interior routing protocol tables bigger than they should be 😭. How big that risk gets depends on the algorithms and policies the ASAs use. Mitigating it might even become an autonomic function in itself 🔥.

2. Terminology ✨

Here's the key word situation 💅. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14 [RFC2119] [RFC8174] 🎀. But ONLY when they show up in ALL CAPS, like here 💖. Lowercase is just regular English, no cap 🙈.

This doc uses terminology defined in [RFC7575] 🦋.

3. Problem Statement ✨

The Autonomic Networking use case here is autonomic IPv6 prefix management at the edge of large-scale ISP networks 🌈.

DHCPv6-PD (DHCPv6 Prefix Delegation) [RFC8415] lets you auto-delegate IPv6 prefixes from one router to another 🧚. But prefix management still mostly depends on humans planning things 😭. There's no basic info or policy to support autonomic decisions on the prefix length each router should request or be delegated, based on its role in the network 💅. Roles could be defined per device or be generic, like edge router or interior router 🫶. And human-driven IPv6 prefix management tends to be rigid and static after the initial planning 🌸.

So the problem Autonomic Networking needs to solve is how to dynamically manage IPv6 address space in large networks so it gets used efficiently 💖. This doc limits the problem to prefix assignment at the edge, close to access routers serving fixed-line subscribers, mobile customers, and corporate customers 🦋. We assume the core infrastructure already has appropriately assigned prefixes 👑. The approach here assumes there's a generic discovery and negotiation protocol that lets intelligent IP routers negotiate directly with each other 🎀. GRASP [RFC8990] is meant to be that protocol 💜.

3.1. Intended User and Administrator Experience ✨

For network admins, the dream is that managing IPv6 address space at the edge takes minimum effort 🧚. Devices get added and removed, customers come and go, and nobody has to babysit it 💅. Ideally, admins only specify a single IPv6 prefix for the whole network plus the initial prefix length for each device role 🫶. For users, prefix assignment should just work the way it does on any other network 🌸.

Actual prefix usage has to be logged for possible offline management, including audit and security incident tracing 🔥.

3.2. Analysis of Parameters and Information Involved ✨

For address management, each edge device implements several parameters 🎀. Some can be preconfigured before the device is connected 💖. They include:

  • Identity, authentication, and authorization of this device 🦋. This is expected to use the Autonomic Networking secure bootstrap process [RFC8995], after which the device can safely join 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 assigned to this device and its downstream devices 🫶.

The network as a whole implements these 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, 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 covers the parameters above that don't need external info for a device to set a reasonable default after bootstrap or after a network disruption 🎀. They are:

  • Default role of this device 🦋.
  • Default IPv6 prefix length for this device 🌈.
  • Cryptographic identity of this device, needed for secure bootstrapping [RFC8995] 💅.

The device may ship from the manufacturer with a preconfigured role and default prefix length, which an autonomic mechanism can modify 🧚. Its cryptographic identity gets installed by the manufacturer 💜.

Part 1 of 5 is done, bestie 🫶💖 Say "next" and I'll keep going with Section 3.2.2 and onward 🦋✨

3.2.2. Information Needed from Network Operations 🎀

okay so this section is about the parameters that might need a little input from network operations 💅 before a device can use a non-default value. 🦋

  • The 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 bit compares the whole use case with what we do today, and ngl the current situation is kinda sad 😭 address management still mostly depends on humans planning everything by hand. it's rigid and static after that first plan, and if the configured address space runs out, address requests just fail. 💀

some autonomic and dynamic address management stuff could be possible by extending existing protocols. for example, DHCPv6-PD [RFC8415] could be extended to request IPv6 prefixes according to the device role. 🎀 BUT defining uniform device roles might not be practical, because some functions can't be configured based on role using existing prefix delegation protocols. 🙈

using a generic autonomic discovery and negotiation protocol instead of specific solutions has a big perk: extra parameters can be added to the autonomic solution without creating new mechanisms. this is the main argument for a generic approach, and it's literally the whole point 🫶

3.3. Interaction with Other Devices

3.3.1. Information Needed from Other Devices

this section lists the parameters from above that need external info from neighbor devices, including the upstream ones. in lots of cases, the devices need a two-way conversation with their neighbors to set or optimize things. 💬

  • 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 part talks about what role devices should play in monitoring, fault diagnosis, and reporting. it's giving responsible adult energy 👑

  • 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 isn't a complete solution description, because it depends on the detailed design of the relevant Autonomic Service Agents (ASAs). 🧩 it uses the generic discovery and negotiation protocol defined by [RFC8990], and the relevant GRASP objectives are defined in Section 5.

the procedures below are carried out by an ASA in each device that takes part in the solution. we'll call this 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 based on what it needs. it should decide the length of the requested prefix and request it via the mechanism described in Section 6. ✨ note that even though the device's role may define certain default allocation lengths, those defaults might change dynamically, and the device might request more, or less, address space because of some local operational heuristic. 🤓

a PrefixManager ASA that needs more address space should first discover peers that might be able to provide extra 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) so it can find peers that also support that option. 🔎 then it should choose one such peer, most likely the first one to respond.

if the GRASP Discovery Response message carries a Divert option pointing to an off-link PrefixManager ASA, the requesting ASA may start a negotiation with that ASA-diverted device to find out whether it can provide the requested prefix length. 🦋

in any case, the requesting ASA acts as a GRASP negotiation initiator by sending a GRASP Request message with a PrefixManager Objective option. the ASA puts the requested prefix length in this option, and that kicks off the GRASP negotiation process. 🚀

during the negotiation, the ASA decides at each step whether to accept the offered prefix. that decision, and the decision to end the negotiation, are implementation choices. 🧠

the ASA could also start GRASP discovery in rapid mode with an embedded negotiation request, if it's 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 gets a Discovery message with a PrefixManager Objective option should respond with a GRASP Response message if it contains a PrefixManager ASA. more details on the discovery process are in [RFC8990]. when this ASA gets a later Request message, it should run a GRASP negotiation sequence, using Negotiate, Confirm Waiting, and Negotiation End messages as needed. 🤝 the Negotiate messages carry a PrefixManager Objective option, which indicates the prefix and its length offered to the requesting ASA. as described in [RFC8990], the negotiation continues until one end stops it with a Negotiation End message. if the negotiation succeeds, the providing ASA removes the negotiated prefix from its pool, and the requesting ASA adds it. 🎉 if the negotiation fails, the party sending the Negotiation End message may include an error code string. 🙈

during the negotiation, the ASA decides at each step how large a prefix to offer. that decision, and the decision to end the negotiation, are implementation choices. 🧠

the ASA could also negotiate in response to GRASP discovery in rapid mode, if it's implemented. ⚡

this specification doesn't care whether all the PrefixManager ASAs are embedded in routers, but that would be a pretty natural setup. 🛜 in a hierarchical network topology, a router typically provides prefixes for the routers below it in the hierarchy, and it's also likely to be the first PrefixManager ASA those downstream routers discover. however, GRASP discovery and its redirection feature mean this isn't the only possible 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. that's another independent GRASP discovery and negotiation process. 🔁 during that processing time, the gateway router should send a Confirm Waiting message to the initial requesting router to extend its timeout. once 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 🎀

once the requesting device gets a GRASP Negotiation End message that says an acceptable prefix length is available, it may use the negotiated prefix without sending 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 (that is, across an administrative boundary). 🌍 ANI/GRASP can also be used inside the domain, with DHCP/DHCPv6-PD used on the edge of the domain for clients (non-ANI devices). another similar use case is ANI/GRASP inside the domain, with RADIUS [RFC2865] providing prefixes to client devices. 🫶

4.4. Prefix Logging 📝

inside the autonomic prefix management system, every prefix assignment is done by devices with no human involved. 🤖 it may be required that the entire prefix assignment history gets 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 used to support autonomic prefix management. 🌟

5.1. Edge Prefix Objective Option 🎀

the PrefixManager Objective option is a GRASP Objective option that follows the GRASP specification [RFC8990]. its name is "PrefixManager" (see Section 8), and its value carries two data items: 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] like this:

  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. 🙅‍♀️ that's because it would make both ASAs store state about the negotiation, and there's no real benefit, since the requesting ASA can't base any decisions on the result of a successful dry-run negotiation. 🥲

5.2. IPv4 Extension 🌸

okay so this bit adds IPv4 support to the PrefixManager objective 🦋 by tacking on one extra flag. Here's the updated shape:

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

Real talk, IPv4 prefix and address management is way harder than IPv6 💀. You've got NAT everywhere, ambiguous addresses ([RFC1918]), and address sharing ([RFC6346]). Because of all that drama, this might need more fields added to the objective later, and those fields aren't defined in this document 🙈.

6. Prefix Management Parameters 💜

An implementation of a prefix manager MUST include default settings of all necessary parameters. ✨ But within a single administrative domain, the network operator MAY change default parameters for all devices with a certain role. So it's possible to apply an intended policy to every device in a simple way, no traditional configuration files needed 🙌. And like we said in Section 4.1, individual autonomic devices can 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 holds mapping info between device roles and their default prefix lengths, MAY be flooded in the network through the Autonomic Control Plane (ACP) [RFC8994]. Here's how it's defined in CDDL:

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 holds the relevant parameter definitions (like the example below) sent as a CBOR object in an appropriate format 🎀.

This could be flooded to all nodes. Any PrefixManager ASA that didn't receive it for some reason could grab a copy using GRASP unicast synchronization 🫶. Once a device gets the prefix management parameters, it can figure out its own default prefix length by matching its role 👑.

6.1. Example of Prefix Management Parameters 🦋

The parameters are the mapping info between device roles and their default prefix lengths in an autonomic domain 💅. Picture this: an IPRAN (IP Radio Access Network) operator wants the prefix length of a Radio Network Controller Site Gateway (RSG) to be 34, the prefix length of an Aggregation Site Gateway (ASG) to be 44, and the prefix length of a Cell Site Gateway (CSG) to be 56 🔥. That gets described in the value of the PrefixManager.Params objective like this:

[
   [["role", "RSG"],["prefix_length", 34]],
   [["role", "ASG"],["prefix_length", 44]],
   [["role", "CSG"],["prefix_length", 56]]
]

This example is written in JSON [RFC8259], which is super easy to represent in CBOR ✨.

An alternative is to express the parameters in YANG [RFC7950] using the YANG-to-CBOR mapping [CORE-YANG-CBOR] 🌈.

For clarity, here's the background on the example, and it can also be seen as a use case for the mechanism defined in this document 🧠.

An IPRAN is used for mobile backhaul 📡. That covers radio stations, RNCs (Radio Network Controllers) (in 3G) or the packet core (in LTE), plus 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 in Figure 1 has Ring1, which is the circle following ASG1->RSG1->RSG2->ASG2->ASG1. It also has Ring2, following CSG1->ASG1->ASG2->CSG2->CSG1, and Ring3, following CSG3->ASG1->ASG2->CSG3. In a real deployment, there may be more stations, rings, and routers in the topology. 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 based on their own status and the info collected from the network 🤖. The prefix management parameters should be part of the info they share 💌.

The routers should know the role of their neighbors, the default prefix length for each type of role, and so on 🧚‍♀️. 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 🛡️. Lowkey the most important part of this whole doc 😤.

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 ✨

okay bestie, here are the informative references 📚 these ones aren't required reading to implement the thing, but they're the context behind it 🫶

Appendix A. Deployment Overview 🧚

this appendix is full of logical deployment models and the target setups they describe 🌸 the whole point is to help you get the mechanism in this document, not to be a rulebook

it has two subsections: A.1 covers the two most common DHCP deployment models, and A.2 covers the PD deployment model described in this document. just so you know, these are only examples, and there are a bunch more deployment models out there 💜

A.1. Address and Prefix Management with DHCP

okay so with an edge DHCP server, every edge router that connects to a Customer Premises Equipment (CPE) device has to be a DHCP server. it hands out IPv4/IPv6 addresses to the CPEs, and optionally IPv6 prefixes through DHCPv6-PD for IPv6-capable CPEs that are routers with 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 setup needs a bunch of coordination through some backend system (the "config server" in Figure 2) 🖥️ the address prefixes on the edge interfaces should be slightly larger than what the connected CPEs need, so the overall address space gets used well 🎀

the config server has to provision the edge interface address prefixes and the DHCP parameters for every edge router. if the prefixes are too fine-grained, the routing tables across the domain in the figure get huge 😭 if they're too coarse-grained, address space goes to waste. (this is less of a worry for IPv6, but if the model includes IPv4, it's a very serious concern 💀)

there's no standard that describes algorithms for how config servers would best do this ongoing dynamic provisioning to keep routing table size and address space use optimized. no vibes, no spec 🙈

there are also no complete YANG data models a config server could use to do these actions, including telemetry of assigned addresses from those distributed DHCP servers. for example, a YANG data model for controlling DHCP server operations is still being developed [DHCP-YANG-MODEL] 🛠️

because of these problems (and some others related to the model above), the more common DHCP deployment model looks like this 👑

+------+                                      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

so in this one, dynamic provisioning changes to the edge routers get avoided by using a central DHCP server and shrinking the edge router from a DHCP server down to a 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]). the DHCP server holds the complete policies for address assignments and for the 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 edge router's routing table. those routes are then supposed to be distributed by the IGP (or BGP) inside the domain, so the CPE and LANs are 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 ✨

okay so, now we're getting to the really fun part 🦋 Using the ANI and prefix management ASAs (PM-ASAs) with GRASP, the deployment model is meant to look like this:

   |<............ 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 🎀

So the network runs an ANI domain with an ACP [RFC8994] sitting between some central device (like a router or an ANI-enabled management device) and the edge routers. ANI/ACP gives you a secure, zero-touch communication channel between the devices, and it means GRASP [RFC8990] isn't just for peer-to-peer chats either. It can do distribution/flooding too, which is honestly iconic 👑

The central devices and edge routers run software in the form of ASAs to support this document's autonomic IPv6 edge prefix management. The PM-ASAs (we'll get into them below) all work together to make up the Autonomic Prefix Management Function 💅

Edge routers can have different roles depending on the type and number of CPEs attached 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 are what 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 then uses the parameters that apply to its own role to locally configure preexisting addressing functions. Because the PM-ASA doesn't 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 a DHCP requesting router (according to [RFC8415]) for each of those interfaces, so it can request an IPv6 prefix for that interface. The router's address on the downstream interface can be another parameter from the GRASP objective. The CPEs then 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, same as in point 1.a 💜

  1. In a solution without a central DHCP server, the PM-ASA on the edge routers not only learns parameters from PrefixManager.Params, it also uses GRASP to request/negotiate actual IPv6 prefix delegation via the GRASP PrefixManager objective. More on that below. In the simplest case, these prefixes get delegated through this GRASP objective from the PM-ASA in the central device. That 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, so host CPEs can get addresses via RA/SLAAC. 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 covers both host CPEs requesting IPv6 addresses and router CPEs requesting 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 to the local DHCP servers it starts. It also needs to monitor address utilization, then request more prefixes when its existing ones run out, or return prefixes when they're no longer needed 🔥

This solution is pretty similar to the earlier IPv6 DHCP deployment model without a central DHCP server. ANI/ACP/GRASP and the PM-ASA do provide the automation that makes this approach work more easily than it can today 🙌

  1. The address pools that prefixes get allocated from don't all have to come 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 so that the PM-ASA finds and selects the objective from the closest neighboring PM-ASA, which allows aggregation to be maximized. A PM-ASA would only request further smaller prefixes when it exhausts its own pool (from the central location) and can't get further large prefixes from that central location anymore. Because the overflow prefixes are taken from a topologically nearby PM-ASA, the number of longer prefixes that have to be injected into the routing tables is limited. Topological proximity also 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. Big brain stuff 🧠✨
  2. 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, so that a hierarchy of PM-ASAs can be created and prefixes can be delegated across it 🌸
  3. In cases where CPEs are also part of the ANI domain (e.g., "managed CPEs"), GRASP extends 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 two major changes: (a) a CPE router will most likely not need to run DHCPv6-PD itself, but only DHCP address assignment, and (b) the edge routers the CPE connects to would most likely become ideal places to run a hierarchical instance of PD-ASAs, as outlined in point 1. It's giving layers, bestie 🫶

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. Thank you all, you're literally the reason this spec slaps 💖🌟

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

📦 where this page comes from