One document matched: draft-yeh-dhc-dhcpv6-prefix-pool-opt-05.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">
<!ENTITY RFC5007 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5007.xml">
<!ENTITY RFC5460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5460.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 ttp://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-05" 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 Agents on Provider Edge Routers</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>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>tena@huawei.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Juergen Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization>Jacobs University Bremen</organization>
<address>
<postal>
<street>Campus Ring 1</street>
<city>Bremen</city>
<code>28759</code>
<country>Germany</country>
</postal>
<email>j.schoenwaelder@jacobs-university.de</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>
<date year="2011" />
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>DHC Working Group</workgroup>
<keyword>DHCPv6</keyword>
<keyword>Prefix Pool</keyword>
<keyword>Aggregation Route</keyword>
<abstract>
<t>The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 relay agent implemented on a Provider Edge (PE) router about active prefix pools allocated by the DHCPv6 server to the PE router. The information of active prefix pools can be used to enforce IPv6 route aggregation on the PE router by adding or removing aggregated routes according to the status of the prefix pools. The advertising of the aggregated routes in the routing protocol enabled on the network-facing interface of PE routers will dramatically decreases the number of the routing table entries in the network.</t>
</abstract>
</front>
<!-- ***** MIDDLE MATTER ***** -->
<middle>
<section anchor="s1" title="Introduction">
<t>The DHCPv6 protocol <xref target="RFC3315"/> specifies a mechanism for the assignment of IPv6 address and configuration information to IPv6 nodes. The DHCPv6 Prefix Delegation (DHCPv6-PD) <xref target="RFC3633"/> specifies a mechanism for the delegation of IPv6 prefixes from the Delegating Router (DR) acting as the DHCPv6 server to the Requesting Routers (RR) acting as the DHCPv6 Clients. DHCPv6 servers always maintain authoritative information related to their operations including, but not limited to, binding data of the delegated IPv6 prefixes, lease data of the delegated IPv6 prefixes, and binding data of their prefix pools. A prefix pool configured and maintained on the server can usually be a short prefix (e.g., a /40 prefix) out of which the longer prefixes (e.g., /56 prefixes) are delegated to customer networks.</t>
<t>In the scenario of a centralized DHCPv6 server, the Provider Edge (PE) routers act as DHCPv6 relay agents when the DHCPv6 server acting as DR and the DHCPv6 clients acting as RRs are not on the same link. For ensuring reachability, the PE routers always need to add or withdraw the route entries directing to each customer network in their routing table to reflect the status of IPv6 prefixes delegated by the DHCPv6 server to customer routers (a.k.a. Routed-RG or Routed-CPE), which acts as RRs (see Section 6.2, <xref target="BBF TR-177"/>).</t>
<t>When a routing protocol is enabled on the network-facing interface of the PE router, all the routes directing to the customer networks are advertised in the ISP network. This will make the number of route entries in the routing table on the ISP router unacceptable large. Hence, it is desirable to aggregate the routes directing to the customer networks on the PE router.</t>
<t>Because the prefixes of the customer networks can not be guaranteed to be valid and continuous, the routing protocol enabled on the PE router in general can not create one aggregated route automatically to cover all the prefixes delegated within the prefix pool. One way to make the aggregated routes is to configure them manually and permanently per the provision of the prefix pools, but the PE router generally does not know about the prefix pools when it acts as the relay agent.</t>
<t> This document proposes a new Prefix Pool option for the DHCPv6 relay agent implemented on PE routers, allowing the DHCPv6 server to notify the DHCPv6 relay agent about the prefix of pools. After the PE router received information about the prefix pools, the aggregated route entries (e.g., black-hole routes) pointing to each of the prefix pools can be added or withdrawn in the routing table of the PE router. The aggregated routes will be advertised into the ISP network through the routing protocol enabled on the PE's network-facing interface.</t>
<t>DHCPv6 Bulk Leasequery <xref target="RFC5460"/> specifies a mechanism for bulk transfer of the binding data of each delegated prefix from the server to the requestor (i.e., a DHCPv6 relay agent), to support the replacement or reboot event of a relay agent. In this document, the capability of DHCPv6 Bulk Leasequery will be extended to support the bulk transfer of the binding data of the prefix pools for route aggregation.</t>
</section>
<section anchor="s2" title="Terminology and Language">
<t>This document defines a new DHCPv6 option to communicate the prefix of an IPv6 prefix pool. This document should be read in conjunction with the DHCPv6 specifications, <xref target="RFC3315"/>, <xref target="RFC3633"/>, <xref target="RFC5007"/> and <xref target="RFC5460"/>, for understanding the complete mechanism. Definitions for terms and acronyms not specified in this document are defined in <xref target="RFC3315"/>, <xref target="RFC3633"/>, <xref target="RFC3769"/>, <xref target="RFC5007"/> and <xref target="RFC5460"/>.</t>
<t>The following terms can be found in this document:
<list style="symbols">
<t>Requesting Router (RR): A router defined in <xref target="RFC3633"/> that acts as a DHCPv6 client, and is requesting prefix(es) to be assigned.</t>
<t>Delegating Router (DR): A router defined in <xref target="RFC3633"/> that acts as a DHCPv6 server, and is responding to the prefix request.</t>
<t>Prefix Pool: An IPv6 address space allocated with a common prefix out of which the longer prefixes are delegated via prefix delegation.</t>
<t>Aggregated Route: A route entry created on an edge router, is based on the knowledge of a delegated prefix pool.</t>
<t>Requestor: A router defined in <xref target="RFC5007"/> that acts as a DHCPv6 relay agent, is leasequery client.</t>
</list>
</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, <xref target="RFC2119"/>.</t>
</section>
<section anchor="s3" title="Scenario and Network Architecture">
<t>Figure 1 and Figure 2 illustrate two typical cases of the targeted network architectures.</t>
<figure anchor="f1" title="Use case of ISP-Customer network where CPE is directly connected to PE">
<artwork>
+------+------+
| DHCPv6 | DHCPv6-PD Delegating Router
| Server | (e.g. binding entry:
+------+------+ pe#1 - 2001:db8:1230::/44
_________|_________ extract pe_id=pe#1
/ \ from the interface_id=pe#1_cfi#2)
| ISP Core Network |
\___________________/
|
| Network-facing interface
+------+------+
| | Provider Edge Router
| PE | DHCPv6 Relay Agent
| | (e.g. pe_id=pe#1;
+------+------+ prefix pool=2001:db8:1230::/44)
| Customer-facing interface (Interface ID)
| (e.g., interface_id=pe#1_cfi#2)
|
+------+------+ Customer Router
| CPE | DHCPv6 Client
| | DHCPv6-PD Requesting Router
+------+------+ (e.g. customer network
| =2001:db8:1234:5600:/56)
_________|_________
/ \
| Customer Network |
\___________________/
</artwork>
</figure>
<figure anchor="f2" title="Use case of ISP-Customer network where CPE is connected to PE through access network">
<artwork>
+------+------+
| DHCPv6 | DHCPv6-PD Delegating Router
| Server | (e.g. binding entry:
+------+------+ pe#3_cfi#4 - 2001:db8:3400::/40)
_________|_________
/ \
| ISP Core Network |
\___________________/
|
| Network-facing interface
+------+------+
| PE | Provider Edge Router
| | DHCPv6 Relay Agent
+------+------+
| Customer-facing interface (Interface ID)
| (e.g. interface_id=pe#3_cfi#4;
| prefix pool=2001:db8:3400::/40)
_________|_________
/ \
| Access Network |
\___________________/
|
+------+------+ Customer Router
| CPE | DHCPv6 Client
| | DHCPv6-PD Requesting Router
+------+------+ (e.g. customer network
| =2001:db8:3456:7800::/56)
_________|_________
/ \
| Customer Network |
\___________________/
</artwork>
</figure>
</section>
<section anchor="s4" title="Prefix Pool Option">
<t>The format of the Prefix Pool option is shown is Figure 3.</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, indicating the
availability of the prefix pool maintained
on the server.
</artwork></figure>
<t>The codes of the status are defined in the following table.</t>
<figure><artwork>
Name Code
Valid 0
Released 1
Reserved 2~255
</artwork></figure>
<t>The status of 'Valid' in the Prefix Pool option can be used to add the prefix pool and the associated aggregated route on the relay agent; while the status of 'Released' in the Prefix Pool option can be used to withdraw the prefix pool and the associated aggregated route on the relay agent.</t>
<t>If the administrative policy on the DHCPv6 server permits and supports route aggregation on the relay agent, the status of prefix pool can be determined by the delegated prefixes within the associated prefix pool. If there is one delegated prefix within the pool that has a valid lease, the status of the prefix pool will be 'Valid'. Otherwise, the status of the prefix pool is 'Released'. If the administrative policy on the server does not permit or support route aggregation on the DHCPv6 relay agent, the status of the prefix pool will always be 'Released'.</t>
</section>
<section anchor="s5" title="Relay Agent Behavior">
<t>The relay agent who needs the information of prefix pools, must include the Option Request option (OPTION_ORO, 6) to request the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) from the DHCPv6 server, who maintains the status of the prefix pools associated to the relay agent itself (Figure 1) or its particular customer-facing interface (Figure 2) when receiving the DHCPv6-PD message from clients. The DHCPv6 relay agent can include this Option Request option for the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay-forward (12) message of SOLICIT (1), REQUEST (3), RENEW(5), REBIND (6) and RELEASE (8). The relay agent may also include the Prefix Pool option with the field values of pfx-pool-len and IPv6-prefix to indicate its preference which prefix pool the relay agent would like the server to return.</t>
<t>The relay agent should include the Interface ID option (OPTION_INTERFACE_ID, 18) so that the DHCPv6 server can identify the relay agent itself or its particular customer-facing interface to which the prefix pool is associated, if the server would not like to use the link-address field specified in the encapsulation of the DHCPv6 relay-forward message to identify the interface of the link on which the clients are located.</t>
<t>After receiving the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) for the relay agent itself or its particular customer-facing interface in the relay-reply message (13) of REPLY (7) from the DHCPv6 server, the relay agent shall add or withdraw the aggregated route entry per the status of the prefix pool. If the status of the prefix pool received from the server is 'Valid', the relay agent shall add an aggregated route entry in its routing table, if the same entry has not been added in. If the status of the prefix pool received from the server is 'Released', the relay agent shall withdraw the associated aggregated route entry in its routing table, if the same entry has not been withdrawn. If there is no route entry directing to the customer network within the associated aggregated route, the relay agent shall automatically withdraw the aggregated route.</t>
<t>The relay agent advertises its routing table including the entries of the aggregated routes based on the information of prefix pools when the routing protocol is enabled on its network-facing interface.</t>
<t>The Relay Agent (i.e., Requestor) can use the DHCPv6 Bulk Leasequery <xref target="RFC5460"/> to query the binding data of prefix pools in the 'Valid' status from the server. After established a TCP connection with the DHCPv6 server, the relay agent must include Query option (OPTION_LQ_QUERY, 44) and set the proper query-type (QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, QUERY_BY_REMOTE_ID), link-address and query-options in the LEASEQUERY (14) message. The query options must include Option Request option (OPTION_ORO, 6) to request the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) from the server.</t>
</section>
<section anchor="s6" title="Server Behavior">
<t>Per DHCPv6-PD <xref target="RFC3633"/>, if the prefix of the customer network requested in relay-forward message of SOLICIT, REQUEST, RENEW, REBIND by the DHCPv6 client (i.e., the RR) has a valid lease, the DHCPv6 server (i.e., the DR) will delegate the prefix with the relevant parameters in the relay-reply message of REPLY. In order to give a meaningful reply, the server has to be able to maintain the binding data of the delegated IPv6 prefixes with the identification of the client. The Interface ID option (OPTION_INTERFACE_ID, 18) nested in the relay-forward message is usually used to identify the access line of the client.</t>
<t>After receiving the Option Request option (OPTION_ORO, 6) requesting the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay-forward messages of the PD, the server must include the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) with the status indicated for the associated relay agent itself (Figure 1) or its customer-facing interface (Figure 2) in the relay-reply messages if the relay-forward messages received are valid.</t>
<t>The server may use the link-address specified in relay-forward message to identify the relay agent itself or its particular customer-facing interface where the prefix pool is associated, but the server has to maintain the binding data of prefix pools in association with these link-addresses. To be more readable, the server can alternatively use the Interface ID option (OPTION_INTERFACE_ID, 18) included in the relay-forward message by the relay agent to identify the relay agent itself (Figure 1) or its particular customer-facing interface (Figure 2) where the prefix pool is associated. In order to give a meaningful reply, the server has to maintain the binding data of prefix pools in association with the information derived from the Interface ID option.</t>
<t>Per DHCPv6 <xref target="RFC3315"/>, the server shall copy the same Interface ID option received via the relay-forward message into the relay-reply message.</t>
<t>If the server is configured to support route aggregation on the relay agent for the particular prefix pool, the status of this prefix pool can be determined by the delegated prefixes within the associated prefix pool. If at least one of delegated prefix in the associated prefix pool has a valid lease, the server shall set the status of the prefix pool to be 'Valid'. If the lease of each delegated prefix within the associated prefix pool has expired, or if the delegated prefix in the relay-forward message of RELEASE is the last prefix releasing in the associated prefix pool, the server shall set the status of the associated prefix pool to be 'Released'. If the server is configured to not support route aggregation on the relay agent for the particular prefix pool, the status of prefix pool will always be 'Released'.</t>
<t>When the administrator of the server changes the setting to support route aggregation on the relay agent for the particular prefix pool, the server may send a relay-reply message of RECONFIGURE (10) including the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) to add or withdraw the prefix pool and the associated aggregated route on the relay agent if at least one delegated prefix within the prefix pool has the valid lease.</t>
<t>Multiple prefix pools may be associated with the same PE router implementing a DHCPv6 relay agent (Figure 1) or its customer-facing interface (Figure 2) in the binding table on the server. Note that the delegated prefix is only from one prefix pool.</t>
<t>After receiving the LEASEQUERY (14) message from the relay agent with the Query option (OPTION_LQ_QUERY, 44) including the Option Request option (OPTION_ORO, 6) to request the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]), the server must include the Client Data options (OPTION_CLIENT_DATA, 45) in the LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (16) message to convey the binding data of the associated prefix pools with the 'Valid' status through the established TCP connection per <xref target="RFC5460"/>. Each Client Data option (OPTION_CLIENT_DATA, 45) shall contain a Prefix Pool option (OPTION_PREFIX_POOL, [TBD]), and may contain the Interface ID option (OPTION_INTERFACE_ID, 18). In order to be able to provide meaningful replies to different query types, the server has to be able to maintain the relevant association of prefix pools with the RELAY_ID, link addresses or Remote_ID of the relay agent in its binding database.</t>
</section>
<section anchor="s7" title="Security Considerations">
<t>Security issues related DHCPv6 are described in section 23 of <xref target="RFC3315"/>.</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>
<section anchor="s9" title="Acknowledgements">
<t>Thanks to the DHC working group members, Bernie Volz, Eliot Lear, Ole Troan, Roberta Maglione, Ted Lemon, for the discussion in the mailing list. Thanks to Christian Jacquenet for pointing out the draft should cover one more use case of ISP-Customer network where CPE is directly connected to PE. Thanks to Sven Ooghe for some revision after the email review. Thanks to Shrinivas Ashok Joshi for pointing out the draft should cover the robust mechanism against the case of reboot. Thanks to Adrian Farrel for the orientation guide on this draft in IETF80 at Prague.</t>
</section>
<section anchor="s10" title="Changes Log">
<t>If this document is accepted for publication as an RFC, this change log is to be removed before publication.</t>
<t> Rev. -05 </t>
<t> Editorial revision to improve readability and make some clarification.</t>
<t>Rev. -04
<list style="letters">
<t>Re-titled the draft to emphasize that the new mechanism with DHCPv6-PD is only designed for the PE router.</t>
<t>Re-write the abstract and some words in the introduction.</t>
</list></t>
<t>Rev. -03
<list style="letters">
<t>Revisions on the behavior of Relay Agent about the automatic withdrawal of the aggregated route.</t>
<t>Re-correct the behavior of Server about the Interface ID option.</t>
</list></t>
<t>Rev. -02
<list style="letters">
<t>Add one more use case of ISP network architecture where CPE is directly connected to PE.</t>
<t>Revisions on the usage of the 'status' field in Prefix Pool option.</t>
<t>Extend DHCPv6 Bulk Leasequery <xref target="RFC5460"/> for the new usage.</t>
</list></t>
</section>
</middle>
<!-- ***** BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC3315;
&RFC3633;
&RFC2119;
&RFC5007;
&RFC5460;
</references>
<references title="Informative References">
&RFC3769;
<reference anchor='BBF TR-177'>
<front>
<title>IPv6 in the context of TR-101, Issue 1</title>
<author initials='' surname='Broadband Forum' fullname='' />
<date year='2010' month='November' />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:24:42 |