One document matched: draft-ietf-anima-prefix-management-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->
<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
(which supports the latest, sometimes undocumented and under-tested, features.) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<?rfc symrefs="yes"?>
<!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc category="info" docName="draft-ietf-anima-prefix-management-01"
ipr="trust200902">
<front>
<title abbrev="Auto IPv6 Prefix Management">Autonomic IPv6 Edge Prefix
Management in Large-scale Networks</title>
<author fullname="Sheng Jiang" initials="S." role="editor" surname="Jiang">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>Q14, Huawei Campus, No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing, 100095</city>
<country>P.R. China</country>
</postal>
<email>jiangsheng@huawei.com</email>
</address>
</author>
<author fullname="Zongpeng Du" initials="Z." surname="Du">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>Q14, Huawei Campus, No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing, 100095</city>
<country>P.R. China</country>
</postal>
<email>duzongpeng@huawei.com</email>
</address>
</author>
<author fullname="Brian Carpenter" initials="B. E." surname="Carpenter">
<organization abbrev="Univ. of Auckland"></organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<region></region>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
<author fullname="Qiong Sun" initials="Q." surname="Sun">
<organization>China Telecom</organization>
<address>
<postal>
<street>No.118, Xizhimennei Street</street>
<city>Beijing</city>
<code>100035</code>
<country>P. R. China</country>
</postal>
<email>sunqiong@ctbri.com.cn</email>
</address>
</author>
<date day="" month="" year="2016" />
<area>Operations and Management</area>
<workgroup>ANIMA WG</workgroup>
<keyword>Autonomic Networking, Prefix Management</keyword>
<abstract>
<t>This document describes an autonomic solution for IPv6 prefix
management at the edge of large-scale ISP networks. An important purpose
of the document is to use it for validation of the design of various
components of the autonomic networking infrastructure.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This document proposes an autonomic solution for IPv6 prefix
management in large-scale networks. The background to Autonomic
Networking (AN) is described in <xref target="RFC7575"></xref> and <xref
target="RFC7576"></xref>. A generic autonomic signaling protocol (GRASP)
is specified by <xref target="I-D.ietf-anima-grasp"></xref> and would be
used by the proposed autonomic prefix management solution. An important
purpose of the present document is to use it for validation of the
design of GRASP and other components of the autonomic networking
infrastructure described in <xref
target="I-D.ietf-anima-reference-model"></xref>.</t>
<t>This document is not intended to solve all cases of IPv6 prefix
management. In fact, it assumes that the network's main infrastructure
elements already have addresses and prefixes. The document is dedicated
to how to make IPv6 prefix management at the edges of large-scale
networks as autonomic as possible. It is specifically written for
service provider (ISP) networks. Although there are similarities between
ISPs and large enterprise networks, the requirements for the two use
cases differ.</t>
<t>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.</t>
<t>Note in draft: This version is preliminary. In particular, many
design details may be subject to change until the Anima specifications
become agreed.</t>
</section>
<!-- intro -->
<section anchor="term" title="Terminology">
<t><list style="hanging">
<t hangText="Autonomic Service Agent (ASA)">An agent implemented on
an autonomic node that implements an autonomic function, either in
part (in the case of a distributed function) or whole. Defined in
<xref target="RFC7575"></xref>.</t>
</list></t>
</section>
<!-- term -->
<section anchor="problem" title="Problem Statement">
<t>The autonomic networking use case considered here is autonomic IPv6
prefix management at the edge of large-scale ISP networks.</t>
<t>Although DHCPv6 Prefix Delegation <xref target="RFC3633"></xref>
supports automated delegation of IPv6 prefixes from one router to
another, prefix management is still largely depending 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
locally defined or could be generic (edge router, interior router,
etc.). Furthermore, IPv6 prefix management by humans tends to be rigid
and static after initial planning.</t>
<t>The problem to be solved by autonomic networking is how to
dynamically manage IPv6 address space in large-scale networks, so that
IPv6 addresses can be used efficiently. Here, we limit the problem to
assignment of prefixes at the edge of the network, close to access
routers that support individual fixed-line subscribers, mobile
customers, and corporate customers. We assume that the core
infrastructure of the network has already been established with
appropriately assigned prefixes. The AN approach discussed in this
document is based on the assumption that there is a generic discovery
and negotiation protocol that enables direct negotiation between
intelligent IP routers. GRASP <xref
target="I-D.ietf-anima-grasp"></xref> is intended to be such a
protocol.</t>
<section anchor="experience"
title="Intended User and Administrator Experience">
<t>The intended experience is, for the administrator(s) of a
large-scale network, that the management of IPv6 address space at the
edge of the network can be run with minimum efforts, 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 administrator(s) 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.</t>
<t>The actual prefix usage needs to be logged for potential offline
management operations including audit and security incident
tracing.</t>
</section>
<section anchor="params"
title="Analysis of Parameters and Information Involved">
<t>For specific purposes of address management, a few parameters are
involved on each edge device (some of them can be pre-configured
before they are connected). They include:</t>
<t><list style="symbols">
<t>Identity, authentication and authorization of this device. This
is expected to use the autonomic networking secure bootstrap
process <xref
target="I-D.ietf-anima-bootstrapping-keyinfra"></xref>, following
which the device could safely take part in autonomic
operations.</t>
<t>Role of this device.</t>
<t>An IPv6 prefix length for this device.</t>
<t>An IPv6 prefix that is assigned to this device and its
downstream devices.</t>
</list>A few parameters are involved in the network as a whole. They
are:</t>
<t><list style="symbols">
<t>Identity of a trust anchor, which is a certification authority
(CA) maintained by the network administrator(s), used during the
secure bootstrap process.</t>
<t>Total IPv6 address space available for edge devices. It is one
(or several) IPv6 prefix(es).</t>
<t>The initial prefix length for each device role.</t>
</list></t>
<section anchor="device"
title="Parameters each device can decide for itself">
<t>This section identifies those of the above parameters that do not
need external information in order for the devices concerned to set
them to a reasonable value after bootstrap or after a network
disruption. There are few of these:</t>
<t><list style="symbols">
<t>Role of this device.</t>
<t>Default IPv6 prefix length for this device.</t>
<t>Identity of this device.</t>
</list>The device may be shipped from the manufacturer with
pre-configured role and default prefix length, which could be
modified by an autonomic mechanism.</t>
</section>
<!-- device -->
<section anchor="intent" title="Information needed from policy intent">
<t>This section identifies those parameters that need external
information about policy intent in order for the devices concerned
to set them to a non-default value.</t>
<t><list style="symbols">
<t>Non-default value for the IPv6 prefix length for this device.
This needs to be decided based on the role of this device.</t>
<t>The initial prefix length for each device role.</t>
<t>Whether to allow the device request more address space.</t>
<t>The policy when to request more address space, for example,
if the address usage reaches a certain limit or percentage.</t>
</list></t>
</section>
<section anchor="compare" title="Comparison with current solutions">
<t>This section briefly compares the above use case with current
solutions. Currently, the address management is still largely
dependent on human planning. It is rigid and static after initial
planning. Address requests will fail if the configured address space
is used up.</t>
<t>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. Some functions are not suitable to be achieved by any existing
protocols.</t>
<t>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.</t>
</section>
<!-- intent -->
</section>
<section anchor="interact" title="Interaction with other devices">
<section anchor="peers" title="Information needed from other devices">
<t>This section identifies those of the above parameters that need
external information from neighbor devices (including the upstream
devices). In many cases, two-way dialogue with neighbor devices is
needed to set or optimize them.</t>
<t><list style="symbols">
<t>Identity of a trust anchor.</t>
<t>The device will need to discover a device, from which it can
acquire IPv6 address space.</t>
<t>The initial prefix length for each device role, particularly
for its own downstream devices.</t>
<t>The default value of the IPv6 prefix length may be overridden
by a non-default value.</t>
<t>The device will need to request and acquire IPv6 prefix that
is assigned to this device and its downstream devices.</t>
<t>The device may respond to prefix delegation request from its
downstream devices.</t>
<t>The device may require to be assigned more IPv6 address
space, if it used up its assigned IPv6 address space.</t>
</list></t>
</section>
<!-- peers -->
<section anchor="monitor"
title="Monitoring, diagnostics and reporting">
<t>This section discusses what role devices should play in
monitoring, fault diagnosis, and reporting.</t>
<t><list style="symbols">
<t>The actual address assignments need to be logged for the
potential offline management operations.</t>
<t>In general, the usage situation of address space should be
reported to the network administrators, in an abstract way, for
example, statistics or visualized report.</t>
<t>A forecast of address exhaustion should be reported.</t>
</list></t>
</section>
<!-- monitor -->
</section>
</section>
<section title="Autonomic Edge Prefix Management Solution">
<t>This section introduces an autonomic edge prefix management solution.
It uses the generic discovery and negotiation protocol defined by <xref
target="I-D.ietf-anima-grasp"></xref>. The relevant options are defined
in <xref target="prefixNegoOptions"></xref>.</t>
<t>The procedures described below are carried out by an Autonomic
Service Agent (ASA) in each device that participates in the solution. We
will refer to this as the PrefixManager ASA.</t>
<t></t>
<section title="Behaviors on prefix requesting device">
<t>If the device containing an 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 by the
intent-based mechanism, described in <xref
target="prefixManageIntent"></xref>.</t>
<t>An 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
an PrefixManager Objective option <xref
target="prefixObjOption"></xref> in order to discover peers also
supporting that option. Then it should choose one such peer, most
likely the first to respond.</t>
<t>If the GRASP discovery Response message carries a divert option
pointing to an off-link PrefixManager ASA, the requesting ASA may
initiate negotiation with that ASA diverted device to find out whether
it can provide the requested length prefix.</t>
<t>In any case, the requesting ASA will act as a GRASP negotiation
initiator by sending a GRASP Request message with an PrefixManager
Objective option. The ASA indicates in this option both the length of
the requested prefix and whether the ASA supports the DHCPv6 Prefix
Delegation (PD) function <xref target="RFC3633"></xref>. This starts a
GRASP negotiation process.</t>
<t>During the subsequent negotiation, the ASA will decide at each step
whether to accept the offered prefix. That decision, and the decision
to end negotiation, is an implementation choice.</t>
<t>The ASA could alternatively initiate rapid mode GRASP discovery
with an embedded negotiation request, if it is implemented.</t>
</section>
<section title="Behaviors on prefix providing device">
<t>A device that receives a Discovery message with an PrefixManager
Objective option should respond with a GRASP Response message if it
contains an PrefixManager ASA. Further details of the discovery
process are described in <xref target="I-D.ietf-anima-grasp"></xref>.
When this ASA receives a subsequent Request message it should conduct
a GRASP negotiation sequence, using Negotiate, Confirm-waiting, and
Negotiation-ending messages as appropriate. The Negotiate messages
carry an PrefixManager Objective option. This will indicate whether
the sending device supports the PD function. More importantly, it will
indicate the prefix and its length offered to the requesting ASA. As
described in <xref target="I-D.ietf-anima-grasp"></xref>, negotiation
will continue until either end stops it with a Negotiation-ending
message. If the negotiation succeeds, the prefix providing ASA will
remove the negotiated prefix from its pool, and the requesting ASA
will add it. If the negotiation fails, the party sending the
Negotiation-ending message may include an error code string.</t>
<t>During the negotiation, the ASA will decide at each step how large
a prefix to offer. That decision, and the decision to end negotiation,
is an implementation choice.</t>
<t>The ASA could alternatively negotiate in response to rapid mode
GRASP discovery, if it is implemented.</t>
<t>This specification is independent of whether the PrefixManager ASAs
are all embedded in routers, but that would be a rather natural
scenario. A gateway router in a hierarchical network topology normally
provides prefixes for routers within its subnet, and it is likely to
contain the first PrefixManager ASA discovered by its downstream
routers. However, the GRASP discovery model, including its Redirect
feature, means that this is not an exclusive scenario, and a
downstream PrefixManager ASA could negotiate a new prefix with a
router other than its upstream router.</t>
<t>A resource shortage may cause the gateway router to request more
resource in turn from its own upstream device. This would be another
independent GRASP discovery and negotiation process. During the
processing time, the gateway router should send a Confirm-waiting
Message to the initial requesting router, to extend its timeout. When
the new resource becomes available, the gateway router responds with a
GRASP Negotiate message with a prefix length matching the request.</t>
<t>The algorithm to choose which prefixes to assign on the prefix
providing devices is an implementation choice.</t>
</section>
<section title="Behavior after Successful Negotiation">
<t>Upon receiving a GRASP Negotiation-ending message that indicates
that an acceptable prefix length is available, the requesting device
may request the prefix using DHCPv6 PD, if both ASAs have indicated
that they are within a device that supports PD. Otherwise, it is
permissible for the initiating ASA to use the negotiated prefix
without further messages.</t>
<t>[Author's note: It is not intended to undermine DHCPv6 PD. But in
fact, if PD is not supported and the GRASP negotiation has succeeded,
there should be no problem with this and it seems consistent as a
solution.]</t>
<t><!--[Author's note: undecided between PDrequest-failure-negotiation (the current description) or negotiation-PDrequest models.]
For now, replaced by discovery (negotiation length) - PDrequest.
Report Prefix Status (not included for now). This may have information leak issues.--></t>
</section>
<section title="Prefix logging">
<t>Within the autonomic prefix management, all the prefix assignment
is done by devices without human intervention. It is therefore
important to record all the prefix assignment history. However, the
logging and reporting process is out of scope for this
specification.</t>
</section>
</section>
<section anchor="prefixNegoOptions"
title="Autonomic Prefix Management Options">
<t>This section defines the GRASP options that are used to support
autonomic prefix management.</t>
<section anchor="prefixObjOption" title="Edge Prefix Objective Option">
<t>The PrefixManager Objective option is a GRASP objective option
conforming to <xref target="I-D.ietf-anima-grasp"></xref>. Its name is
"PrefixManager" (see <xref target="iana"></xref>) and it carries up to
three data items as its value: the PD support flag, the prefix length,
and the actual prefix bits. The format of the PrefixManager Objective
option is described as follows in CBOR data definition language (CDDL)
<xref target="I-D.greevenbosch-appsawg-cbor-cddl"></xref>:</t>
<figure>
<artwork><![CDATA[
objective = ["PrefixManager", objective-flags, loop-count,
PD-support, length, ?prefix]
loop-count = 0..255 ; as in the GRASP specification
objective-flags /= ; as in the GRASP specification
PD-support = true / false ; indicates whether sender supports PD
length = 0..128 ; requested or offered prefix length
prefix = bytes .size 16 ; offered prefix in binary format
]]></artwork>
</figure>
</section>
</section>
<section anchor="prefixManageIntent" title="Prefix Management Intent">
<t>With in a single administrative domain, the network operator could
provide intent 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 human intervention or configuration files.</t>
<t>For example, the network operator could define the default prefix
length for each type of role. A prefix management intent, which contains
all mapping information of device roles and their default prefix
lengths, should be flooded in the network, through the Autonomic Control
Plane (ACP) <xref
target="I-D.ietf-anima-autonomic-control-plane"></xref>. The intent
flooding mechanism is not yet defined, but one possibility would be
define a suitable GRASP synchronization objective and flood it through
the network. To make this concrete, there could be an objective defined
as follows:</t>
<figure>
<artwork><![CDATA[
objective = ["Intent.PrefixManager", objective-flags, text]
loop-count = 0..255 ; as in the GRASP specification
objective-flags /= ; as in the GRASP specification
;The text object would be the relevant intent statements (such
;as the example below) transmitted as a single string with all
;whitespace and format characters removed.
]]></artwork>
</figure>
<t>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
synchronization. Upon receiving the prefix management intent, every
device can decide its default prefix length by matching its own
role.</t>
<section title="Example of Prefix Management Intent">
<t>The prefix management intent in this document is used to carry
mapping information of device roles and their default prefix lengths
in an autonomic domain. For example, an IPRAN operator wants to
configure the prefix length of RNC Site Gateway (RSG) as 34, the
prefix length of Aggregation Site Gateway (ASG) as 44, and the prefix
length of Cell Site Gateway (CSG) as 56. She/he may input the
following intent into the autonomic network:</t>
<figure>
<artwork><![CDATA[{"autonomic_intent":
[
{"model_version": "1.0"},
{"intent_type": "Network management"},
{"autonomic_domain": "Customer_X_intranet"},
{"intent_name": "Prefix management"},
{"intent_version": 73},
{"Timestamp": "20150606 00:00:00"},
{"Lifetime": "Permanent"},
{"signature": "XXXXXXXXXXXXXXXXXXX"},
{"content":
[
{"role": [{"role_name": "RSG"},
{"role_characteristic":
[{"prefix_length": "34"}]}
]},
{"role": [{"role_name": "ASG"},
{"role_characteristic":
[{"prefix_length": "44"}]}
]},
{"role": [{"role_name": "CSG"},
{"role_characteristic":
[{"prefix_length": "56"}]}
]}
]
}
]
}
]]></artwork>
</figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>Relevant security issues are discussed in <xref
target="I-D.ietf-anima-grasp"></xref>. The preferred security model is
that devices are trusted following the secure bootstrap procedure <xref
target="I-D.ietf-anima-bootstrapping-keyinfra"></xref> and that a secure
Autonomic Control Plane (ACP) <xref
target="I-D.ietf-anima-autonomic-control-plane"></xref> is in place.</t>
<t>It is RECOMMENDED that DHCPv6 PD, if used, should be operated using
DHCPv6 authentication or Secure DHCPv6.</t>
</section>
<!-- security -->
<section anchor="iana" title="IANA Considerations">
<t>This document defines one new GRASP Objective Option name,
"PrefixManager". The IANA is requested to add this to the GRASP
Objective Names Table registry defined by <xref
target="I-D.ietf-anima-grasp"></xref> (if approved).</t>
</section>
<!-- iana -->
<section anchor="ack" title="Acknowledgements">
<t>Valuable comments were received from Michael Behringer, Joel Halpern,
and Chongfeng Xie.</t>
<t>This document was produced using the xml2rfc tool <xref
target="RFC2629"></xref>.</t>
</section>
<!-- ack -->
<section anchor="changes" title="Change log [RFC Editor: Please remove]">
<t>draft-jiang-anima-prefix-management-00: original version,
2014-10-25.</t>
<t>draft-jiang-anima-prefix-management-01: add intent example and
coauthor Zongpeng Du, 2015-05-04.</t>
<t>draft-jiang-anima-prefix-management-02: update references and the
format of the prefix management intent, 2015-10-14.</t>
<t>draft-ietf-anima-prefix-management-00: WG adoption, clarify scope and
purpose, update text to match latest GRASP spec, 2016-01-11.</t>
<t>draft-ietf-anima-prefix-management-01: minor update, 2016-07-08.</t>
</section>
<!-- changes -->
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.I-D.ietf-anima-grasp'?>
<?rfc include='reference.I-D.greevenbosch-appsawg-cbor-cddl'?>
<?rfc include='reference.I-D.ietf-anima-bootstrapping-keyinfra'?>
<?rfc include='reference.I-D.ietf-anima-autonomic-control-plane'?>
<?rfc include='reference.RFC.3633'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2629'?>
<?rfc include='reference.RFC.7575'?>
<?rfc include='reference.RFC.7576'?>
<?rfc include='reference.I-D.ietf-anima-reference-model'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:19:18 |