One document matched: draft-yeh-dhc-dhcpv6-prefix-pool-opt-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY RFC3769 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3769.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-yeh-dhc-dhcpv6-prefix-pool-opt-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902, or pre5378Trust200902 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters -->
<title abbrev="DHCPv6 Prefix Pool Option">Prefix Pool Option for DHCPv6 Relay Agent</title>
<author fullname="Leaf Y. Yeh" initials="L." role="editor" surname="Yeh">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Area F, Huawei Park, Bantian</street>
<city>Longgang District</city>
<region>Shenzhen</region>
<code>518129</code>
<country>P.R.China</country>
</postal>
<phone>+86-755-28971871</phone>
<email>leaf.y.yeh@huawei.com</email>
</address>
</author>
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies</organization>
<address>
<email>tena@huawei.com</email>
</address>
</author>
<author fullname="Jie Hu" initials="J." surname="Hu">
<organization>China Telecom</organization>
<address>
<postal>
<street>No.118, Xi Zhi Men-Nei Da Jie</street>
<city>Xicheng District</city>
<region>Beijing</region>
<code>100035</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-58552808</phone>
<email>huj@ctbri.com.cn</email>
</address>
</author>
<author fullname="Qiong Sun" initials="Q." surname="Sun">
<organization>China Telecom</organization>
<address>
<email>sunqiong@ctbri.com.cn</email>
</address>
</author>
<date year="2010" />
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>DHC</workgroup>
<keyword>DHCPv6</keyword>
<keyword>Prefix Pool</keyword>
<keyword>Aggregation Route</keyword>
<abstract>
<t>The Prefix Pool option provides an automatic mechanism for the messages exchange between DHCPv6 server and DHCPv6 Relay Agent. The information about Prefix Pools maintained on DHCPv6 server can be transferred from server to relay agent through this DHCPv6 option to support the necessary route aggregation on the provide edge router, which has a huge number of routes pointing to the customer networks before.</t>
</abstract>
</front>
<!-- ***** MIDDLE MATTER ***** -->
<middle>
<section anchor="s1" title="Introduction">
<t>DHCPv6 Relay Agents <xref target="RFC3315"/> are deployed to relay messages between clients and servers when they are not on the same link, and are often implemented along with a routing function on the provider edge (PE) routers <xref target="BBF WT-177"/>. Meanwhile, the PE router always employ the DHCPv6 Prefix Delegation <xref target="RFC3633"/> as the mechanism for the automated delegation of IPv6 prefix to the customer network.</t>
<t>In order to make the customer network to be reachable in the IPv6 network, the PE routers always need to add or remove the route entry directing to each customer network in its routing table per the messages between DHCPv6 Server (Delegation Router) and Customer router (CPE, DHCPv6 Client, DHCPv6 Requesting Router) when the PE router acts as DHCPv6 Relay Agent <xref target="BBF WT-177"/>. </t>
<t>When the routing protocol is enabled on the network-facing interface of the PE router, all the routes directing to the customer networks are supposed to advertise in the ISP core network. This will make the number of entries in the routing table on the ISP core router to be unacceptable huge, so that it is necessary to aggregate the routes directing to the customer networks on the PE router. </t>
<t>Because the prefixes of the customer networks can not guarantee always to be valid and continuous, the routing protocol on the PE router can not make one aggregation route automatically to cover all the prefixes delegated to the customer networks, which are associated to the same client-facing link of the PE. On the other hand, the information of the prefix pools associated to each client-facing interface of PEs is always maintained on the DHCPv6 server. </t>
<t>When the PE router acts as the DHCPv6 Server, the aggregation routes (eg. black-hole routes) can be generated by the information of the prefix pools directly, but when the PE router acts as the DHCPv6 Relay Agent, a new mechanism to transfer the information of the prefix pools from the server to the relay agent for each client-facing interface of the PE is requested.</t>
<t>After the PE got the information of the prefix pools associated to its client-facing interfaces, the aggregation route entries pointing to each of the prefix pools can be added or withdrawed in the routing table of PE. When the routing protocol is enabled on PE's network-facing interface, the above aggregation route pointing to all of the customer networks attached on the same link of the PE's client-facing interface will be advertised to the whole ISP network.</t>
</section>
<section anchor="s2" title="Terminology and Language">
<t>This document describes new DHCPv6 options of prefix pool and the associated mechanism for the configuration on the Relay Agent. This document should be read in conjunction with the DHCPv6 specification, RFC 3315 and RFC 3633, for a complete mechanism. Definitions for terms and acronyms not specifically defined in this document are defined in RFC 3315, RFC 3633 and RFC 3769 <xref target="RFC3769"/>.</t>
<t>The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 <xref target="RFC2119"/>.</t>
</section>
<section anchor="s3" title="Scenario and Network architecture">
<t>The following figure illustrates a typical ISP-Customer network architecture.</t>
<figure anchor="f1" title="An example of ISP-Customer network architecture">
<artwork>
+------+------+
| DHCPv6 | DHCPv6-PD Delegating Router
| Server | (eg. binding entry:
+------+------+ pe#1_cfi#2 < - > 3ffe:ffff:0::/40)
_________|_________
/ \
| ISP Core Network |
\___________________/
|
| Network-facing interface
+------+------+
| PE | Provider Edge Router
| | DHCPv6 Relay Agent
+------+------+
| Client-facing interface (Interface ID)
| (eg. interface_id=pe#1_cfi#2;
| prefix pool=3ffe:ffff:1200::/40)
_________|_________
/ \
| Access Network |
\___________________/
|
+------+------+ Customer Router
| CPE | DHCPv6 Client
| | DHCPv6-PD Requesting Router
+------+------+ (eg. customer network
| =3ffe:ffff:1234:5600:/56)
_________|_________
/ \
| Customer Network |
\___________________/
</artwork>
</figure>
</section>
<section anchor="s4" title="Prefix Pool option">
<t>The format of the Prefix Pool option is:</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PREFIX_POOL | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pfx-pool-len | |
+-+-+-+-+-+-+-+-+ IPv6 prefix +
| (16 octets) |
| |
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_PREFIX_POOL (TBD)
option-length: 18
pfx-pool-len: Length for the prefix pool in bits
IPv6 prefix: IPv6 prefix of the prefix pool
Status: Status of the prefix pool
</artwork>
</figure>
<t>The Status field in the Prefix Pool option indicates the availability of the prefix pool maintained on the Server. The code of the Status is defined in the following table.</t>
<figure><artwork>
Name Code
Valid 0
Released 1
Reserved 2~255
</artwork></figure>
</section>
<section anchor="s5" title="Relay Agent Behavior">
<t>The Relay Agent who needs the information of prefix pools from the server, shall includes Option Request Option (OPTION_ORO, 6) to request Prefix Pool option from the server, who maintains the status of the prefix pools associated to the particular client-facing interface of the Relay Agent where receiving the message from clients. The Relay Agent may include the ORO for Prefix Pool Option in the relay-forward (12) message of SOLICIT (1), REQUEST (3), RENEW (5), REBIND (6) and RELEASE (8).</t>
<t>The Relay Agent should includes Interface ID option (OPTION_INTERFACE_ID, 18) for the server to identify the associated interface on which the prefix pool is configured, if the Server would not like to use link-address specified in the DHCPv6 message encapsulation of relay-forward message to identify the interface of the link on which clients are located. </t>
<t>After received the Prefix Pool option for that particular client-facing interface in the relay-reply message (13) message of REPLY (7) from the server, the Relay Agent shall add or remove the aggregation route entry per the status of the prefix pool. If the status of the prefix pool got from the server is 'Valid', the Relay Agent shall add an aggregation route entry in its routing table if the same entry has not been added in. If the status of the prefix pool got from he server is 'Released', the Relay Agent shall withdraw the associated aggregation route entry in its routing table.</t>
<t>The Relay Agent advertises its routing table including the entries of the aggregation routes based on the information of prefix pools when the routing protocol is enabled on its network-facing interface.</t>
</section>
<section anchor="s6" title="Server Behavior">
<t>Per RFC3633, if the prefix of the customer network associated to the IA_PD option in relay-forward message of SOLICIT , REQUEST, RENEW, REBIND is indicated to be valid on the Server, the Server (delegating router) will delegate the prefix of the customer network with the relevant parameters to the client (requesting router, customer router) in the relay-reply message of REPLY.</t>
<t>The Server shall use the Interface ID included in the relay-forward message by the relay agent to identify the client-facing interface of the relay agent on which the associated prefix pool will be configured. Per RFC3315, the Server may include the same Interface ID option in the relay-reply message.</t>
<t>After receives the ORO in the relay-forward message, the Server must include Prefix Pool option with the status indicated for the associated client-facing interface of the relay agent in the relay-reply message of REPLY.</t>
<t>The status of 'Valid' in the Prefix Pool option can be used to set up the prefix pool and the associated aggregation route on the relay agent; while the status of 'Released' in the Prefix Pool option can be used to withdraw the configuration of the prefix pool and the associated aggregation route on the relay agent.</t>
<t>On the other hand, if the prefix of the customer network associated to the IA_PD option in the relay-forward message of RELEASE is the last releasing prefix within the associated prefix pool, the Server (delegating router) shall turn the status of the associated prefix pool to be 'Released'. After receives the ORO in the relay-forward message, the Server must include Prefix Pool option with the status of 'Released' for the associated client-facing interface of the relay agent in the relay-reply message of REPLY.</t>
<t>Note that multiple prefix pools may associate with the same client-facing interface of the PE router implementing Relay Agent in the binding table on the Server, and the status of the prefix pools associated to each of client-facing interface of the PE router implementing Relay Agent in the binding table can be reset by the administrator of the Server.</t>
<t>When the status of prefix pool is reset by manual configuration, the Server shall initiate the relay-reply message of RECONFIGURE (10), if there is at least one prefix indicated to be valid within the associated prefix pool on the Server.</t>
</section>
<section anchor="s7" title="Security Considerations">
<t>Security issues related DHCPv6 are described in section 23 of RFC 3315.</t>
</section>
<section anchor="s8" title="IANA Considerations">
<t>IANA is requested to assign an option code to Option_Prefix_Pool from the "DHCPv6 and DHCPv6 options" registry (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml).</t>
</section>
</middle>
<!-- ***** BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC3315;
&RFC3633;
&RFC3769;
&RFC2119;
</references>
<references title="Informative References">
<reference anchor='BBF WT-177'>
<front>
<title>IPv6 in the context of TR-101, Rev.16, Straw Ballot</title>
<author initials='' surname='Broadband Forum' fullname='' />
<date year='2010' month='September' />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:24:23 |