One document matched: draft-jiang-anima-prefix-management-02.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-jiang-anima-prefix-management-02"
ipr="trust200902">
<front>
<title abbrev="Auto Prefix Management">Autonomic 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"/>
<address>
<postal>
<street>Department of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<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="2015"/>
<area>Operations and Management</area>
<workgroup>ANIMA WG</workgroup>
<keyword>Autonomic Networking, Prefix Management</keyword>
<abstract>
<t>This document describes an autonomic solution for prefix management
in large-scale networks.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This document proposes an autonomic solution for prefix management in
large-scale networks. The background to Autonomic Network (AN) is
described in <xref target="RFC7575"/> and <xref target="RFC7576"/>. A
generic autonomic signaling protocol (GRASP) is proposed by <xref
target="I-D.ietf-anima-grasp"/>, which would be used by the proposed
autonomic prefix management solution.</t>
<t>This document is dedicated to how to make IPv6 prefix management in
pure IPv6 large-scale networks as autonomic as possible. This document
for now is only considering service provider (ISP) networks. Although
there are similarities with large enterprise networks, the requirements
are a little different for the two use cases.</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="problem" title="Problem Statement">
<t>The autonomic networking use case considered here is autonomic IP
address management in large-scale networks.</t>
<t>Although DHCPv6 Prefix Delegation <xref target="RFC3633"/> has
supported automated delegation of IPv6 prefixes, 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, the current IPv6
prefix management by humans is rigid and static after initial
planning.</t>
<t>The problem to be solved by AN is how to dynamically and
autonomically manage IPv6 address space in large-scale networks, so that
IPv6 addresses can be used efficiently. 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. <xref target="I-D.ietf-anima-grasp"/> is
one of the attempts at 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 can be
run with minimum efforts, for both the network and network device
initiation stage and during running time. In the ideal scenario, the
administrator(s) only have to configure a single IPv6 prefix for the
whole network and the initial prefix length for each device role.</t>
<t>The actual address 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 device (some of them can be pre-configured before
they are connected). They include:</t>
<t><list style="symbols">
<t>Identity of this device. It can be verified by the
certification authority (CA) that is maintained by the network
administrator(s).</t>
<t>Identity of a trust anchor which is certification authority
(CA) that is maintained by the network administrator(s).</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) that is maintained by the network administrator(s).</t>
<t>Total IPv6 address space. 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 manufacture with
pre-configured role and default prefix length.</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>Identity of a trust anchor.</t>
<t>Whether to allow the device request more address space.</t>
<t>The policy when to request more address space, for example,
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
depending on human planning. It is rigid and static after initial
planning. The address requests will fail if the configured address
space is used up.</t>
<t>Some functions, for autonomic and dynamic address management, may
be achievable by extending the existing protocols, for example,
extending DHCPv6-PD to request IPv6 address 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>However, 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 Prefix Management Solution">
<t>This section introduces an autonomic prefix management solution. It
extends the generic discovery and negotiation protocol defined by <xref
target="I-D.ietf-anima-grasp"/>. The relevant options are defined in
<xref target="prefixNegoOptions"/>.</t>
<t/>
<section title="Behaviors to discover prefix providing device">
<t>A device should decide the length of request prefix by <!--either pre-configuration or-->the
intent-based mechanism, described in <xref
target="prefixManageIntent"/>. If it used up its current address
resource, it could request more, which is not necessary to be on the
same scale as its initial resource.</t>
<t>A prefix requesting device that needs new or more address space
should firstly discover peer devices that may be able to provide extra
address space. The device should send out a GRASP Discovery message
that contains a Prefix Objective option <xref
target="prefixObjOption"/>, in which the device also indicates whether
it supports the DHCPv6 Prefix Delegation (PD) <xref target="RFC3633"/>
function and the length of requested prefix.</t>
</section>
<section title="Behaviors on prefix providing device">
<t>A peer device receiving a Discovery message with a Prefix Objective
option, if it is able to provide such a prefix, should respond with a
GRASP Response message. The Response message also carries a Prefix
Objective option, which also indicate whether the peer device supports
the PD function and the available prefix length matching the request.
If the peer device does not have enough resource, it may silently drop
the Discovery message or return a GRASP Response message, which
contains a longer prefix length (smaller address space) that it can
provide. A divert option may also be added into the GRASP Response
message. This divert option indicates another device that may provide
the prefix. The diverted device is typically an upstream gateway
router, but it could in theory be any device that might have unused
prefix space.</t>
<t>A gateway router in a hierarchical network topology is normally
responsible to provide prefixes for routers within its subnet. In the
case that it does not have enough resource for the downstream
requesting router, it should return a GRASP Response message, which
contains a longer prefix length (smaller address space) that this
gateway router may provide. In this case too, a divert option may be
added into the GRASP Response message. The diverted device is
typically another upstream gateway router.</t>
<t>A resource shortage may cause the gateway router to request more
resource from its upstream device. This would be another independent
GND discovery and negotiation process. During the processing time, the
gateway router should send a Confirm-waiting Message to the initial
requesting router. When the new resource becomes available, the
gateway router responds with a GRASP Response message with the prefix
length matching the request.</t>
<t>The algorithm to choose which prefixes to assign on the prefix
providing devices is an implementation choice out of document
scope.</t>
</section>
<section title="Prefix Requests Behaviors">
<t>Upon receiving the GRASP Response message that indicates the
requesting prefix length is accepted, the requesting device may
request the prefix using DHCPv6 PD, if both itself and the response
device support PD.</t>
<t>Upon receiving the GRASP Response message that indicates the
requesting prefix length is not possible, but a longer prefix length
is available, the requesting device may request the longer prefix
using DHCPv6 PD, if both itself and the response device support
PD.</t>
<t>If the GRASP Response message carries a divert option, the
requesting device may sent an unicast GRASP Discovery message to the
diverted device to find out whether that device can provide the
requested length prefix.</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-->[Author's
note: undecided whether we should support prefix delegation using the
GRASP protocol. This would have some partial overlap with DHCPv6 PD.
But it seems more consistent as a solution.]</t>
<t><!--Report Prefix Status (not included for now). This may have information leak issues.--></t>
</section>
<section title="Prefix log">
<t>Within the autonomic prefix management, all the prefix assignment
is done by devices without human intervention. It is even more
important to record all the prefix assignment history. However, the
logging and reporting process is out of document scope.</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="Prefix Objective option">
<t>The Prefix Objective option carries the PD support flag and the
prefix length. The format of the Prefix Objective option is described
as follows:<figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix_Obj_Option | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PD_Support_Flag| Prefix_Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code Prefix_Obj_Option (TBA1).
option-len 2, length of option content in octets.
PD_Support_Flag Indicates whether the message sender supports
DHCPv6 Prefix Delegation function, 1 for support,
0 for no support, as client or server accordingly.
This flag must not be set to any other values.
Prefix_Length Indicate the prefix length that the message sender
requests or is willing to provide.
]]></artwork>
</figure></t>
<t/>
</section>
</section>
<section anchor="prefixManageIntent" title="Prefix Management Intent">
<t>With in a single administrative domain, the network operator could
manage all their devices with role set. If so, there is possibility to
configure/manage the prefix length for every device in a simple way.</t>
<t>The network operator could only manage 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"/>. The
intent flooding mechanism is out of document scope.</t>
<t>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"/>. The security mechanism in this document
is established on a Public Key Infrastructure (PKI) system <xref
target="RFC3647"/> that is maintained by the network
administrator(s).</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 option. The IANA is requested to
assign a value for this option from the GRASP Option Codes table of the
GRASP Parameters registry as defined by <xref
target="I-D.ietf-anima-grasp"/> (if approved).</t>
<t><list style="symbols">
<t>The Prefix Objective option (TBA1), described in <xref
target="prefixObjOption"/>.</t>
</list></t>
</section>
<!-- iana -->
<section anchor="ack" title="Acknowledgements">
<t>Valuable comments were received from Michael Behringer and Chongfeng
Xie.</t>
<t>This document was produced using the xml2rfc tool <xref
target="RFC2629"/>.</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>
</section>
<!-- changes -->
</middle>
<back>
<references title="References">
<?rfc include='reference.RFC.2629'?>
<?rfc include='reference.RFC.3647'?>
<?rfc include='reference.RFC.3633'?>
<?rfc include='reference.RFC.7575'?>
<?rfc include='reference.RFC.7576'?>
<?rfc include='reference.I-D.ietf-anima-grasp'?>
<?rfc include='reference.I-D.ietf-anima-autonomic-control-plane'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 14:12:23 |