Autonomic IPv6 Edge Prefix
Management in Large-Scale NetworksHuawei Technologies Co., LtdNo. 156 Beiqing RoadQ14, Huawei CampusHai-Dian District, Beijing100095Chinajiangsheng@huawei.comChina Mobile32 Xuanwumen West StXicheng District, Beijing100053Chinaduzongpeng@chinamobile.comUniversity of AucklandSchool of Computer SciencePB 92019Auckland1142New Zealandbrian.e.carpenter@gmail.comChina Telecom118 Xizhimennei StBeijing100035Chinasunqiong@chinatelecom.cn
Operations and Management
ANIMAAutonomic NetworkingPrefix ManagementThis document defines two autonomic technical objectives for IPv6 prefix
management at the edge of large-scale ISP networks,
with an extension to support IPv4 prefixes. An important purpose
of this document is to use it for validation of the design of various
components of the Autonomic Networking Infrastructure.IntroductionThe original purpose of this document was to validate the design of the
Autonomic Networking Infrastructure (ANI) for a realistic use case. It shows
how the ANI can be applied to IP prefix delegation,
and it outlines approaches to build a system to do this. A fully
standardized solution would require more details, so this document
is informational in nature.This document defines two autonomic technical objectives for IPv6 prefix
management in large-scale networks, with an extension to support IPv4 prefixes.
The background to Autonomic Networking is described in
and . The GeneRic Autonomic Signaling Protocol (GRASP) is
specified by and can make use of
the technical objectives to provide a solution for autonomic
prefix management. An important purpose
of the present document is to use it for validation of the design of
GRASP and other components of the ANI as
described in .This document is not a complete functional specification of an
autonomic prefix management system, and it does not describe all
detailed aspects of the GRASP objective parameters and Autonomic Service
Agent (ASA) procedures necessary to build a complete system. Instead, it
describes the architectural framework utilizing the components of the
ANI, outlines the different
deployment options and aspects, and defines GRASP objectives for use in
building the system. It also provides some basic parameter examples.This document is not intended to solve all cases of IPv6 prefix
management. In fact, it assumes that the network's main infrastructure
elements already have addresses and prefixes. This document is dedicated
to how to make IPv6 prefix management at the edges of large-scale
networks as autonomic as possible. It is specifically written for
Internet Service Provider (ISP) networks. Although there are similarities between
ISPs and large enterprise networks, the requirements for the two use
cases differ. In any case, the scope of the solution is expected
to be limited, like any Autonomic Network, to a single management
domain.However, the solution is designed in a general way. Its use for a
broader scope than edge prefixes, including some or all infrastructure
prefixes, is left for future discussion.A complete solution has many aspects that are not discussed here.
Once prefixes have been assigned to routers, they need to be
communicated to the routing system as they are brought into use. Similarly,
when prefixes are released, they need to be removed from the routing system.
Different operators may have different policies regarding prefix lifetimes,
and they may prefer to have centralized or distributed pools of spare
prefixes. In an Autonomic Network, these are properties decided upon by the
design of the relevant ASAs. The GRASP objectives are simply building
blocks.
A particular risk of distributed prefix allocation in large networks
is that over time, it might lead to fragmentation of the address space
and an undesirable increase in the size of the interior routing protocol tables.
The extent of this risk depends on the algorithms and policies used by the ASAs.
Mitigating this risk might even become an autonomic function in itself.TerminologyThe key words "MUST", "MUST NOT",
"REQUIRED", "SHALL",
"SHALL NOT", "SHOULD",
"SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14
when, and only
when, they appear in all capitals, as shown here.This document uses terminology defined in .Problem StatementThe Autonomic Networking use case considered here is autonomic IPv6
prefix management at the edge of large-scale ISP networks.Although DHCPv6-PD (DHCPv6 Prefix Delegation) supports
automated delegation of IPv6 prefixes from one router to another, prefix
management still largely depends on human planning. In other words,
there is no basic information or policy to support autonomic decisions
on the prefix length that each router should request or be delegated,
according to its role in the network. Roles could be defined separately
for individual devices or
could be generic (edge router, interior router, etc.). Furthermore, IPv6
prefix management by humans tends to be rigid and static after initial
planning.The problem to be solved by Autonomic Networking is how to
dynamically manage IPv6 address space in large-scale networks, so that
IPv6 addresses can be used efficiently. Here, we limit the problem to
assignment of prefixes at the edge of the network, close to access
routers that support individual fixed-line subscribers, mobile
customers, and corporate customers. We assume that the core
infrastructure of the network has already been established with
appropriately assigned prefixes. The Autonomic Networking approach discussed in this
document is based on the assumption that there is a generic discovery
and negotiation protocol that enables direct negotiation between
intelligent IP routers. GRASP is
intended to be such a protocol.Intended User and Administrator ExperienceThe intended experience is, for the administrators of a
large-scale network, that the management of IPv6 address space at the
edge of the network can be run with minimum effort, as devices at the
edge are added and removed and as customers of all kinds join and
leave the network. In the ideal scenario, the administrators only
have to specify a single IPv6 prefix for the whole network and the
initial prefix length for each device role. As far as users are
concerned, IPv6 prefix assignment would occur exactly as it does in
any other network.The actual prefix usage needs to be logged for potential offline
management operations, including audit and security incident
tracing.Analysis of Parameters and Information InvolvedFor specific purposes of address management, each edge device will implement
several parameters. (Some of them can be preconfigured
before they are connected.) They include the following:
Identity, authentication, and authorization of this device. This
is expected to use the Autonomic Networking secure bootstrap
process ,
following which the device could safely take part in autonomic
operations.
Role of this device. Some example roles are discussed in .
An IPv6 prefix length for this device.
An IPv6 prefix that is assigned to this device and its
downstream devices.
The network as a whole will implement the following parameters:
Identity of a trust anchor, which is a certification authority
(CA) maintained by the network administrators, used during the
secure bootstrap process.
Total IPv6 address space available for edge devices. It is a pool
of one or several IPv6 prefixes.
The initial prefix length for each device role.
Parameters Each Device Can Define for ItselfThis section identifies those of the above parameters that do not
need external information in order for the devices concerned to set
them to a reasonable default value after bootstrap or after a network
disruption. They are as follows:
Default role of this device.
Default IPv6 prefix length for this device.
Cryptographic identity of this device, as needed for secure bootstrapping
.
The device may be shipped from the manufacturer with a
preconfigured role and default prefix length, which could be
modified by an autonomic mechanism. Its cryptographic identity will be installed
by its manufacturer.Information Needed from Network OperationsThis section identifies those parameters that might need
operational input in order for the devices concerned to set them to
a non-default value.
Non-default value for the IPv6 prefix length for this device.
This needs to be decided based on the role of this device.
The initial prefix length for each device role.
Whether to allow the device to request more address
space.
The policy regarding when to request more address space -- for example,
if the address usage reaches a certain limit or percentage.
Comparison with Current SolutionsThis section briefly compares the above use case with current
solutions. Currently, the address management is still largely
dependent on human planning. It is rigid and static after initial
planning. Address requests will fail if the configured address space
is used up.Some autonomic and dynamic address management functions may be
achievable by extending the existing protocols -- for example,
extending DHCPv6-PD
to request IPv6 prefixes according to the device
role. However, defining uniform device roles may not be a practical
task, as some functions cannot be configured on the basis of role using
existing prefix delegation protocols.Using a generic autonomic discovery and negotiation protocol
instead of specific solutions has the advantage that additional
parameters can be included in the autonomic solution without
creating new mechanisms. This is the principal argument for a
generic approach.Interaction with Other DevicesInformation Needed from Other DevicesThis section identifies those of the above parameters that need
external information from neighbor devices (including the upstream
devices). In many cases, two-way dialogue with neighbor devices is
needed to set or optimize them.
Information regarding the identity of a trust anchor is needed.
The device will need to discover another device from which it can
acquire IPv6 address space.
Information regarding the initial prefix length for the role of each device is needed, particularly
for its own downstream devices.
The default value of the IPv6 prefix length may be overridden
by a non-default value.
The device will need to request and acquire one or more IPv6 prefixes that
can be assigned to this device and its downstream devices.
The device may respond to prefix delegation requests from its
downstream devices.
The device may require the assignment of more IPv6 address
space if it used up its assigned IPv6 address space.
Monitoring, Diagnostics, and ReportingThis section discusses what role devices should play in
monitoring, fault diagnosis, and reporting.
The actual address assignments need to be logged for
potential offline management operations.
In general, the usage situation regarding address space should be
reported to the network administrators in an abstract way -- for
example, statistics or a visualized report.
A forecast of address exhaustion should be reported.
Autonomic Edge Prefix Management SolutionThis section introduces the building blocks for
an autonomic edge prefix management solution.
As noted in , this is not a complete description of
a solution, which will depend on the detailed design of the relevant
Autonomic Service Agents (ASAs).
It uses the generic discovery and negotiation protocol defined
by . The relevant GRASP objectives
are defined in .The procedures described below are carried out by an ASA in each device that participates in the solution. We
will refer to this as the PrefixManager ASA.Behavior of a Device Requesting a PrefixIf the device containing a PrefixManager ASA has used up its
address pool, it can request more space according to its requirements.
It should decide the length of the requested prefix and request it via
the mechanism described in . Note that
although the device's role may define certain default allocation lengths,
those defaults might be changed dynamically, and
the device might request more, or less, address space due to
some local operational heuristic.A PrefixManager ASA that needs additional address space should
firstly discover peers that may be able to provide extra address
space. The ASA should send out a GRASP Discovery message that contains
a PrefixManager Objective option (see and ) in
order to discover peers also supporting that option. Then, it should
choose one such peer, most likely the first to respond.If the GRASP Discovery Response message carries a Divert option
pointing to an off-link PrefixManager ASA, the requesting ASA may
initiate negotiation with that ASA-diverted device to find out whether
it can provide the requested length of the prefix.In any case, the requesting ASA will act as a GRASP negotiation
initiator by sending a GRASP Request message with a PrefixManager
Objective option. The ASA indicates in this option the length of
the requested prefix.
This starts a GRASP negotiation process.During the subsequent negotiation, the ASA will decide at each step
whether to accept the offered prefix. That decision, and the decision
to end the negotiation, are implementation choices.The ASA could alternatively initiate GRASP discovery in rapid mode
with an embedded negotiation request, if it is implemented.Behavior of a Device Providing a PrefixAt least one device on the network must be configured with
the initial pool of available prefixes mentioned in .
Apart from that requirement, any device may act as a provider of prefixes.A device that receives a Discovery message with a PrefixManager
Objective option should respond with a GRASP Response message if it
contains a PrefixManager ASA. Further details of the discovery
process are described in . When
this ASA receives a subsequent Request message, it should conduct a
GRASP negotiation sequence, using Negotiate, Confirm Waiting, and
Negotiation End messages as appropriate. The Negotiate messages
carry a PrefixManager Objective option,
which will indicate the prefix and its length offered to the requesting ASA. As
described in , negotiation will
continue until either end stops it with a Negotiation End message.
If the negotiation succeeds, the ASA that provides the prefix will remove the
negotiated prefix from its pool, and the requesting ASA will add it.
If the negotiation fails, the party sending the Negotiation End
message may include an error code string.During the negotiation, the ASA will decide at each step how large
a prefix to offer. That decision, and the decision to end the negotiation,
are implementation choices.The ASA could alternatively negotiate in response to GRASP discovery in rapid mode, if it is implemented.This specification is independent of whether the PrefixManager ASAs
are all embedded in routers, but that would be a rather natural
scenario. In a hierarchical network topology, a given router typically
provides prefixes for routers below it in the hierarchy, and it is
also likely to contain the first PrefixManager ASA discovered by those downstream
routers. However, the GRASP discovery model, including its redirection
feature, means that this is not an exclusive scenario, and a
downstream PrefixManager ASA could negotiate a new prefix with a
device other than its upstream router.A resource shortage may cause the gateway router to request more
resources in turn from its own upstream device. This would be another
independent GRASP discovery and negotiation process. During the
processing time, the gateway router should send a Confirm Waiting
message to the initial requesting router, to extend its timeout. When
the new resource becomes available, the gateway router responds with a
GRASP Negotiate message with a prefix length matching the request.The algorithm used to choose which prefixes to assign on the devices that
provide prefixes is an implementation choice.Behavior after Successful NegotiationUpon receiving a GRASP Negotiation End message that indicates
that an acceptable prefix length is available, the requesting device
may use the negotiated prefix without further messages.There are use cases where the ANI/GRASP-based prefix
management approach can work together with DHCPv6-PD
as a complement. For example, the ANI/GRASP-based
method can be used intra-domain, while the DHCPv6-PD method works inter-domain
(i.e., across an administrative boundary). Also, ANI/GRASP can be used
inside the domain, and DHCP/DHCPv6-PD can be used on the edge of the
domain to clients (non-ANI devices). Another similar use case would be
ANI/GRASP inside the domain, with
RADIUS providing prefixes to client devices.Prefix LoggingWithin the autonomic prefix management system, all prefix assignments are
done by devices without human intervention. It may be required
that all prefix assignment history be recorded -- for example, to detect
or trace lost prefixes after outages or to meet legal requirements.
However, the logging and reporting process is out of scope for this
document.Autonomic Prefix Management ObjectivesThis section defines the GRASP technical objective options that are used to support
autonomic prefix management.Edge Prefix Objective OptionThe PrefixManager Objective option is a GRASP Objective option
conforming to the GRASP specification . Its name is
"PrefixManager" (see ), and it carries the following
data items as its value: the prefix length and
the actual prefix bits. Since GRASP is based on CBOR (Concise Binary Object Representation)
, the format of the PrefixManager Objective
option is described in the Concise Data Definition Language (CDDL)
as follows:The use of the "dry run" mode of GRASP is NOT RECOMMENDED for this objective, because it
would require both ASAs to store state information about the corresponding negotiation, to no real
benefit -- the requesting ASA cannot base any decisions on the result of a successful
dry-run negotiation.IPv4 ExtensionThis section presents an extended version of the
PrefixManager objective that supports IPv4 by adding an extra flag:
Prefix and address management for IPv4 is considerably more difficult
than for IPv6, due to the prevalence of NAT, ambiguous addresses ,
and address sharing . These complexities might require further extending
the objective with additional fields that are not defined by this document.Prefix Management ParametersAn implementation of a prefix manager MUST include default settings
of all necessary parameters. However, within a single administrative
domain, the network operator MAY change default parameters for all
devices with a certain role. Thus, it would be possible to apply an
intended policy for every device in a simple way, without traditional
configuration files. As noted in , individual
autonomic devices may also change their own behavior dynamically.For example, the network operator could change the default prefix
length for each type of role. A prefix management parameters objective,
which contains mapping information of device roles and their default
prefix lengths, MAY be flooded in the network, through the Autonomic
Control Plane (ACP) .
The objective is defined in CDDL as follows:The "any" object would be the relevant parameter definitions (such as
the example below) transmitted as a CBOR object in an appropriate
format.This could be flooded to all nodes, and any PrefixManager ASA that
did not receive it for some reason could obtain a copy using GRASP
unicast synchronization. Upon receiving the prefix management
parameters, every device can decide its default prefix length by
matching its own role.Example of Prefix Management ParametersThe parameters comprise mapping information of device roles and
their default prefix lengths in an autonomic domain. For example,
suppose an IPRAN (IP Radio Access Network) operator wants to configure
the prefix length of a Radio Network Controller Site Gateway (RSG) as 34, the prefix length
of an Aggregation Site Gateway (ASG) as 44, and the prefix length of a Cell
Site Gateway (CSG) as 56. This could be described in the value of the
PrefixManager.Params objective as:This example is expressed in JSON , which is easy to represent in CBOR.An alternative would be to express the parameters in YANG using the YANG-to-CBOR mapping .For clarity, the background of the example is introduced below
and can also be regarded as a use case for the mechanism defined in
this document.An IPRAN is used for mobile backhaul, including radio
stations, RNCs (Radio Network Controllers) (in 3G) or the packet core (in LTE), and the IP network
between them, as shown in . The eNB (Evolved Node B) entities, the RNC, the SGW (Serving Gateway), and the MME (Mobility
Management Entity) are mobile network entities defined in 3GPP. The
CSGs, ASGs, and RSGs are entities defined in the IPRAN solution.The IPRAN topology shown in
includes Ring1, which is the
circle following ASG1->RSG1->RSG2->ASG2->ASG1; Ring2,
following CSG1->ASG1->ASG2->CSG2->CSG1; and Ring3,
following CSG3->ASG1->ASG2->CSG3. In a real deployment of an
IPRAN, there may be more stations, rings, and routers in the topology,
and normally the network is highly dependent on human design and
configuration, which is neither flexible nor cost-effective.If ANI/GRASP is supported in the IPRAN, the network nodes
should be able to negotiate with each other and make some autonomic
decisions according to their own status and the information
collected from the network. The prefix management parameters should be
part of the information they communicate.The routers should know the role of their neighbors, the default
prefix length for each type of role, etc. An ASG should be able to
request prefixes from an RSG, and a CSG should be able to request prefixes from
an ASG. In each request, the ASG/CSG should indicate the required prefix length, or its role,
which implies what length it needs by default.Security ConsiderationsRelevant security issues are discussed in . The preferred security model is that
devices are trusted following the secure bootstrap procedure and that a secure
Autonomic Control Plane (ACP) is in place.It is RECOMMENDED that DHCPv6-PD, if used, should be implemented using
DHCPv6 authentication or Secure DHCPv6.IANA ConsiderationsThis 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 .ReferencesNormative ReferencesGeneRic Autonomic Signaling Protocol (GRASP)Bootstrapping Remote Secure Key Infrastructure (BRSKI)An Autonomic Control Plane (ACP)Informative ReferencesCBOR Encoding of Data Modeled with YANGA Reference Model for Autonomic NetworkingYang Data Model for DHCP ProtocolDeployment OverviewThis appendix includes logical deployment models and explanations of
the target deployment models. Its purpose is to help in understanding
the mechanism described in this document.This appendix includes two subsections:
for the two most common
DHCP deployment models and for the PD deployment model described in this document. It
should be noted that these are just examples, and there are many more
deployment models.Address and Prefix Management with DHCPEdge DHCP server deployment requires every edge router connecting
to a Customer Premises Equipment (CPE) device to be a DHCP server assigning IPv4/IPv6 addresses to CPEs -- and,
optionally, IPv6 prefixes via DHCPv6-PD for IPv6-capable CPEs that are
routers and have LANs behind them.This requires various coordination functions via some backend
system (depicted as the "config server" in ): the address prefixes on the edge
interfaces should be slightly larger than required for the number of
CPEs connected so that the overall address space is best used.The config server needs to provision edge interface address
prefixes and DHCP parameters for every edge router. If prefixes that are too fine-grained are used, this will result in large routing tables
across the domain shown in the figure. If prefixes that are too coarse-grained are used, address
space is wasted. (This is less of a concern for IPv6, but if the
model includes IPv4, it is a very serious concern.)There is no standard that describes algorithms for how configuration servers
would best perform this ongoing dynamic provisioning to optimize
routing table size and address space utilization.There are currently no complete YANG data models that a config server
could use to perform these actions (including telemetry of assigned
addresses from such distributed DHCP servers). For example, a YANG data model for controlling DHCP server operations is
still being developed .Due to these and other problems related to the above model, the more common
DHCP deployment model is as follows:Dynamic provisioning changes to edge routers are avoided by using a
central DHCP server and reducing the edge router from DHCP server to
DHCP relay. The "configuration" on the edge routers is static. The
DHCP relay function inserts an "edge interface" and/or
subscriber-identifying options into DHCP requests from CPEs (e.g., ), and the DHCP server has
complete policies for address assignments and prefixes usable on
every edge router / interface / subscriber group. When the DHCP relay sees
the DHCP reply, it inserts static routes for the assigned
address / address prefix into the routing table of the edge router; these routes
are then to be distributed by the IGP (or BGP) inside the domain to
make the CPE and LANs reachable across the domain shown in the figure.There is no comprehensive standardization of these solutions. For example, 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."Prefix Management with ANI/GRASPUsing the ANI and prefix management ASAs (PM-ASAs) using GRASP, the deployment
model is intended to look as follows:The network runs an ANI domain with an ACP between some central
device (e.g., a router or an ANI-enabled management device) and the edge
routers. ANI/ACP provides a secure, zero-touch communication channel
between the devices and enables the use of GRASP not only for peer-to-peer communication
but also for distribution/flooding.The central devices and edge routers run software
in the form of ASAs to support this document's autonomic IPv6 edge prefix management. PM-ASAs as discussed below
together comprise the Autonomic Prefix Management Function.Edge routers can have different roles based on the type and number
of CPEs attaching to them. Each edge router could be an RSG, ASG, or CSG
in mobile aggregation networks (see ). Mechanisms outside
the scope of this document make routers aware of their roles.Some considerations related to the deployment model are
as follows.
In a minimum prefix management solution, the central device uses
the PrefixManager.Params GRASP objective introduced in this document
to disseminate network-wide, per-role parameters to edge routers. The
PM-ASA uses the parameters that apply to its own role to locally
configure preexisting addressing functions. Because the PM-ASA does
not manage the dynamic assignment of actual IPv6 address prefixes in
this case, the following options can be considered:
The edge router connects via downstream interfaces to each (host)
CPE that requires an address. The PM-ASA sets up for each such
interface a DHCP requesting router (according to )
to request an IPv6 prefix for the interface. The
router's address on the downstream interface can be another parameter
from the GRASP objective. The CPEs assign addresses in the prefix via
Router Advertisements (RAs), or the PM&nbhy;ASA manages a local DHCPv6 server to
assign addresses to the CPEs. A central DHCP server acting as the DHCP
delegating router (according to ) is required.
Its address can be another parameter from the GRASP objective.
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&nbhy;ASA sets up a DHCP relay function to pass
on requests to the central DHCP server as in point 1.a.
In a solution without a central DHCP server, the PM-ASA on the
edge routers not only learns parameters from PrefixManager.Params
but also utilizes GRASP to request/negotiate actual IPv6 prefix
delegation via the GRASP PrefixManager objective, as described in more
detail below. In the simplest case, these prefixes are delegated
via this GRASP objective from the PM-ASA in the central device.
This device must be provisioned initially with a large pool of
prefixes. The delegated
prefixes are then used by the PM-ASA on the edge routers to configure prefixes on their downstream interfaces to assign
addresses via RA/SLAAC to host CPEs. The PM-ASA may also start local
DHCP servers (as in point 1.a) to assign addresses via DHCP to the CPEs from the
prefixes it received. This includes both host CPEs requesting IPv6
addresses and router CPEs that request IPv6 prefixes. The
PM-ASA needs to manage the address pool(s) it has requested via GRASP
and allocate sub-address pools to interfaces and the local DHCP
servers it starts. It needs to monitor the address utilization and
accordingly request more address prefixes if its existing prefixes are
exhausted, or return address prefixes when they are unneeded.This solution is quite similar to the previous IPv6 DHCP
deployment model without a central DHCP server, and ANI/ACP/GRASP and
the PM-ASA do provide the automation to make this approach work more
easily than is possible today.
The address pools from which prefixes are allocated do not all
need to be taken from one central location. An edge-router PM&nbhy;ASA
that received a big (short) prefix from a central PM-ASA could offer
smaller sub-prefixes to a neighboring edge-router PM&nbhy;ASA. GRASP could be
used in such a way that the PM-ASA would find and select the objective
from the closest neighboring PM&nbhy;ASA, therefore allowing aggregation to be maximized: a PM&nbhy;ASA would only request further smaller
prefixes when it exhausts its own pool (from the central location) and
cannot get further large prefixes from that central location anymore.
Because the overflow prefixes taken from a topologically nearby PM&nbhy;ASA,
the number of longer prefixes that have to be injected into the
routing tables is limited and the topological proximity increases the
chances that aggregation of prefixes in the IGP can most likely limit
the geography in which the longer prefixes need to be routed.
Instead of peer-to-peer optimization of prefix delegation, a
hierarchy of PM-ASAs can be built (indicated in via a
dotted intermediate router). This would require additional parameters
in the PrefixManager objective to allow the creation of a hierarchy of
PM-ASAs across which the prefixes can be delegated.
In cases where CPEs are also part of the ANI domain (e.g.,
"managed CPEs"), then GRASP will extend into the actual customer sites
and can also run a PM-ASA. All the options described in points 1 to
4 above would then apply to the CPE as the edge router, with the major
changes being that (a) a CPE router will most likely not need to run
DHCPv6-PD itself, but only DHCP address assignment and (b) the edge
routers to which the CPE connects would most likely become ideal places
on which to run a hierarchical instance of PD-ASAs, as outlined in
point 1.
AcknowledgementsValuable comments were received from
,
,
,
,
,
,
,
,
,
,
,
and .