rfc8992.original   rfc8992.txt 
ANIMA WG S. Jiang, Ed. Internet Engineering Task Force (IETF) S. Jiang, Ed.
Internet-Draft Z. Du Request for Comments: 8992 Huawei Technologies Co., Ltd
Intended status: Informational Huawei Technologies Co., Ltd Category: Informational Z. Du
Expires: June 18, 2018 B. Carpenter ISSN: 2070-1721 China Mobile
B. Carpenter
Univ. of Auckland Univ. of Auckland
Q. Sun Q. Sun
China Telecom China Telecom
December 15, 2017 May 2021
Autonomic IPv6 Edge Prefix Management in Large-scale Networks Autonomic IPv6 Edge Prefix Management in Large-Scale Networks
draft-ietf-anima-prefix-management-07
Abstract Abstract
This document defines two autonomic technical objectives for IPv6 This document defines two autonomic technical objectives for IPv6
prefix management at the edge of large-scale ISP networks, with an prefix management at the edge of large-scale ISP networks, with an
extension to support IPv4 prefixes. An important purpose of the extension to support IPv4 prefixes. An important purpose of this
document is to use it for validation of the design of various document is to use it for validation of the design of various
components of the autonomic networking infrastructure. components of the Autonomic Networking Infrastructure.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on June 18, 2018. 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 Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement
3.1. Intended User and Administrator Experience . . . . . . . 4 3.1. Intended User and Administrator Experience
3.2. Analysis of Parameters and Information Involved . . . . . 5 3.2. Analysis of Parameters and Information Involved
3.2.1. Parameters each device can define for itself . . . . 5 3.2.1. Parameters Each Device Can Define for Itself
3.2.2. Information needed from network operations . . . . . 6 3.2.2. Information Needed from Network Operations
3.2.3. Comparison with current solutions . . . . . . . . . . 6 3.2.3. Comparison with Current Solutions
3.3. Interaction with other devices . . . . . . . . . . . . . 7 3.3. Interaction with Other Devices
3.3.1. Information needed from other devices . . . . . . . . 7 3.3.1. Information Needed from Other Devices
3.3.2. Monitoring, diagnostics and reporting . . . . . . . . 7 3.3.2. Monitoring, Diagnostics, and Reporting
4. Autonomic Edge Prefix Management Solution . . . . . . . . . . 8 4. Autonomic Edge Prefix Management Solution
4.1. Behaviors on prefix requesting device . . . . . . . . . . 8 4.1. Behavior of a Device Requesting a Prefix
4.2. Behaviors on prefix providing device . . . . . . . . . . 9 4.2. Behavior of a Device Providing a Prefix
4.3. Behavior after Successful Negotiation . . . . . . . . . . 10 4.3. Behavior after Successful Negotiation
4.4. Prefix logging . . . . . . . . . . . . . . . . . . . . . 10 4.4. Prefix Logging
5. Autonomic Prefix Management Objectives . . . . . . . . . . . 10 5. Autonomic Prefix Management Objectives
5.1. Edge Prefix Objective Option . . . . . . . . . . . . . . 10 5.1. Edge Prefix Objective Option
5.2. IPv4 extension . . . . . . . . . . . . . . . . . . . . . 11 5.2. IPv4 Extension
6. Prefix Management Parameters . . . . . . . . . . . . . . . . 11 6. Prefix Management Parameters
6.1. Example of Prefix Management Parameters . . . . . . . . . 12 6.1. Example of Prefix Management Parameters
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. References
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 14 9.1. Normative References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Deployment Overview
11.2. Informative References . . . . . . . . . . . . . . . . . 16 A.1. Address and Prefix Management with DHCP
Appendix A. Deployment Overview . . . . . . . . . . . . . . . . 17 A.2. Prefix Management with ANI/GRASP
A.1. Address & Prefix management with DHCP . . . . . . . . . . 17 Acknowledgements
A.2. Prefix management with ANI/GRASP . . . . . . . . . . . . 19 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The original purpose of this document was to validate the design of The original purpose of this document was to validate the design of
the Autonomic Networking Infrastructure (ANI) for a realistic use the Autonomic Networking Infrastructure (ANI) for a realistic use
case. It shows how the ANI can be applied to IP prefix delegation 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 and it outlines approaches to build a system to do this. A fully
standardized solution would require more details, so this document is standardized solution would require more details, so this document is
informational in nature. informational in nature.
This document defines two autonomic technical objectives for IPv6 This document defines two autonomic technical objectives for IPv6
prefix management in large-scale networks, with an extension to prefix management in large-scale networks, with an extension to
support IPv4 prefixes. The background to Autonomic Networking (AN) support IPv4 prefixes. The background to Autonomic Networking is
is described in [RFC7575] and [RFC7576]. The GeneRic Autonomic described in [RFC7575] and [RFC7576]. The GeneRic Autonomic
Signaling Protocol (GRASP) is specified by [I-D.ietf-anima-grasp] and Signaling Protocol (GRASP) is specified by [RFC8990] and can make use
can make use of the proposed technical objectives to provide a of the technical objectives to provide a solution for autonomic
solution for autonomic prefix management. An important purpose of prefix management. An important purpose of the present document is
the present document is to use it for validation of the design of to use it for validation of the design of GRASP and other components
GRASP and other components of the autonomic networking infrastructure of the ANI as described in [RFC8993].
described in [I-D.ietf-anima-reference-model].
This document is not a complete functional specification of an This document is not a complete functional specification of an
autonomic prefix management system and it does not describe all autonomic prefix management system, and it does not describe all
detailed aspects of the GRASP objective parameters and Autonomic detailed aspects of the GRASP objective parameters and Autonomic
Service Agent (ASA) procedures necessary to build a complete system. Service Agent (ASA) procedures necessary to build a complete system.
Instead, it describes the architectural framework utilizing the Instead, it describes the architectural framework utilizing the
components of the ANI, outlines the different deployment options and components of the ANI, outlines the different deployment options and
aspects, and defines GRASP objectives for use in building the system. aspects, and defines GRASP objectives for use in building the system.
It also provides some basic parameter examples. It also provides some basic parameter examples.
This document is not intended to solve all cases of IPv6 prefix This document is not intended to solve all cases of IPv6 prefix
management. In fact, it assumes that the network's main management. In fact, it assumes that the network's main
infrastructure elements already have addresses and prefixes. The infrastructure elements already have addresses and prefixes. This
document is dedicated to how to make IPv6 prefix management at the document is dedicated to how to make IPv6 prefix management at the
edges of large-scale networks as autonomic as possible. It is edges of large-scale networks as autonomic as possible. It is
specifically written for service provider (ISP) networks. Although specifically written for Internet Service Provider (ISP) networks.
there are similarities between ISPs and large enterprise networks, Although there are similarities between ISPs and large enterprise
the requirements for the two use cases differ. In any case, the networks, the requirements for the two use cases differ. In any
scope of the solution is expected to be limited, like any autonomic case, the scope of the solution is expected to be limited, like any
network, to a single management domain. Autonomic Network, to a single management domain.
However, the solution is designed in a general way. Its use for a However, the solution is designed in a general way. Its use for a
broader scope than edge prefixes, including some or all broader scope than edge prefixes, including some or all
infrastructure prefixes, is left for future discussion. infrastructure prefixes, is left for future discussion.
A complete solution has many aspects that are not discussed here. A complete solution has many aspects that are not discussed here.
Once prefixes have been assigned to routers, they need to be Once prefixes have been assigned to routers, they need to be
communicated to the routing system as they are brought into use. communicated to the routing system as they are brought into use.
Similarly, when prefixes are released, they need to be removed from Similarly, when prefixes are released, they need to be removed from
the routing system. Different operators may have different policies the routing system. Different operators may have different policies
about prefix lifetimes, and they may prefer to have centralized or regarding prefix lifetimes, and they may prefer to have centralized
distributed pools of spare prefixes. In an autonomic network, these or distributed pools of spare prefixes. In an Autonomic Network,
are properties decided by the design of the relevant ASAs. The GRASP these are properties decided upon by the design of the relevant ASAs.
objectives are simply building blocks. The GRASP objectives are simply building blocks.
A particular risk of distributed prefix allocation in large networks A particular risk of distributed prefix allocation in large networks
is that over time, it might lead to fragmentation of the address is that over time, it might lead to fragmentation of the address
space and an undesirable increase in the interior routing protocol space and an undesirable increase in the size of the interior routing
tables. The extent of this risk depends on the algorithms and protocol tables. The extent of this risk depends on the algorithms
policies used by the ASAs. Mitigating this risk might even become an and policies used by the ASAs. Mitigating this risk might even
autonomic function in itself. become an autonomic function in itself.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses terminology defined in [RFC7575]. This document uses terminology defined in [RFC7575].
3. Problem Statement 3. Problem Statement
The autonomic networking use case considered here is autonomic IPv6 The Autonomic Networking use case considered here is autonomic IPv6
prefix management at the edge of large-scale ISP networks. prefix management at the edge of large-scale ISP networks.
Although DHCPv6 Prefix Delegation [RFC3633] supports automated Although DHCPv6-PD (DHCPv6 Prefix Delegation) [RFC8415] supports
delegation of IPv6 prefixes from one router to another, prefix automated delegation of IPv6 prefixes from one router to another,
management still largely depends on human planning. In other words, prefix management still largely depends on human planning. In other
there is no basic information or policy to support autonomic words, there is no basic information or policy to support autonomic
decisions on the prefix length that each router should request or be decisions on the prefix length that each router should request or be
delegated, according to its role in the network. Roles could be delegated, according to its role in the network. Roles could be
defined separately for individual devices or could be generic (edge defined separately for individual devices or could be generic (edge
router, interior router, etc.). Furthermore, IPv6 prefix management router, interior router, etc.). Furthermore, IPv6 prefix management
by humans tends to be rigid and static after initial planning. by humans tends to be rigid and static after initial planning.
The problem to be solved by autonomic networking is how to The problem to be solved by Autonomic Networking is how to
dynamically manage IPv6 address space in large-scale networks, so dynamically manage IPv6 address space in large-scale networks, so
that IPv6 addresses can be used efficiently. Here, we limit the that IPv6 addresses can be used efficiently. Here, we limit the
problem to assignment of prefixes at the edge of the network, close problem to assignment of prefixes at the edge of the network, close
to access routers that support individual fixed-line subscribers, to access routers that support individual fixed-line subscribers,
mobile customers, and corporate customers. We assume that the core mobile customers, and corporate customers. We assume that the core
infrastructure of the network has already been established with infrastructure of the network has already been established with
appropriately assigned prefixes. The AN approach discussed in this appropriately assigned prefixes. The Autonomic Networking approach
document is based on the assumption that there is a generic discovery discussed in this document is based on the assumption that there is a
and negotiation protocol that enables direct negotiation between generic discovery and negotiation protocol that enables direct
intelligent IP routers. GRASP [I-D.ietf-anima-grasp] is intended to negotiation between intelligent IP routers. GRASP [RFC8990] is
be such a protocol. intended to be such a protocol.
3.1. Intended User and Administrator Experience 3.1. Intended User and Administrator Experience
The intended experience is, for the administrators of a large-scale 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, 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 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 added and removed and as customers of all kinds join and leave the
network. In the ideal scenario, the administrators only have to network. In the ideal scenario, the administrators only have to
specify a single IPv6 prefix for the whole network and the initial specify a single IPv6 prefix for the whole network and the initial
prefix length for each device role. As far as users are concerned, prefix length for each device role. As far as users are concerned,
IPv6 prefix assignment would occur exactly as it does in any other IPv6 prefix assignment would occur exactly as it does in any other
network. network.
The actual prefix usage needs to be logged for potential offline The actual prefix usage needs to be logged for potential offline
management operations including audit and security incident tracing. management operations, including audit and security incident tracing.
3.2. Analysis of Parameters and Information Involved 3.2. Analysis of Parameters and Information Involved
For specific purposes of address management, a few parameters are For specific purposes of address management, each edge device will
involved on each edge device (some of them can be pre-configured implement several parameters. (Some of them can be preconfigured
before they are connected). They include: before they are connected.) They include the following:
o Identity, authentication and authorization of this device. This * Identity, authentication, and authorization of this device. This
is expected to use the autonomic networking secure bootstrap is expected to use the Autonomic Networking secure bootstrap
process [I-D.ietf-anima-bootstrapping-keyinfra], following which process [RFC8995], following which the device could safely take
the device could safely take part in autonomic operations. part in autonomic operations.
o Role of this device. Some example roles are discussed in * Role of this device. Some example roles are discussed in
Section 6.1. Section 6.1.
o An IPv6 prefix length for this device. * An IPv6 prefix length for this device.
o An IPv6 prefix that is assigned to this device and its downstream * An IPv6 prefix that is assigned to this device and its downstream
devices. devices.
A few parameters are involved in the network as a whole. They are: The network as a whole will implement the following parameters:
o Identity of a trust anchor, which is a certification authority * Identity of a trust anchor, which is a certification authority
(CA) maintained by the network administrators, used during the (CA) maintained by the network administrators, used during the
secure bootstrap process. secure bootstrap process.
o Total IPv6 address space available for edge devices. It is a pool * Total IPv6 address space available for edge devices. It is a pool
of one or several IPv6 prefixes. of one or several IPv6 prefixes.
o The initial prefix length for each device role. * The initial prefix length for each device role.
3.2.1. Parameters each device can define for itself 3.2.1. Parameters Each Device Can Define for Itself
This section identifies those of the above parameters that do not This section identifies those of the above parameters that do not
need external information in order for the devices concerned to set need external information in order for the devices concerned to set
them to a reasonable default value after bootstrap or after a network them to a reasonable default value after bootstrap or after a network
disruption. There are few of these: disruption. They are as follows:
o Default role of this device. * Default role of this device.
o Default IPv6 prefix length for this device. * Default IPv6 prefix length for this device.
o Cryptographic identity of this device, as needed for secure * Cryptographic identity of this device, as needed for secure
bootstrapping [I-D.ietf-anima-bootstrapping-keyinfra]. bootstrapping [RFC8995].
The device may be shipped from the manufacturer with pre-configured The device may be shipped from the manufacturer with a preconfigured
role and default prefix length, which could be modified by an role and default prefix length, which could be modified by an
autonomic mechanism. Its cryptographic identity will be installed by autonomic mechanism. Its cryptographic identity will be installed by
its manufacturer. its manufacturer.
3.2.2. Information needed from network operations 3.2.2. Information Needed from Network Operations
This section identifies those parameters that might need operational This section identifies those parameters that might need operational
input in order for the devices concerned to set them to a non-default input in order for the devices concerned to set them to a non-default
value. value.
o Non-default value for the IPv6 prefix length for this device. * Non-default value for the IPv6 prefix length for this device.
This needs to be decided based on the role of this device. This needs to be decided based on the role of this device.
o The initial prefix length for each device role. * The initial prefix length for each device role.
o Whether to allow the device to request more address space. * Whether to allow the device to request more address space.
o The policy when to request more address space, for example, if the * The policy regarding when to request more address space -- for
address usage reaches a certain limit or percentage. example, if the address usage reaches a certain limit or
percentage.
3.2.3. Comparison with current solutions 3.2.3. Comparison with Current Solutions
This section briefly compares the above use case with current This section briefly compares the above use case with current
solutions. Currently, the address management is still largely solutions. Currently, the address management is still largely
dependent on human planning. It is rigid and static after initial dependent on human planning. It is rigid and static after initial
planning. Address requests will fail if the configured address space planning. Address requests will fail if the configured address space
is used up. is used up.
Some autonomic and dynamic address management functions may be Some autonomic and dynamic address management functions may be
achievable by extending the existing protocols, for example, achievable by extending the existing protocols -- for example,
extending DHCPv6-PD (DHCPv6 Prefix Delegation, [RFC3633]) to request extending DHCPv6-PD [RFC8415] to request IPv6 prefixes according to
IPv6 prefixes according to the device role. However, defining the device role. However, defining uniform device roles may not be a
uniform device roles may not be a practical task. Some functions are practical task, as some functions cannot be configured on the basis
not suitable to be achieved by any existing protocols. of role using existing prefix delegation protocols.
Using a generic autonomic discovery and negotiation protocol instead Using a generic autonomic discovery and negotiation protocol instead
of specific solutions has the advantage that additional parameters of specific solutions has the advantage that additional parameters
can be included in the autonomic solution without creating new can be included in the autonomic solution without creating new
mechanisms. This is the principal argument for a generic approach. mechanisms. This is the principal argument for a generic approach.
3.3. Interaction with other devices 3.3. Interaction with Other Devices
3.3.1. Information needed from other devices 3.3.1. Information Needed from Other Devices
This section identifies those of the above parameters that need This section identifies those of the above parameters that need
external information from neighbor devices (including the upstream external information from neighbor devices (including the upstream
devices). In many cases, two-way dialogue with neighbor devices is devices). In many cases, two-way dialogue with neighbor devices is
needed to set or optimize them. needed to set or optimize them.
o Identity of a trust anchor. * Information regarding the identity of a trust anchor is needed.
o The device will need to discover a device, from which it can * The device will need to discover another device from which it can
acquire IPv6 address space. acquire IPv6 address space.
o The initial prefix length for each device role, particularly for * Information regarding the initial prefix length for the role of
its own downstream devices. each device is needed, particularly for its own downstream
devices.
o The default value of the IPv6 prefix length may be overridden by a * The default value of the IPv6 prefix length may be overridden by a
non-default value. non-default value.
o The device will need to request and acquire one or more IPv6 * The device will need to request and acquire one or more IPv6
prefixes that can be assigned to this device and its downstream prefixes that can be assigned to this device and its downstream
devices. devices.
o The device may respond to prefix delegation requests from its * The device may respond to prefix delegation requests from its
downstream devices. downstream devices.
o The device may require to be assigned more IPv6 address space, if * The device may require the assignment of more IPv6 address space
it used up its assigned IPv6 address space. if it used up its assigned IPv6 address space.
3.3.2. Monitoring, diagnostics and reporting 3.3.2. Monitoring, Diagnostics, and Reporting
This section discusses what role devices should play in monitoring, This section discusses what role devices should play in monitoring,
fault diagnosis, and reporting. fault diagnosis, and reporting.
o The actual address assignments need to be logged for potential * The actual address assignments need to be logged for potential
offline management operations. offline management operations.
o In general, the usage situation of address space should be * In general, the usage situation regarding address space should be
reported to the network administrators, in an abstract way, for reported to the network administrators in an abstract way -- for
example, statistics or visualized report. example, statistics or a visualized report.
o A forecast of address exhaustion should be reported. * A forecast of address exhaustion should be reported.
4. Autonomic Edge Prefix Management Solution 4. Autonomic Edge Prefix Management Solution
This section introduces the building blocks for an autonomic edge This section introduces the building blocks for an autonomic edge
prefix management solution. As noted in Section 1, this is not a prefix management solution. As noted in Section 1, this is not a
complete description of a solution, which will depend on the detailed complete description of a solution, which will depend on the detailed
design of the relevant Autonomic Service Agents. It uses the generic design of the relevant Autonomic Service Agents (ASAs). It uses the
discovery and negotiation protocol defined by [I-D.ietf-anima-grasp]. generic discovery and negotiation protocol defined by [RFC8990]. The
The relevant GRASP objectives are defined in Section 5. relevant GRASP objectives are defined in Section 5.
The procedures described below are carried out by an Autonomic The procedures described below are carried out by an ASA in each
Service Agent (ASA) in each device that participates in the solution. device that participates in the solution. We will refer to this as
We will refer to this as the PrefixManager ASA. the PrefixManager ASA.
4.1. Behaviors on prefix requesting device 4.1. Behavior of a Device Requesting a Prefix
If the device containing a PrefixManager ASA has used up its address If the device containing a PrefixManager ASA has used up its address
pool, it can request more space according to its requirements. It pool, it can request more space according to its requirements. It
should decide the length of the requested prefix and request it by should decide the length of the requested prefix and request it via
the mechanism described in Section 6. Note that although the the mechanism described in Section 6. Note that although the
device's role may define certain default allocation lengths, those device's role may define certain default allocation lengths, those
defaults might be changed dynamically, and the device might request defaults might be changed dynamically, and the device might request
more, or less, address space due to some local operational heuristic. more, or less, address space due to some local operational heuristic.
A PrefixManager ASA that needs additional address space should A PrefixManager ASA that needs additional address space should
firstly discover peers that may be able to provide extra address firstly discover peers that may be able to provide extra address
space. The ASA should send out a GRASP Discovery message that space. The ASA should send out a GRASP Discovery message that
contains a PrefixManager Objective option (see Section 5.1) in order contains a PrefixManager Objective option (see Section 2 of [RFC8650]
to discover peers also supporting that option. Then it should choose and Section 5.1) in order to discover peers also supporting that
one such peer, most likely the first to respond. option. Then, it should choose one such peer, most likely the first
to respond.
If the GRASP discovery Response message carries a divert option If the GRASP Discovery Response message carries a Divert option
pointing to an off-link PrefixManager ASA, the requesting ASA may pointing to an off-link PrefixManager ASA, the requesting ASA may
initiate negotiation with that ASA diverted device to find out initiate negotiation with that ASA-diverted device to find out
whether it can provide the requested length prefix. whether it can provide the requested length of the prefix.
In any case, the requesting ASA will act as a GRASP negotiation In any case, the requesting ASA will act as a GRASP negotiation
initiator by sending a GRASP Request message with a PrefixManager initiator by sending a GRASP Request message with a PrefixManager
Objective option. The ASA indicates in this option the length of the Objective option. The ASA indicates in this option the length of the
requested prefix. This starts a GRASP negotiation process. requested prefix. This starts a GRASP negotiation process.
During the subsequent negotiation, the ASA will decide at each step During the subsequent negotiation, the ASA will decide at each step
whether to accept the offered prefix. That decision, and the whether to accept the offered prefix. That decision, and the
decision to end negotiation, is an implementation choice. decision to end the negotiation, are implementation choices.
The ASA could alternatively initiate rapid mode GRASP discovery with The ASA could alternatively initiate GRASP discovery in rapid mode
an embedded negotiation request, if it is implemented. with an embedded negotiation request, if it is implemented.
4.2. Behaviors on prefix providing device 4.2. Behavior of a Device Providing a Prefix
At least one device on the network must be configured with the At least one device on the network must be configured with the
initial pool of available prefixes mentioned in Section 3.2. Apart initial pool of available prefixes mentioned in Section 3.2. Apart
from that requirement, any device may act as a prefix providing from that requirement, any device may act as a provider of prefixes.
device.
A device that receives a Discovery message with a PrefixManager A device that receives a Discovery message with a PrefixManager
Objective option should respond with a GRASP Response message if it Objective option should respond with a GRASP Response message if it
contains a PrefixManager ASA. Further details of the discovery contains a PrefixManager ASA. Further details of the discovery
process are described in [I-D.ietf-anima-grasp]. When this ASA process are described in [RFC8990]. When this ASA receives a
receives a subsequent Request message, it should conduct a GRASP subsequent Request message, it should conduct a GRASP negotiation
negotiation sequence, using Negotiate, Confirm-waiting, and sequence, using Negotiate, Confirm Waiting, and Negotiation End
Negotiation-ending messages as appropriate. The Negotiate messages messages as appropriate. The Negotiate messages carry a
carry a PrefixManager Objective option, which will indicate the PrefixManager Objective option, which will indicate the prefix and
prefix and its length offered to the requesting ASA. As described in its length offered to the requesting ASA. As described in [RFC8990],
[I-D.ietf-anima-grasp], negotiation will continue until either end negotiation will continue until either end stops it with a
stops it with a Negotiation-ending message. If the negotiation Negotiation End message. If the negotiation succeeds, the ASA that
succeeds, the prefix providing ASA will remove the negotiated prefix provides the prefix will remove the negotiated prefix from its pool,
from its pool, and the requesting ASA will add it. If the and the requesting ASA will add it. If the negotiation fails, the
negotiation fails, the party sending the Negotiation-ending message party sending the Negotiation End message may include an error code
may include an error code string. string.
During the negotiation, the ASA will decide at each step how large a During the negotiation, the ASA will decide at each step how large a
prefix to offer. That decision, and the decision to end negotiation, prefix to offer. That decision, and the decision to end the
is an implementation choice. negotiation, are implementation choices.
The ASA could alternatively negotiate in response to rapid mode GRASP The ASA could alternatively negotiate in response to GRASP discovery
discovery, if it is implemented. in rapid mode, if it is implemented.
This specification is independent of whether the PrefixManager ASAs This specification is independent of whether the PrefixManager ASAs
are all embedded in routers, but that would be a rather natural are all embedded in routers, but that would be a rather natural
scenario. In a hierarchical network topology, a given router scenario. In a hierarchical network topology, a given router
typically provide prefixes for routers below it in the hierarchy, and typically provides prefixes for routers below it in the hierarchy,
it is also likely to contain the first PrefixManager ASA discovered and it is also likely to contain the first PrefixManager ASA
by those downstream routers. However, the GRASP discovery model, discovered by those downstream routers. However, the GRASP discovery
including its Redirect feature, means that this is not an exclusive model, including its redirection feature, means that this is not an
scenario, and a downstream PrefixManager ASA could negotiate a new exclusive scenario, and a downstream PrefixManager ASA could
prefix with a device other than its upstream router. negotiate a new prefix with a device other than its upstream router.
A resource shortage may cause the gateway router to request more A resource shortage may cause the gateway router to request more
resource in turn from its own upstream device. This would be another resources in turn from its own upstream device. This would be
independent GRASP discovery and negotiation process. During the another independent GRASP discovery and negotiation process. During
processing time, the gateway router should send a Confirm-waiting the processing time, the gateway router should send a Confirm Waiting
Message to the initial requesting router, to extend its timeout. message to the initial requesting router, to extend its timeout.
When the new resource becomes available, the gateway router responds When the new resource becomes available, the gateway router responds
with a GRASP Negotiate message with a prefix length matching the with a GRASP Negotiate message with a prefix length matching the
request. request.
The algorithm to choose which prefixes to assign on the prefix The algorithm used to choose which prefixes to assign on the devices
providing devices is an implementation choice. that provide prefixes is an implementation choice.
4.3. Behavior after Successful Negotiation 4.3. Behavior after Successful Negotiation
Upon receiving a GRASP Negotiation-ending message that indicates that Upon receiving a GRASP Negotiation End message that indicates that an
an acceptable prefix length is available, the requesting device may acceptable prefix length is available, the requesting device may use
use the negotiated prefix without further messages. the negotiated prefix without further messages.
There are use cases where the ANI/GRASP based prefix management There are use cases where the ANI/GRASP-based prefix management
approach can work together with DHCPv6-PD [RFC3633] as a complement. approach can work together with DHCPv6-PD [RFC8415] as a complement.
For example, the ANI/GRASP based method can be used intra-domain, For example, the ANI/GRASP-based method can be used intra-domain,
while the DHCPv6-PD method works inter-domain (i.e., across an while the DHCPv6-PD method works inter-domain (i.e., across an
administrative boundary). Also, ANI/GRASP can be used inside the administrative boundary). Also, ANI/GRASP can be used inside the
domain, and DHCP/DHCPv6-PD be used on the edge of the domain to domain, and DHCP/DHCPv6-PD can be used on the edge of the domain to
client (non-ANI devices). Another similar use case would be ANI/ clients (non-ANI devices). Another similar use case would be ANI/
GRASP inside the domain, with RADIUS [RFC2865] providing prefixes to GRASP inside the domain, with RADIUS [RFC2865] providing prefixes to
client devices. client devices.
4.4. Prefix logging 4.4. Prefix Logging
Within the autonomic prefix management, all the prefix assignment is Within the autonomic prefix management system, all prefix assignments
done by devices without human intervention. It may be required to are done by devices without human intervention. It may be required
record all the prefix assignment history, for example to detect or that all prefix assignment history be recorded -- for example, to
trace lost prefixes after outages, or to meet legal requirements. detect or trace lost prefixes after outages or to meet legal
However, the logging and reporting process is out of scope for this requirements. However, the logging and reporting process is out of
document. scope for this document.
5. Autonomic Prefix Management Objectives 5. Autonomic Prefix Management Objectives
This section defines the GRASP technical objective options that are This section defines the GRASP technical objective options that are
used to support autonomic prefix management. used to support autonomic prefix management.
5.1. Edge Prefix Objective Option 5.1. Edge Prefix Objective Option
The PrefixManager Objective option is a GRASP objective option The PrefixManager Objective option is a GRASP Objective option
conforming to [I-D.ietf-anima-grasp]. Its name is "PrefixManager" conforming to the GRASP specification [RFC8990]. Its name is
(see Section 8) and it carries the following data items as its value: "PrefixManager" (see Section 8), and it carries the following data
the prefix length, and the actual prefix bits. Since GRASP is based items as its value: the prefix length and the actual prefix bits.
on CBOR (Concise Binary Object Representation [RFC7049]), the format Since GRASP is based on CBOR (Concise Binary Object Representation)
of the PrefixManager Objective option is described as follows in CBOR [RFC8949], the format of the PrefixManager Objective option is
data definition language (CDDL) [I-D.ietf-cbor-cddl]: described in the Concise Data Definition Language (CDDL) [RFC8610] as
follows:
objective = ["PrefixManager", objective-flags, loop-count, objective = ["PrefixManager", objective-flags, loop-count,
[length, ?prefix]] [length, ?prefix]]
loop-count = 0..255 ; as in the GRASP specification loop-count = 0..255 ; as in the GRASP specification
objective-flags /= ; as in the GRASP specification objective-flags /= ; as in the GRASP specification
length = 0..128 ; requested or offered prefix length length = 0..128 ; requested or offered prefix length
prefix = bytes .size 16 ; offered prefix in binary format prefix = bytes .size 16 ; offered prefix in binary format
The use of the 'dry run' mode of GRASP is NOT RECOMMENDED for this 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 objective, because it would require both ASAs to store state
the corresponding negotiation, to no real benefit - the requesting information about the corresponding negotiation, to no real benefit
ASA cannot base any decisions on the result of a successful dry run -- the requesting ASA cannot base any decisions on the result of a
negotiation. successful dry-run negotiation.
5.2. IPv4 extension 5.2. IPv4 Extension
This section presents an extended version of the PrefixManager This section presents an extended version of the PrefixManager
Objective that supports IPv4 by adding an extra flag: objective that supports IPv4 by adding an extra flag:
objective = ["PrefixManager", objective-flags, loop-count, prefval] objective = ["PrefixManager", objective-flags, loop-count, prefval]
loop-count = 0..255 ; as in the GRASP specification loop-count = 0..255 ; as in the GRASP specification
objective-flags /= ; as in the GRASP specification objective-flags /= ; as in the GRASP specification
prefval /= pref6val prefval /= pref6val
pref6val = [version6, length, ?prefix] pref6val = [version6, length, ?prefix]
version6 = 6 version6 = 6
length = 0..128 ; requested or offered prefix length length = 0..128 ; requested or offered prefix length
skipping to change at page 11, line 44 skipping to change at line 510
prefval /= pref4val prefval /= pref4val
pref4val = [version4, length4, ?prefix4] pref4val = [version4, length4, ?prefix4]
version4 = 4 version4 = 4
length4 = 0..32 ; requested or offered prefix length length4 = 0..32 ; requested or offered prefix length
prefix4 = bytes .size 4 ; offered prefix in binary format prefix4 = bytes .size 4 ; offered prefix in binary format
Prefix and address management for IPv4 is considerably more difficult Prefix and address management for IPv4 is considerably more difficult
than for IPv6, due to the prevalence of NAT, ambiguous addresses than for IPv6, due to the prevalence of NAT, ambiguous addresses
[RFC1918], and address sharing [RFC6346]. These complexities might [RFC1918], and address sharing [RFC6346]. These complexities might
require further extending the objective with additional fields which require further extending the objective with additional fields that
are not defined by this document. are not defined by this document.
6. Prefix Management Parameters 6. Prefix Management Parameters
An implementation of a prefix manager MUST include default settings An implementation of a prefix manager MUST include default settings
of all necessary parameters. However, within a single administrative of all necessary parameters. However, within a single administrative
domain, the network operator MAY change default parameters for all domain, the network operator MAY change default parameters for all
devices with a certain role. Thus it would be possible to apply an devices with a certain role. Thus, it would be possible to apply an
intended policy for every device in a simple way, without traditional intended policy for every device in a simple way, without traditional
configuration files. As noted in Section 4.1, individual autonomic configuration files. As noted in Section 4.1, individual autonomic
devices may also change their own behavior dynamically. devices may also change their own behavior dynamically.
For example, the network operator could change the default prefix For example, the network operator could change the default prefix
length for each type of role. A prefix management parameters length for each type of role. A prefix management parameters
objective, which contains mapping information of device roles and objective, which contains mapping information of device roles and
their default prefix lengths, MAY be flooded in the network, through their default prefix lengths, MAY be flooded in the network, through
the Autonomic Control Plane (ACP) the Autonomic Control Plane (ACP) [RFC8994]. The objective is
[I-D.ietf-anima-autonomic-control-plane]. The objective is defined defined in CDDL as follows:
in CDDL as follows:
objective = ["PrefixManager.Params", objective-flags, any] objective = ["PrefixManager.Params", objective-flags, any]
loop-count = 0..255 ; as in the GRASP specification loop-count = 0..255 ; as in the GRASP specification
objective-flags /= ; as in the GRASP specification objective-flags /= ; as in the GRASP specification
The 'any' object would be the relevant parameter definitions (such as The "any" object would be the relevant parameter definitions (such as
the example below) transmitted as a CBOR object in an appropriate the example below) transmitted as a CBOR object in an appropriate
format. format.
This could be flooded to all nodes, and any PrefixManager ASA that 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 did not receive it for some reason could obtain a copy using GRASP
unicast synchronization. Upon receiving the prefix management unicast synchronization. Upon receiving the prefix management
parameters, every device can decide its default prefix length by parameters, every device can decide its default prefix length by
matching its own role. matching its own role.
6.1. Example of Prefix Management Parameters 6.1. Example of Prefix Management Parameters
The parameters comprise mapping information of device roles and their The parameters comprise mapping information of device roles and their
default prefix lengths in an autonomic domain. For example, suppose default prefix lengths in an autonomic domain. For example, suppose
an IPRAN (IP Radio Access Network) operator wants to configure the an IPRAN (IP Radio Access Network) operator wants to configure the
prefix length of Radio Network Controller Site Gateway (RSG) as 34, prefix length of a Radio Network Controller Site Gateway (RSG) as 34,
the prefix length of Aggregation Site Gateway (ASG) as 44, and the the prefix length of an Aggregation Site Gateway (ASG) as 44, and the
prefix length of Cell Site Gateway (CSG) as 56. This could be prefix length of a Cell Site Gateway (CSG) as 56. This could be
described in the value of the PrefixManager.Params objective as: described in the value of the PrefixManager.Params objective as:
[ [
[["role", "RSG"],["prefix_length", 34]], [["role", "RSG"],["prefix_length", 34]],
[["role", "ASG"],["prefix_length", 44]], [["role", "ASG"],["prefix_length", 44]],
[["role", "CSG"],["prefix_length", 56]] [["role", "CSG"],["prefix_length", 56]]
] ]
This example is expressed in JSON notation [RFC7159], which is easy This example is expressed in JSON [RFC8259], which is easy to
to represent in CBOR. represent in CBOR.
An alternative would be to express the parameters in YANG [RFC7950] An alternative would be to express the parameters in YANG [RFC7950]
using the YANG-to-CBOR mapping [I-D.ietf-core-yang-cbor]. using the YANG-to-CBOR mapping [CORE-YANG-CBOR].
For clarity, the background of the example is introduced below, which For clarity, the background of the example is introduced below and
can also be regarded as a use case of the mechanism proposed in this can also be regarded as a use case for the mechanism defined in this
document. document.
An IPRAN network is used for mobile backhaul, including radio An IPRAN is used for mobile backhaul, including radio stations, RNCs
stations, RNC (in 3G) or the packet core (in LTE), and the IP network (Radio Network Controllers) (in 3G) or the packet core (in LTE), and
between them as shown in Figure 1. The eNB (Evolved Node B), RNC the IP network between them, as shown in Figure 1. The eNB (Evolved
(Radio Network Controller), SGW (Service Gateway), and MME (Mobility Node B) entities, the RNC, the SGW (Serving Gateway), and the MME
Management Entity) are mobile network entities defined in 3GPP. The (Mobility Management Entity) are mobile network entities defined in
CSG, ASG, and RSG are entities defined in the IPRAN solution. 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 The IPRAN topology shown in Figure 1 includes Ring1, which is the
circle following ASG1->RSG1->RSG2->ASG2->ASG1, Ring2 following circle following ASG1->RSG1->RSG2->ASG2->ASG1; Ring2, following
CSG1->ASG1->ASG2->CSG2->CSG1, and Ring3 following CSG1->ASG1->ASG2->CSG2->CSG1; and Ring3, following
CSG3->ASG1->ASG2->CSG3. In a real deployment of IPRAN, there may be CSG3->ASG1->ASG2->CSG3. In a real deployment of an IPRAN, there may
more stations, rings, and routers in the topology, and normally the be more stations, rings, and routers in the topology, and normally
network is highly dependent on human design and configuration, which the network is highly dependent on human design and configuration,
is neither flexible nor cost-effective. which is neither flexible nor cost-effective.
+------+ +------+ +------+ +------+
| eNB1 |---| CSG1 |\ | eNB1 |---| CSG1 |\
+------+ +------+ \ +-------+ +------+ +-------+ +------+ +------+ \ +-------+ +------+ +-------+
| \ | ASG1 |-------| RSG1 |-----------|SGW/MME| | \ | ASG1 |-------| RSG1 |-----------|SGW/MME|
| Ring2 +-------+ +------+ \ /+-------+ | Ring2 +-------+ +------+ \ /+-------+
+------+ +------+ / | | \ / +------+ +------+ / | | \ /
| eNB2 |---| CSG2 | \ / | Ring1 | \/ | eNB2 |---| CSG2 | \ / | Ring1 | \/
+------+ +------+ \ Ring3| | /\ +------+ +------+ \ Ring3| | /\
/ \ | | / \ / \ | | / \
+------+ +------+ / \ +-------+ +------+/ \+-------+ +------+ +------+ / \ +-------+ +------+/ \+-------+
| eNB3 |---| CSG3 |--------| ASG2 |------| RSG2 |---------| RNC | | eNB3 |---| CSG3 |--------| ASG2 |------| RSG2 |---------| RNC |
+------+ +------+ +-------+ +------+ +-------+ +------+ +------+ +-------+ +------+ +-------+
Figure 1: IPRAN Topology Example Figure 1: IPRAN Topology Example
If ANI/GRASP is supported in the IPRAN network, the network nodes If ANI/GRASP is supported in the IPRAN, the network nodes should be
should be able to negotiate with each other, and make some autonomic able to negotiate with each other and make some autonomic decisions
decisions according to their own status and the information collected according to their own status and the information collected from the
from the network. The Prefix Management Parameters should be part of network. The prefix management parameters should be part of the
the information they communicate. information they communicate.
The routers should know the role of their neighbors, the default 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 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 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 prefixes from an ASG. In each request, the ASG/CSG should indicate
the required prefix length, or its role, which implies what length it the required prefix length, or its role, which implies what length it
needs by default. needs by default.
7. Security Considerations 7. Security Considerations
Relevant security issues are discussed in [I-D.ietf-anima-grasp]. Relevant security issues are discussed in [RFC8990]. The preferred
The preferred security model is that devices are trusted following security model is that devices are trusted following the secure
the secure bootstrap procedure bootstrap procedure [RFC8995] and that a secure Autonomic Control
[I-D.ietf-anima-bootstrapping-keyinfra] and that a secure Autonomic Plane (ACP) [RFC8994] is in place.
Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane] is in
place.
It is RECOMMENDED that DHCPv6-PD, if used, should be operated using It is RECOMMENDED that DHCPv6-PD, if used, should be implemented
DHCPv6 authentication or Secure DHCPv6. using DHCPv6 authentication or Secure DHCPv6.
8. IANA Considerations 8. IANA Considerations
This document defines two new GRASP Objective Option names, This document defines two new GRASP Objective option names:
"PrefixManager" and "PrefixManager.Params". The IANA is requested to "PrefixManager" and "PrefixManager.Params". The IANA has added these
add these to the GRASP Objective Names Table registry defined by to the "GRASP Objective Names" registry defined by [RFC8990].
[I-D.ietf-anima-grasp] (if approved).
9. 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.
10. Change log [RFC Editor: Please remove]
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.
11. References
11.1. Normative References
[I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-12 (work in progress), October 2017.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-09 (work in progress), October 2017.
[I-D.ietf-anima-grasp] 9. References
Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017.
[I-D.ietf-cbor-cddl] 9.1. Normative References
Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to
express CBOR data structures", draft-ietf-cbor-cddl-00
(work in progress), July 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003,
<https://www.rfc-editor.org/info/rfc3633>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References [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>.
[I-D.ietf-anima-reference-model] [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Richardson, M., Jiang, S., Lemon, T., and T. Winters,
Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
Reference Model for Autonomic Networking", draft-ietf- RFC 8415, DOI 10.17487/RFC8415, November 2018,
anima-reference-model-05 (work in progress), October 2017. <https://www.rfc-editor.org/info/rfc8415>.
[I-D.ietf-core-yang-cbor] [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. Definition Language (CDDL): A Notational Convention to
Minaburo, "CBOR Encoding of Data Modeled with YANG", Express Concise Binary Object Representation (CBOR) and
draft-ietf-core-yang-cbor-05 (work in progress), August JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
2017. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[I-D.liu-dhc-dhcp-yang-model] [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
Liu, B., Lou, K., and C. Chen, "Yang Data Model for DHCP Autonomic Signaling Protocol (GRASP)", RFC 8990,
Protocol", draft-liu-dhc-dhcp-yang-model-06 (work in DOI 10.17487/RFC8990, May 2021,
progress), March 2017. <https://www.rfc-editor.org/info/rfc8990>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
and E. Lear, "Address Allocation for Private Internets", Autonomic Control Plane (ACP)", RFC 8994,
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/info/rfc1918>. <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, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>. <https://www.rfc-editor.org/info/rfc2865>.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, DOI 10.17487/RFC3046, January 2001, RFC 3046, DOI 10.17487/RFC3046, January 2001,
<https://www.rfc-editor.org/info/rfc3046>. <https://www.rfc-editor.org/info/rfc3046>.
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221,
DOI 10.17487/RFC6221, May 2011, DOI 10.17487/RFC6221, May 2011,
<https://www.rfc-editor.org/info/rfc6221>. <https://www.rfc-editor.org/info/rfc6221>.
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to
the IPv4 Address Shortage", RFC 6346, the IPv4 Address Shortage", RFC 6346,
DOI 10.17487/RFC6346, August 2011, DOI 10.17487/RFC6346, August 2011,
<https://www.rfc-editor.org/info/rfc6346>. <https://www.rfc-editor.org/info/rfc6346>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap
Analysis for Autonomic Networking", RFC 7576, Analysis for Autonomic Networking", RFC 7576,
DOI 10.17487/RFC7576, June 2015, DOI 10.17487/RFC7576, June 2015,
<https://www.rfc-editor.org/info/rfc7576>. <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 Appendix A. Deployment Overview
This Appendix includes logical deployment models, and explanations of This appendix includes logical deployment models and explanations of
the target deployment models. The purpose is to help in the target deployment models. Its purpose is to help in
understanding the mechanism of the document. understanding the mechanism described in this document.
This Appendix includes two sub-sections: A.1 for the two most common This appendix includes two subsections: Appendix A.1 for the two most
DHCP deployment models, and A.2 for the proposed PD deployment model. common DHCP deployment models and Appendix A.2 for the PD deployment
It should be noted that these are just examples, and there are many model described in this document. It should be noted that these are
more deployment models. just examples, and there are many more deployment models.
A.1. Address & Prefix management with DHCP A.1. Address and Prefix Management with DHCP
Edge DHCP server deployment requires every edge router connecting to Edge DHCP server deployment requires every edge router connecting to
CPE to be a DHCP server assigning IPv4/IPv6 addresses to CPE - and a Customer Premises Equipment (CPE) device to be a DHCP server
optionally IPv6 prefixes via DHCPv6-PD for IPv6 capable CPE that are assigning IPv4/IPv6 addresses to CPEs -- and, optionally, IPv6
router and have LANs behind them. prefixes via DHCPv6-PD for IPv6-capable CPEs that are routers and
have LANs behind them.
edge edge
dynamic, "netconf/YANG" interfaces dynamic, "NETCONF/YANG" interfaces
<---------------> +-------------+ <---------------> +-------------+
+------+ <- telemetry | edge router/|-+ ----- +-----+ +------+ <- telemetry | edge router/|-+ ----- +-----+
|config| .... Domain ... | DHCP server | | ... | CPE |+ LANs |config| .... domain ... | DHCP server | | ... | CPE |+ LANs
|server| +-------------+ | ----- +-----+| (---| ) |server| +-------------+ | ----- +-----+| (---| )
+------+ +--------------+ DHCP/ +-----+ +------+ +--------------+ DHCP/ +-----+
DHCPv6 / PD DHCPv6-PD
Figure 2: DHCP Deployment Model without a Central DHCP Server Figure 2: DHCP Deployment Model without a Central DHCP Server
This requires various coordination functions via some backend system This requires various coordination functions via some backend system
depicted as "config server": The address prefixes on the edge (depicted as the "config server" in Figure 2): the address prefixes
interfaces should be slightly larger than required for the number of on the edge interfaces should be slightly larger than required for
CPEs connected so that the overall address space is best used. the number of CPEs connected so that the overall address space is
best used.
The config server needs to provision edge interface address prefixes The config server needs to provision edge interface address prefixes
and DHCP parameters for every edge router. If too fine grained and DHCP parameters for every edge router. If prefixes that are too
prefixes are used, this will result in large routing tables across fine-grained are used, this will result in large routing tables
the "Domain". If too coarse grained prefixes are used, address space across the domain shown in the figure. If prefixes that are too
is wasted. (This is less of a concern for IPv6, but if the model coarse-grained are used, address space is wasted. (This is less of a
includes IPv4, it is a very serious concern.) concern for IPv6, but if the model includes IPv4, it is a very
serious concern.)
There is no standard describing algorithms for how configuration There is no standard that describes algorithms for how configuration
servers would best perform this ongoing dynamic provisioning to servers would best perform this ongoing dynamic provisioning to
optimize routing table size and address space utilization. optimize routing table size and address space utilization.
There are currently no complete YANG models that a config server There are currently no complete YANG data models that a config server
could use to perform these actions (including telemetry of assigned could use to perform these actions (including telemetry of assigned
addresses from such distributed DHCP servers). addresses from such distributed DHCP servers). For example, a YANG
data model for controlling DHCP server operations is still being
For example, a YANG model for controlling DHCP server operations is developed [DHCP-YANG-MODEL].
still in draft [I-D.liu-dhc-dhcp-yang-model].
Due to these and other problems of the above model, the more common Due to these and other problems related to the above model, the more
DHCP deployment model is as follows: common DHCP deployment model is as follows:
+------+ edge +------+ edge
|config| initial, "CLI" interfaces |config| initial, "CLI" interfaces
|server| ----------------> +-------------+ |server| ----------------> +-------------+
+------+ | edge router/|-+ ----- +-----+ +------+ | edge router/|-+ ----- +-----+
| .... Domain ... | DHCP relay | | ... | CPE |+ LANs | .... domain ... | DHCP relay | | ... | CPE |+ LANs
+------+ +-------------+ | ----- +-----+| (---| ) +------+ +-------------+ | ----- +-----+| (---| )
|DHCP | +--------------+ DHCP/ +-----+ |DHCP | +--------------+ DHCP/ +-----+
|server| DHCPv6 / PD |server| DHCPv6-PD
+------+ +------+
Figure 3: DHCP Deployment Model with a Central DHCP Server Figure 3: DHCP Deployment Model with a Central DHCP Server
Dynamic provisioning changes to edge routers are avoided by using a Dynamic provisioning changes to edge routers are avoided by using a
central DHCP server and reducing the edge router from DHCP server to 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. The "configuration" on the edge routers is static. The
DHCP relay function inserts "edge interface" and/or subscriber DHCP relay function inserts an "edge interface" and/or subscriber-
identifying options into DHCP requests from CPE (e.g., [RFC3046], identifying options into DHCP requests from CPEs (e.g., [RFC3046]
[RFC6221]), the DHCP server has complete policies for address [RFC6221]), and the DHCP server has complete policies for address
assignments and prefixes useable on every edge-router/interface/ assignments and prefixes usable on every edge router / interface /
subscriber-group. When the DHCP relay sees the DHCP reply, it subscriber group. When the DHCP relay sees the DHCP reply, it
inserts static routes for the assigned address/address-prefix into inserts static routes for the assigned address / address prefix into
the routing table of the edge router which are then to be distributed the routing table of the edge router; these routes are then to be
by the IGP (or BGP) inside the domain to make the CPE and LANs distributed by the IGP (or BGP) inside the domain to make the CPE and
reachable across the Domain. LANs reachable across the domain shown in the figure.
There is no comprehensive standardization of these solutions. There is no comprehensive standardization of these solutions. For
[RFC3633] section 14, for example, simply refers to "a [non-defined] example, [RFC8415], Section 19.1.3 simply refers to "a [non-defined]
protocol or other out-of-band communication to add routing protocol or other out-of-band communication to configure routing
information for delegated prefixes into the provider edge router". information for delegated prefixes on any router through which the
client may forward traffic."
A.2. Prefix management with ANI/GRASP A.2. Prefix Management with ANI/GRASP
With the proposed use of ANI and Prefix-management ASAs using GRASP, Using the ANI and prefix management ASAs (PM-ASAs) using GRASP, the
the deployment model is intended to look as follows: deployment model is intended to look as follows:
|<............ ANI Domain / ACP............>| (...) ........-> |<............ ANI domain / ACP............>| (...) ........->
Roles Roles
| |
v "Edge routers" v "Edge routers"
GRASP parameter +----------+ GRASP parameter +----------+
Network wide | PM-ASA | downstream Network-wide | PM-ASA | downstream
parameters/policies | (DHCP- | interfaces parameters/policies | (DHCP | interfaces
| |functions)| ------ | |functions)| ------
v "central device" +----------+ v "central device" +----------+
+------+ ^ +--------+ +------+ ^ +--------+
|PM-ASA| <............GRASP .... .... | CPE |-+ (LANs) |PM-ASA| <............GRASP .... .... | CPE |-+ (LANs)
+------+ . v |(PM-ASA)| | ---| +------+ . v |(PM-ASA)| | ---|
. +........+ +----------+ +--------+ | . +........+ +----------+ +--------+ |
+...........+ . PM-ASA . | PM-ASA | ------ +---------+ +...........+ . PM-ASA . | PM-ASA | ------ +---------+
.DHCP server. +........+ | (DHCP- | SLAAC/ .DHCP server. +........+ | (DHCP | SLAAC/
+...........+ "intermediate |functions)| DHCP/DHCP-PD +...........+ "intermediate |functions)| DHCP/DHCP-PD
router" +----------+ router" +----------+
Figure 4: Proposed Deployment Model using ANI/GRASP Figure 4: Deployment Model Using ANI/GRASP
The network runs an ANI domain with ACP The network runs an ANI domain with an ACP [RFC8994] between some
[I-D.ietf-anima-autonomic-control-plane] between some central device central device (e.g., a router or an ANI-enabled management device)
(e.g., router or ANI enabled management device) and the edge routers. and the edge routers. ANI/ACP provides a secure, zero-touch
ANI/ACP provides a secure, zero-touch communication channel between communication channel between the devices and enables the use of
the devices and enables the use of GRASP[I-D.ietf-anima-grasp] not GRASP [RFC8990] not only for peer-to-peer communication but also for
only for p2p communication, but also for distribution/flooding. distribution/flooding.
The central devices and edge routers run software in the form of The central devices and edge routers run software in the form of ASAs
"Autonomic Service Agents" (ASA) to support this document's autonomic to support this document's autonomic IPv6 edge prefix management.
IPv6 edge prefix management (PM). The ASAs for prefix management are PM-ASAs as discussed below together comprise the Autonomic Prefix
called PM-ASAs below, and together comprise the Autonomic Prefix
Management Function. Management Function.
Edge routers can have different roles based on the type and number of 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 CPEs attaching to them. Each edge router could be an RSG, ASG, or
in mobile aggregation networks (see Section 6.1). Mechanisms outside CSG in mobile aggregation networks (see Section 6.1). Mechanisms
the scope of this document make routers aware of their roles. outside the scope of this document make routers aware of their roles.
Some considerations about the proposed deployment model are listed as Some considerations related to the deployment model are as follows.
follows.
1. In a minimum Prefix Management solution, the central device uses 1. In a minimum prefix management solution, the central device uses
the "PrefixManager.Params" GRASP Objective introduced in this the PrefixManager.Params GRASP objective introduced in this
document to disseminate network wide, per-role parameters to edge document to disseminate network-wide, per-role parameters to edge
routers. The PM-ASA uses the parameters applying to its role to routers. The PM-ASA uses the parameters that apply to its own
locally configure pre-existing addressing functions. Because PM-ASA role to locally configure preexisting addressing functions.
does not manage the dynamic assignment of actual IPv6 address Because the PM-ASA does not manage the dynamic assignment of
prefixes in this case, the following options can be considered: 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 1.a The edge router connects via downstream interfaces to each
that each requires an address. The PM-ASA sets up for each such (host) CPE that requires an address. The PM-ASA sets up for
interface a DHCP requesting router (according to [RFC3633]) to each such interface a DHCP requesting router (according to
request an IPv6 prefix for the interface. The router's address on [RFC8415]) to request an IPv6 prefix for the interface. The
the downstream interface can be another parameter from the GRASP router's address on the downstream interface can be another
Objective. The CPEs assign addresses in the prefix via RAs from the parameter from the GRASP objective. The CPEs assign
router or the PM-ASA manages a local DHCPv6 server to assign addresses in the prefix via Router Advertisements (RAs), or
addresses to the CPEs. A central DHCP server acting as the DHCP the PM-ASA manages a local DHCPv6 server to assign addresses
delegating router (according to [RFC3633]) is required. Its address to the CPEs. A central DHCP server acting as the DHCP
can be another parameter from the GRASP Objective. 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 1.b The edge router also connects via downstream interfaces to
(customer managed) CPEs that are routers and act as DHCPv6 requesting (customer managed) CPEs that are routers and act as DHCPv6
routers. The need to support this could be derived from role and/or requesting routers. The need to support this could be
GRASP parameters and the PM-ASA sets up a DHCP relay function to pass derived from role or GRASP parameters, and the PM-ASA sets
on requests to the central DHCP server as in 1.a. 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 2. In a solution without a central DHCP server, the PM-ASA on the
edge routers not only learn parameters from "PrefixManager.Params" edge routers not only learns parameters from PrefixManager.Params
but also utilize GRASP to request/negotiate actual IPv6 prefix but also utilizes GRASP to request/negotiate actual IPv6 prefix
delegation via the GRASP "PrefixManager" objective described in more delegation via the GRASP PrefixManager objective, as described in
detail below. In the most simple case, these prefixes are delegated more detail below. In the simplest case, these prefixes are
via this GRASP objective from the PM-ASA in the central device. This delegated via this GRASP objective from the PM-ASA in the central
device must be provisioned initially with a large pool of prefixes. device. This device must be provisioned initially with a large
The delegated prefixes are then used by the PM-ASA on the edge pool of prefixes. The delegated prefixes are then used by the
routers to edge routers to configure prefixes on their downstream PM-ASA on the edge routers to configure prefixes on their
interfaces to assign addresses via RA/SLAAC to host CPEs. The PM-ASA downstream interfaces to assign addresses via RA/SLAAC to host
may also start local DHCP servers (as in 1.a) to assign addresses via CPEs. The PM-ASA may also start local DHCP servers (as in point
DHCP to CPE from the prefixes it received. This includes both host 1.a) to assign addresses via DHCP to the CPEs from the prefixes
CPEs requesting IPv6 addresses as well as router CPEs that request it received. This includes both host CPEs requesting IPv6
IPv6 prefixes. The PM-ASA needs to manage the address pool(s) it has addresses and router CPEs that request IPv6 prefixes. The PM-ASA
requested via GRASP and allocate sub-address pools to interfaces and needs to manage the address pool(s) it has requested via GRASP
the local DHCP servers it starts. It needs to monitor the address and allocate sub-address pools to interfaces and the local DHCP
utilization and accordingly request more address prefixes if its servers it starts. It needs to monitor the address utilization
existing prefixes are exhausted, or return address prefixes when they and accordingly request more address prefixes if its existing
are unneeded. prefixes are exhausted, or return address prefixes when they are
unneeded.
This solution is quite similar to the initial described IPv6 DHCP This solution is quite similar to the previous IPv6 DHCP
deployment model without central DHCP server, and ANI/ACP/GRASP and deployment model without a central DHCP server, and ANI/ACP/GRASP
the PM-ASA do provide the automation to make this approach work more and the PM-ASA do provide the automation to make this approach
easily than it is possible today. work more easily than is possible today.
3. The address pool(s) from which prefixes are allocated does not 3. The address pools from which prefixes are allocated do not all
need to be taken all from one central location. Edge router PM-ASA need to be taken from one central location. An edge-router
that received a big (short) prefix from a central PM-ASA could offer PM-ASA that received a big (short) prefix from a central PM-ASA
smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could could offer smaller sub-prefixes to a neighboring edge-router
be used in such a way that the PM-ASA would find and select the PM-ASA. GRASP could be used in such a way that the PM-ASA would
objective from the closest neighboring PM-ASA, therefore allowing to find and select the objective from the closest neighboring
maximize aggregation: A PM-ASA would only request further (smaller/ PM-ASA, therefore allowing aggregation to be maximized: a PM-ASA
shorter) prefixes when it exhausts its own poll (from the central would only request further smaller prefixes when it exhausts its
location) and can not get further large prefixes from that central own pool (from the central location) and cannot get further large
location anymore. Because the overflow prefixes taken from a prefixes from that central location anymore. Because the
topological nearby PM-ASA, the number of longer prefixes that have to overflow prefixes taken from a topologically nearby PM-ASA, the
be injected into the routing tables is limited and the topological number of longer prefixes that have to be injected into the
proximity increases the chances that aggregation of prefixes in the routing tables is limited and the topological proximity increases
IGP can most likely limit the geography in which the longer prefixes the chances that aggregation of prefixes in the IGP can most
need to be routed. likely limit the geography in which the longer prefixes need to
be routed.
4. Instead of peer-to-peer optimization of prefix delegation, a 4. Instead of peer-to-peer optimization of prefix delegation, a
hierarchy of PM-ASA can be built (indicated in the picture via a hierarchy of PM-ASAs can be built (indicated in Figure 4 via a
dotted intermediate router). This would require additional dotted intermediate router). This would require additional
parameters to the "PrefixManager" objective to allow creating a parameters in the PrefixManager objective to allow the creation
hierarchy of PM-ASA across which the prefixes can be delegated. This of a hierarchy of PM-ASAs across which the prefixes can be
is not detailed further below. delegated.
5. In cases where CPEs are also part of the ANI Domain (e.g., 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 "managed CPEs"), then GRASP will extend into the actual customer
and can equally run a PM-ASA. All the options described in points 1 sites and can also run a PM-ASA. All the options described in
to 4 above would then apply to the CPE as the edge router with the points 1 to 4 above would then apply to the CPE as the edge
mayor changes being that a) a CPE router will most likley not need to router, with the major changes being that (a) a CPE router will
run DHCPv6-PD itself, but only DHCP address assignment, b) The edge most likely not need to run DHCPv6-PD itself, but only DHCP
routers to which the CPE connect would most likely become ideal address assignment and (b) the edge routers to which the CPE
places to run a hierarchical instance of PD-ASAs on as outlined in connects would most likely become ideal places on which to run a
point 1. 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 Authors' Addresses
Sheng Jiang (editor) Sheng Jiang (editor)
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road Q14, Huawei Campus
Hai-Dian District, Beijing, 100095 No. 156 Beiqing Road
P.R. China Hai-Dian District, Beijing
100095
China
Email: jiangsheng@huawei.com Email: jiangsheng@huawei.com
Zongpeng Du Zongpeng Du
Huawei Technologies Co., Ltd China Mobile
Q14, Huawei Campus, No.156 Beiqing Road 32 Xuanwumen West St
Hai-Dian District, Beijing, 100095 Xicheng District, Beijing
P.R. China 100053
China
Email: duzongpeng@huawei.com Email: duzongpeng@chinamobile.com
Brian Carpenter Brian Carpenter
Department of Computer Science
University of Auckland University of Auckland
School of Computer Science
PB 92019 PB 92019
Auckland 1142 Auckland 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
Qiong Sun Qiong Sun
China Telecom China Telecom
No.118, Xizhimennei Street 118 Xizhimennei St
Beijing 100035 Beijing
P. R. China 100035
China
Email: sunqiong@ctbri.com.cn Email: sunqiong@chinatelecom.cn
 End of changes. 155 change blocks. 
519 lines changed or deleted 502 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/