DHC Working Group L. Yeh, Ed.
Internet-Draft T. Tsou
Intended status: Standards Track Huawei Technologies
Expires: July 24, 2012 M. Boucadair
France Telecom
J. Schoenwaelder
Jacobs University Bremen
J. Hu
China Telecom
January 21, 2012
Prefix Pool Option for DHCPv6 Relay Agents on Provider Edge Routers
draft-yeh-dhc-dhcpv6-prefix-pool-opt-06
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 24, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Yeh, et al. Expires July 24, 2012 [Page 1]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Language . . . . . . . . . . . . . . . . . . . 4
3. Scenario and Network Architecture . . . . . . . . . . . . . . 4
4. Prefix Pool Option . . . . . . . . . . . . . . . . . . . . . . 6
5. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 8
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. Changes Log . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Yeh, et al. Expires July 24, 2012 [Page 2]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
1. Introduction
The DHCPv6 protocol [RFC3315] specifies a mechanism for the
assignment of IPv6 address and configuration information to IPv6
nodes. The DHCPv6 Prefix Delegation (DHCPv6-PD) [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.
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, [BBF TR-177]).
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.
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.
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
Yeh, et al. Expires July 24, 2012 [Page 3]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
network through the routing protocol enabled on the PE's network-
facing interface.
DHCPv6 Bulk Leasequery [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.
2. Terminology and Language
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, [RFC3315], [RFC3633], [RFC5007] and
[RFC5460], for understanding the complete mechanism. Definitions for
terms and acronyms not specified in this document are defined in
[RFC3315], [RFC3633], [RFC3769], [RFC5007] and [RFC5460].
The following terms can be found in this document:
o Requesting Router (RR): A router defined in [RFC3633] that acts as
a DHCPv6 client, and is requesting prefix(es) to be assigned.
o Delegating Router (DR): A router defined in [RFC3633] that acts as
a DHCPv6 server, and is responding to the prefix request.
o Prefix Pool: An IPv6 address space allocated with a common prefix
out of which the longer prefixes are delegated via prefix
delegation.
o Aggregated Route: A route entry created on an edge router, is
based on the knowledge of a delegated prefix pool.
o Requestor: A router defined in [RFC5007] that acts as a DHCPv6
relay agent, is leasequery client.
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, [RFC2119].
3. Scenario and Network Architecture
Figure 1 and Figure 2 illustrate two typical cases of the targeted
network architectures.
Yeh, et al. Expires July 24, 2012 [Page 4]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
+------+------+
| 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 |
\___________________/
Figure 1: Use case of ISP-Customer network where CPE is directly
connected to PE
Yeh, et al. Expires July 24, 2012 [Page 5]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
+------+------+
| 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 |
\___________________/
Figure 2: Use case of ISP-Customer network where CPE is connected to
PE through access network
4. Prefix Pool Option
The format of the Prefix Pool option is shown is Figure 3.
Yeh, et al. Expires July 24, 2012 [Page 6]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
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.
The codes of the status are defined in the following table.
Name Code
Valid 0
Released 1
Reserved 2~255
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.
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'.
Yeh, et al. Expires July 24, 2012 [Page 7]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
5. Relay Agent Behavior
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.
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.
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.
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.
The Relay Agent (i.e., Requestor) can use the DHCPv6 Bulk Leasequery
[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
Yeh, et al. Expires July 24, 2012 [Page 8]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
(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.
6. Server Behavior
Per DHCPv6-PD [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.
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.
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.
Per DHCPv6 [RFC3315], the server shall copy the same Interface ID
option received via the relay-forward message into the relay-reply
message.
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
Yeh, et al. Expires July 24, 2012 [Page 9]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
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'.
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.
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.
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 [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.
7. Security Considerations
Security issues related DHCPv6 are described in section 23 of
[RFC3315].
Yeh, et al. Expires July 24, 2012 [Page 10]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
8. IANA Considerations
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).
9. Acknowledgements
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.
10. Changes Log
If this document is accepted for publication as an RFC, this change
log is to be removed before publication.
Rev. -05
Editorial revision to improve readability and make some
clarification.
Rev. -04
a. Re-titled the draft to emphasize that the new mechanism with
DHCPv6-PD is only designed for the PE router.
b. Re-write the abstract and some words in the introduction.
Rev. -03
a. Revisions on the behavior of Relay Agent about the automatic
withdrawal of the aggregated route.
b. Re-correct the behavior of Server about the Interface ID option.
Rev. -02
Yeh, et al. Expires July 24, 2012 [Page 11]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
a. Add one more use case of ISP network architecture where CPE is
directly connected to PE.
b. Revisions on the usage of the 'status' field in Prefix Pool
option.
c. Extend DHCPv6 Bulk Leasequery [RFC5460] for the new usage.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
February 2009.
11.2. Informative References
[BBF TR-177]
Broadband Forum, "IPv6 in the context of TR-101, Issue 1",
November 2010.
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004.
Yeh, et al. Expires July 24, 2012 [Page 12]
Internet-Draft DHCPv6 Prefix Pool Option January 2012
Authors' Addresses
Leaf Y. Yeh (editor)
Huawei Technologies
Shenzhen,
China
Phone: +86-755-28978851
Email: leaf.y.yeh@huawei.com
Tina Tsou
Huawei Technologies
USA
Email: tina.tsou.zouting@huawei.com
Mohamed Boucadair
France Telecom
Rennes,
France
Email: mohamed.boucadair@orange-ftgroup.com
Juergen Schoenwaelder
Jacobs University Bremen
Bremen,
Germany
Email: j.schoenwaelder@jacobs-university.de
Jie Hu
China Telecom
Beijing,
China
Phone: +86-10-58552808
Email: huj@ctbri.com.cn
Yeh, et al. Expires July 24, 2012 [Page 13]