draft-ietf-dhc-dhcpv6-prefix-pool-opt-00.txt   draft-ietf-dhc-dhcpv6-prefix-pool-opt-01.txt 
DHC Working Group L. Yeh DHC Working Group L. Yeh
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track T. Lemon Intended status: Standards Track T. Lemon
Expires: March 14, 2013 Nominum, Inc Expires: April 22, 2013 Nominum, Inc
M. Boucadair M. Boucadair
France Telecom France Telecom
September 10, 2012 October 19, 2012
Prefix Pool Option for DHCPv6 Relay Agents on Provider Edge Routers Prefix Pool Option for DHCPv6 Relay Agents on Provider Edge Routers
draft-ietf-dhc-dhcpv6-prefix-pool-opt-00 draft-ietf-dhc-dhcpv6-prefix-pool-opt-01
Abstract Abstract
The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix
Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6
relay agent implemented on a Provider Edge (PE) router about active relay agent implemented on a Provider Edge (PE) router about active
prefix pools allocated by the DHCPv6 server to the PE router. The prefix pools allocated by the DHCPv6 server to the PE router. The
information of active prefix pools can be used to enforce IPv6 route information of active prefix pools can be used to enforce IPv6 route
aggregation on the PE router by adding or removing aggregation routes aggregation on the PE router through adding or removing aggregation
according to the status of the prefix pools. The advertising of the routes according to the status of the prefix pools. The advertising
aggregation routes in the routing protocol enabled on the network- of the aggregation routes in the routing protocol enabled on the
facing interface of PE routers will dramatically decreases the number network-facing interface of PE routers will dramatically decreases
of the routing table entries in the ISP network. the number of the routing table entries in the ISP network.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2013. This Internet-Draft will expire on April 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Scenario and Network Architecture . . . . . . . . . . . . . . 5 3. Scenario and Network Architecture . . . . . . . . . . . . . . 5
4. Prefix Pool Option . . . . . . . . . . . . . . . . . . . . . . 6 4. Prefix Pool Option . . . . . . . . . . . . . . . . . . . . . . 6
5. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 8 5. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 8
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Contributors List . . . . . . . . . . . . . . . . . . . . . . 12 9. Contributors List . . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The DHCPv6 protocol [RFC3315] specifies a mechanism for the The DHCPv6 protocol [RFC3315] specifies a mechanism for the
assignment of IPv6 address and configuration information to IPv6 assignment of IPv6 address and configuration information to IPv6
nodes. The DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] specifies nodes. The DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] specifies
a mechanism for the delegation of IPv6 prefixes from the Delegating a mechanism for the delegation of IPv6 prefixes from the Delegating
Router (DR) acting as the DHCPv6 server to the Requesting Routers Router (DR) acting as the DHCPv6 server to the Requesting Routers
(RR) acting as the DHCPv6 Clients. DHCPv6 servers always maintain (RR) acting as the DHCPv6 clients. DHCPv6 servers always maintain
authoritative information associated to their operations including, authoritative information associated with their operations including,
but not limited to, the binding data of the delegated IPv6 prefixes, but not limited to, the binding data of the delegated IPv6 prefixes,
the lease data of the delegated IPv6 prefixes, and the status of the lease data of the delegated IPv6 prefixes, and the status of
their prefix pools. A prefix pool configured and maintained on the 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 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 which the longer prefixes (e.g., /56 prefixes) are delegated to
customer networks. customer networks.
In the scenario of a centralized DHCPv6 server, the Provider Edge In the scenario of a centralized DHCPv6 server, the Provider Edge
(PE) routers act as DHCPv6 relay agents when the DHCPv6 server and (PE) routers act as DHCPv6 relay agents, when the DHCPv6 server and
the Customer Edge (CE) router (a.k.a. Routed-RG or Routed-CPE) the Customer Edge (CE) router (a.k.a. Routed-RG or Routed-CPE)
acting as RRs and DHCPv6 clients are not on the same link. For acting as RRs and DHCPv6 clients, are not on the same link. For
ensuring reachability, the PE routers always need to add or withdraw ensuring reachability, the PE routers always need to add or withdraw
the route entries directing to each customer network in their routing the route entries directing to each customer network in their routing
table to reflect the status of IPv6 prefixes delegated by the DHCPv6 table to reflect the status of IPv6 prefixes delegated by the DHCPv6
server to CE routers (see Section 6.2, [BBF TR-177]). server to CE routers (see Section 6.2, [BBF TR-177]).
When a routing protocol is enabled on the network-facing interface of When a routing protocol is enabled on the network-facing interface of
the PE router, all the routes directing to the customer networks are the PE router, all the routes directing to the customer networks are
advertised in the ISP network. This will make the number of route advertised in the ISP network. It will make the number of route
entries in the routing table on the ISP router be unacceptable large. entries in the routing table on the ISP router be unacceptable large.
Hence, it is desirable to aggregate the routes directing to the Hence, it is desirable to aggregate the routes directing to the
customer networks on the PE router. customer networks on the PE router.
Because the prefixes of the customer networks can not be guaranteed Because the prefixes of the customer networks can not be guaranteed
to be active and continuous, the routing protocol enabled on the PE to be active and continuous, the routing protocol enabled on the PE
router in general can not create one aggregation route automatically router in general can not create one aggregation route automatically
to cover all the prefixes delegated within the prefix pool. One way to cover all the prefixes delegated within the prefix pool. When the
to make the aggregation routes (e.g., black-hole routes) pointing to PE router acts as the relay agent, it in general can not be aware
each of the prefix pools is to configure them manually and about the status of the prefix pools. One way to make the
permanently, but the PE router is not really aware about the status aggregation routes (e.g., black-hole routes) pointing to each of the
of the prefix pools, especially when it acts as the relay agent. prefix pools is to configure them manually and permanently, but it is
meant to a large amount of the handwork on each PE router for its
operation and maintenance.
This document proposes a new Prefix Pool option for the DHCPv6 relay This document proposes a new Prefix Pool option for the DHCPv6 relay
agent implemented on PE routers, allowing the DHCPv6 server to notify agent implemented on PE routers, allowing the DHCPv6 server to notify
the DHCPv6 relay agent about the prefix of pools. After the PE the DHCPv6 relay agent about the prefix of pools. After the PE
router received information about the prefix pools, the aggregation router received information about the prefix pools, the aggregation
route entries per the provision status of the prefix pools can be route entries can be added or withdrawn in the routing table of the
added or withdrawn in the routing table of the PE router. The PE router according to the provision status of the prefix pools. The
aggregation routes will then be advertised into the ISP network aggregation routes will then be advertised into the ISP network
through the routing protocol enabled on the PE's network-facing through the routing protocol enabled on the PE's network-facing
interface. interface.
DHCPv6 Bulk Leasequery [RFC5460] specifies a mechanism for bulk DHCPv6 Bulk Leasequery [RFC5460] specifies a mechanism for bulk
transfer of the binding data of each delegated prefix from the server transfer of the binding data of each delegated prefix from the server
to the requestor, typically a DHCPv6 relay agent, to support the to the requestor, typically a relay agent, to support the replacement
replacement or reboot event of a relay agent. In this document, the or reboot event of a relay agent. In this document, the capability
capability of DHCPv6 Bulk Leasequery will be extended to support the of DHCPv6 Bulk Leasequery will be extended to support the bulk
bulk transfer of the status of the prefix pools for route transfer of the prefix and its status of the prefix pools for route
aggregation. aggregation.
The automatic mechanisms described in this document depend on the The automatic mechanisms described in this document depend on the
existing DHCPv6 protocols and implementations without requiring a new existing DHCPv6 protocols and implementations without requiring a new
DHCPv6 message or a new interface for the configuration of the DHCPv6 message or a new interface for the configuration of the
aggregation route. The administrator of the ISP network can decide aggregation route. The administrator of the ISP network can decide
whether to inject the aggregation route or not based on the policies whether to inject the aggregation route or not based on the policies
defined on the DHCPv6 server. defined on the DHCPv6 server.
2. Terminology and Conventions 2. Terminology and Conventions
This document defines a new DHCPv6 option to communicate the prefix This document defines a new DHCPv6 option to communicate the prefix
of an IPv6 prefix pool. This document SHOULD be read in conjunction and its status of an IPv6 prefix pool. Definitions for terms and
with the DHCPv6 specifications, [RFC3315], [RFC3633], [RFC5007] and acronyms not specified in this document are defined in [RFC3315],
[RFC5460], for understanding the complete mechanism. Definitions for [RFC3633], [RFC5007] and [RFC5460].
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: The following terms have been employed in this document:
o Requesting Router (RR): A router defined in [RFC3633] that acts as o Requesting Router (RR): A router defined in [RFC3633] that acts as
a DHCPv6 client, and is requesting prefix(es) to be delegated. a DHCPv6 client, and is requesting prefix to be delegated.
o Delegating Router (DR): A router defined in [RFC3633] that acts as o Delegating Router (DR): A router defined in [RFC3633] that acts as
a DHCPv6 server, and is responding to the prefix request. a DHCPv6 server, and is responding to the prefix request.
o Prefix Pool: An IPv6 address space allocated with a common prefix o Prefix Pool: An IPv6 address space allocated with a common prefix,
out of which the longer prefixes are delegated via prefix out of which the longer prefixes are delegated via prefix
delegation. delegation.
o aggregation Route: A route entry created on an edge router, is o aggregation route: A route entry created on an edge router, is
based on the knowledge of a delegated prefix pool. based on the knowledge of a prefix pool of the delegated prefixes.
o Requestor: A node defined in [RFC5007] that acts as the leasequery o Requestor: A node defined in [RFC5007] that acts as the leasequery
client. client.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in BCP 14, [RFC2119]. document, are to be interpreted as described in BCP 14, [RFC2119].
3. Scenario and Network Architecture 3. Scenario and Network Architecture
Figure 1 and Figure 2 illustrate two typical cases of the targeted Figure 1 and Figure 2 illustrate two typical cases of the targeted
network architectures. network architectures.
+------+------+ DHCPv6 Server +------+------+ DHCPv6 Server
| DHCPv6 | (e.g. Binding entry | DHCPv6 | (e.g. Binding entry
| Server | pe#1 - 2001:db8:1230::/44 | Server | pe#1 - 2001:db8:1230::/44,
| | extract PE_ID=pe#1 | | extract PE_ID=pe#1
+------+------+ from the Interface_ID=pe#1_cfi#2) +------+------+ from the Interface_ID=pe#1_cfi#2)
| |
_________|_________ _________|_________
/ \ / \
| ISP Core Network | | ISP Core Network |
\___________________/ \___________________/
| |
| Network-facing interface | Network-facing interface
+------+------+ +------+------+
skipping to change at page 7, line 19 skipping to change at page 7, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status | pfx-pool-len | | | status | pfx-pool-len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
| ipv6-prefix (variable length) | | ipv6-prefix (variable length) |
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_PREFIX_POOL (TBD) option-code: OPTION_PREFIX_POOL (TBA-IANA)
option-length: 2 + length of ipv6-prefix (in Octets) option-length: 2 + length of ipv6-prefix (in Octets)
pfx-pool-len: Length for the prefix pool in bits pfx-pool-len: Length for the prefix pool in bits
status: Status of the prefix pool, indicating the status: Status of the prefix pool, indicating the
availability of the prefix pool maintained availability of the prefix pool maintained
on the server. on the server.
ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16 ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16
octets in length. Bits outsides of the octets in length. Bits outsides of the
pfx-pool-len, if included, MUST be zero. pfx-pool-len, if included, MUST be zero.
The codes of the status are defined in the following table. The codes of the status are defined in the following table.
skipping to change at page 7, line 42 skipping to change at page 7, line 42
Active 0 Active 0
Released 1 Released 1
Reserved 2~255 Reserved 2~255
The 'Active' status of the prefix pool indicated in this option can The 'Active' status of the prefix pool indicated in this option can
be used to add the prefix pool and its associated aggregation route be used to add the prefix pool and its associated aggregation route
on the relay agent; while the 'Released' status of prefix pool on the relay agent; while the 'Released' status of prefix pool
indicated in this option can be used to withdraw the prefix pool and indicated in this option can be used to withdraw the prefix pool and
its associated aggregation route on the relay agent. its associated aggregation route on the relay agent.
If the administrative policy on the DHCPv6 server permits to support If the administrative policy on the server permits to support route
route aggregation on the relay agent, the status of prefix pool can aggregation on the relay agent, the status of prefix pool can be
be determined by the delegated prefixes within the associated prefix determined by the delegated prefixes within the associated prefix
pool. If there is one delegated prefix within the pool that has a pool: If there is one delegated prefix within the pool that has a
valid lease, the status of the prefix pool will be 'Active'. valid lease, the status of the prefix pool will be 'Active';
Otherwise, the status of the prefix pool is 'Released'. If the otherwise, the status of the prefix pool is 'Released'. If the
administrative policy on the server does not permit to support route administrative policy on the server does not permit to support route
aggregation on the DHCPv6 relay agent, the status of the prefix pool aggregation on the relay agent, the status of the prefix pool will
will always be 'Released'. always be 'Released'.
Discussion:
The alternative option might include the lease information in the
prefix pool, then populate it to relay agent, make the state
machine on the relay agent keep synchronizing the lease and status
of the associated prefix pool with the server. But the solution
proposed in this draft is to let relay agent confirm the received
status of the prefix pool by itself as per the leases of delegated
customer prefixes within it, and build its own lease for the
prefix pool.
Prefix Pool Option MAY be included by the DHCPv6 server in RELAY-REPL Prefix Pool Option MAY be included by the DHCPv6 server in RELAY-REPL
(13), LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) message, or MAY (13), LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) message, and MAY
be included by the DHCPv6 relay agent in the RELAY-FORW (12). be included by the DHCPv6 relay agent in the RELAY-FORW (12).
5. Relay Agent Behavior 5. Relay Agent Behavior
The relay agent who needs the information of prefix pools, MUST The DHCPv6 relay agent who needs the information of prefix pools,
include the associated requested-option-code in Option Request option MUST include the associated requested-option-code in Option Request
(OPTION_ORO, 6) to request the Prefix Pool option option (OPTION_ORO, 6) to request the Prefix Pool option
(OPTION_PREFIX_POOL, [TBD]) from the DHCPv6 server, who maintains the (OPTION_PREFIX_POOL, [TBD-IANA]) from the DHCPv6 server, who
status of the prefix pools associated to the relay agent itself maintains the status of the prefix pools associated with the relay
(Figure 1) or its particular customer-facing interface (Figure 2), agent itself (Figure 1) or its particular customer-facing interface
when receiving the DHCPv6-PD message from clients. The DHCPv6 relay (Figure 2), when receiving the DHCPv6-PD message from clients. The
agent MAY include this Option Request option for the Prefix Pool relay agent MAY include this Option Request option for the Prefix
option in the RELAY-FORW (12) message of SOLICIT (1), REQUEST (3), Pool option in the RELAY-FORW (12) message of SOLICIT (1), REQUEST
RENEW(5), REBIND (6) and RELEASE (8). The relay agent MAY also (3), RENEW(5), REBIND (6) and RELEASE (8). The relay agent MAY also
include the Prefix Pool option with the values of pfx-pool-len and include the Prefix Pool option with the values of 'pfx-pool-len' and
IPv6-prefix to indicate its preference, which prefix pool the relay 'ip6-prefix' to indicate its preference for which prefix pool the
agent would like the server to return. relay agent would like the server to return.
The relay agent SHOULD include the Interface ID option The relay agent SHOULD include the Interface ID option
(OPTION_INTERFACE_ID, 18) so that the DHCPv6 server can identify the (OPTION_INTERFACE_ID, 18) so that the server can identify the relay
relay agent itself or its particular customer-facing interface to agent itself or its particular customer-facing interface with which
which the prefix pool is associated, if the server would not like to the prefix pool is associated, if the server would not like to use
use the link-address field specified in the encapsulation of the the link-address field specified in the encapsulation of the DHCPv6
DHCPv6 relay-forward message to identify the interface of the link on relay-forward message to identify the interface of the link on which
which the clients are located. the clients are located.
The relay agent MAY set up a table for the leases and/or status of The relay agent MAY set up a table for the lease or status of the
the prefix pools on it as per the delegated customer prefixes within prefix pool on it according to the leases of the delegated customer
it. The lease of the prefix pools MUST dynamically set to be the prefixes within it. The lease of the prefix pools MUST dynamically
maximum lease of the delegated customer prefixes. If there is no set to be the maximum lease of the delegated customer prefixes. If
route entry directing to the customer network within the aggregation there is no route entry directing to the customer network within the
route associated with the prefix pool, the relay agent shall aggregation route associated with the prefix pool or the lease of
automatically withdraw the aggregation route. prefix pool runs out, the relay agent Should automatically withdraw
the aggregation route.
After receiving the Prefix Pool option for the relay agent itself or After receiving the Prefix Pool option for the relay agent itself or
its particular customer-facing interface in the relay-reply message its particular customer-facing interface in the RELAY-REPL (13)
(13) of REPLY (7) from the DHCPv6 server, the relay agent acting as message of REPLY (7) from the server, the relay agent acting as the
the PE router shall confirm the status of the prefix pool as per the PE router Should confirm the status of the prefix pool according to
leases of delegated customer prefixes within it, then add the the leases of delegated customer prefixes within it. If the status
aggregation route entry per the status of the prefix pool. If the of the prefix pool received and confirmed is 'Active', the relay
status of the prefix pool received and confirmed is 'Active', the agent Should add an aggregation route entry in its routing table, if
relay agent shall add an aggregation route entry in its routing the same entry has not been added before. If the status of the
table, if the same entry has not been added in before. If the status prefix pool received is 'Released', the relay agent Should withdraw
of the prefix pool received is 'Released', the relay agent shall the associated aggregation route entry in its routing table, if the
withdraw the associated aggregation route entry in its routing table, same entry has not been withdrawn before.
if the same entry has not been withdrawn before.
The relay agent advertises its routing table including the entries of The relay agent advertises its routing table including the entries of
the aggregation routes based on the information of prefix pools when the aggregation routes based on the information of prefix pools when
the routing protocol is enabled on its network-facing interface. the routing protocol is enabled on its network-facing interface.
The Relay Agent (i.e., Requestor) can use the DHCPv6 Bulk Leasequery The Relay Agent (i.e., Requestor) can use the DHCPv6 Bulk Leasequery
[RFC5460] to query the binding data of prefix pools in the 'Active' [RFC5460] to query the binding data of prefix pools in the 'Active'
status from the server. After established a TCP connection with the status from the server. After established a TCP connection with the
DHCPv6 server, the relay agent MUST include Query option server, the relay agent MUST include Query option (OPTION_LQ_QUERY,
(OPTION_LQ_QUERY, 44) and set the proper query-type 44) and set the proper query-type (QUERY_BY_RELAY_ID,
(QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, QUERY_BY_REMOTE_ID), link- QUERY_BY_LINK_ADDRESS or QUERY_BY_REMOTE_ID), link-address and query-
address and query-options in the LEASEQUERY (14) message. The query options in the LEASEQUERY (14) message. The query options MUST
options MUST include Option Request option (OPTION_ORO, 6) to request include Option Request option (OPTION_ORO, 6) to request the Prefix
the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) from the server. Pool option (OPTION_PREFIX_POOL, [TBD]) from the server.
6. Server Behavior 6. Server Behavior
Per DHCPv6-PD [RFC3633], if the prefix of the customer network According to DHCPv6-PD [RFC3633], if the prefix of the customer
requested in relay-forward (12) message of SOLICIT, REQUEST, RENEW, network requested in RELAY-FORW (12) message of SOLICIT, REQUEST,
REBIND from the DHCPv6 client (i.e., the RR) has a valid lease, the RENEW, REBIND from the DHCPv6 client (i.e., the RR) has a valid
DHCPv6 server (i.e., the DR) will delegate the prefix with the lease, the DHCPv6 server (i.e., the DR) will delegate the prefix with
relevant parameters in the relay-reply (13) message of REPLY. In the relevant parameters in the RELAY-REPL (13) message of REPLY. In
order to give a meaningful reply, the server has to be able to order to give a meaningful reply, the server has to maintain the
maintain the binding data of the delegated IPv6 prefixes with the binding data of the delegated IPv6 prefixes with the identification
identification of the client. The Interface ID option of the client. The Interface ID option (OPTION_INTERFACE_ID, 18)
(OPTION_INTERFACE_ID, 18) nested in the relay-forward message is nested in the relay-forward message is usually used to identify the
usually used to identify the access line of the client. access line of the client.
After receiving the Option Request option (OPTION_ORO, 6) requesting After receiving the Option Request option (OPTION_ORO, 6) requesting
the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay- the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay-
forward messages of the DHCPv6-PD, the server MUST include the Prefix forward messages of the DHCPv6-PD, the server MUST include the Prefix
Pool option with the status indicated for the associated relay agent Pool option with the status indicated for the associated relay agent
itself (Figure 1) or its customer-facing interface (Figure 2) in the itself (Figure 1) or its customer-facing interface (Figure 2) in the
relay-reply messages if the relay-forward messages received are relay-reply messages if the relay-forward messages received are
valid. valid.
The server MAY use the link-address specified in relay-forward The server MAY use the link-address specified in relay-forward
message to identify the relay agent itself or its particular message to identify the relay agent itself or its particular
customer-facing interface where the prefix pool is associated, but customer-facing interface where the prefix pool is associated, but
the server has to maintain the binding data of prefix pools in the server has to maintain the binding data of prefix pools in
association with these link-addresses. To be more readable, the association with these link-addresses. To be more readable, the
server can alternatively use the Interface ID option server can alternatively use the Interface ID option included in the
(OPTION_INTERFACE_ID, 18) included in the relay-forward message by relay-forward message by the relay agent to identify the relay agent
the relay agent to identify the relay agent itself (Figure 1) or its itself or its particular customer-facing interface where the prefix
particular customer-facing interface (Figure 2) where the prefix pool pool is associated. In order to give a meaningful reply, the server
is associated. In order to give a meaningful reply, the server has has to maintain the binding data of prefix pools in association with
to maintain the binding data of prefix pools in association with the the information derived from the Interface ID option. According to
information derived from the Interface ID option. DHCPv6 [RFC3315], the server MUST copy the Interface ID option from
the relay-forward message into the relay-reply message.
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 administrative policy on the DHCPv6 server permits to support If the administrative policy on the server permits to support route
route aggregation on the relay agent for some particular prefix, the aggregation on the relay agent for some particular prefix pool, the
status of prefix pool can be determined by the delegated prefixes status of prefix pool can be determined by the delegated prefixes
within the associated prefix pool. If there is at least one within the associated prefix pool. If there is at least one
delegated prefix within the pool that has a valid lease, the server delegated prefix within the pool that has a valid lease, the server
shall set the status of the associated prefix pool to be 'Active'. Should set the status of the associated prefix pool to be 'Active'.
After the last prefix releasing in the associated prefix pool, the After the last prefix released in the associated prefix pool, the
server shall set the status of the associated prefix pool to be server Should set the status of the associated prefix pool to be
'Released'. If the administrative policy on the server does not 'Released'. If the administrative policy on the server does not
permit to support route aggregation on the DHCPv6 relay agent, the permit to support route aggregation on the relay agent, the server
server shall set the status of the prefix pools always to be shall set the status of the prefix pools always to be 'Released'.
'Released'.
When the administrator of the server changes the setting to support When the administrator of the server changes the setting to support
route aggregation on the relay agent for the particular prefix pool, route aggregation on the relay agent for the particular prefix pool,
the status of the prefix pool MAY change from 'Released' to be the status of the prefix pool MAY change from 'Released' to be
'Active' if at least one delegated prefix within the prefix pool has 'Active' if at least one delegated prefix within the prefix pool has
the valid lease. When the administrator of the server changes the the valid lease. When the administrator of the server changes the
setting not to support route aggregation on the relay agent for the setting not to support route aggregation on the relay agent for the
particular prefix pool, the status of the prefix pool MAY change from particular prefix pool, the status of the prefix pool MAY change from
'Active' to be 'Released' if at least one delegated prefix within the 'Active' to be 'Released' if at least one delegated prefix within the
prefix pool has the valid lease. Then the server MAY send a relay- prefix pool has the valid lease. Then the server MAY send a relay-
reply message of RECONFIGURE (10) to initiate immediately a Renew (5) reply message of RECONFIGURE (10) to initiate immediately a Renew (5)
/ Reply (7) PD message exchange with Prefix Pool option between one / Reply (7) prefix delegation message exchange with Prefix Pool
active client and the server. option between one active client and the server.
Multiple prefix pools MAY be associated with the same PE router Multiple prefix pools MAY be associated with the same PE router
implementing a DHCPv6 relay agent (Figure 1) or its customer-facing implementing the relay agent, or its customer-facing interface in the
interface (Figure 2) in the binding table on the server. Note that binding table on the server. Note that these prefix pools Should not
these prefix pools don't overlay, and the delegated customer prefix overlay, and the delegated customer prefix is only from one prefix
is only from one prefix pool. pool.
After receiving the LEASEQUERY (14) message from the relay agent with After receiving the LEASEQUERY (14) message from the relay agent with
the Query option (OPTION_LQ_QUERY, 44) including the Option Request the OPTION_LQ_QUERY (44) including the OPTION_ORO (6) to request the
option (OPTION_ORO, 6) to request the Prefix Pool option OPTION_PREFIX_POOL (TBD), the server MUST include the Prefix Pool
(OPTION_PREFIX_POOL, [TBD]), the server MUST include the Client Data option in the LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) messages
options (OPTION_CLIENT_DATA, 45) in the LEASEQUERY-REPLY (15) and to convey the binding data of the associated prefix pools through the
LEASEQUERY-DATA (17) message to convey the binding data of the established TCP connection according to mechanism defined in the
associated prefix pools with the 'Active' status through the DHCPv6 Bulk Leasequery [RFC5460]. Each LEASEQUERY-REPLY (15) and
established TCP connection per [RFC5460]. Each Client Data option LEASEQUERY-DATA (17) message only contains one OPTION_PREFIX_POOL or
shall contain a Prefix Pool option, and MAY contain the Interface ID and the associated OPTION_INTERFACE_ID (18) if the status of the
option (OPTION_INTERFACE_ID, 18). In order to be able to provide prefix pool is 'active'. In order to be able to provide meaningful
meaningful replies to different query types, the server has to be replies to different query types, the server has to maintain the
able to maintain the relevant association of prefix pools with the relevant association of prefix pools with the RELAY_ID, link
RELAY_ID, link addresses or Remote_ID of the relay agent in its addresses or Remote_ID of the relay agent in its binding database.
binding database.
7. Security Considerations 7. Security Considerations
Security issues related DHCPv6 are described in Section 23 of Security issues related DHCPv6 are described in Section 23 of
[RFC3315] and Section 15 of [RFC3633]. [RFC3315] and Section 15 of [RFC3633].
8. IANA Considerations 8. IANA Considerations
IANA is requested to assign an option code to Option_Prefix_Pool from IANA is requested to assign an option code to Option_Prefix_Pool from
the "DHCPv6 and DHCPv6 options" registry the DHCPv6 registry (http://www.iana.org/assignments/
(http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6- dhcpv6-parameters/dhcpv6-parameters.xml).
parameters.xml).
9. Contributors List 9. Contributors List
Juergen Schoenwaelder Juergen Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
Bremen Bremen
Germany Germany
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
skipping to change at page 12, line 30 skipping to change at page 11, line 41
Tina Tsou Tina Tsou
Huawei Technologies Huawei Technologies
Santa Clara, CA Santa Clara, CA
USA USA
Email: tina.tsou.zouting@huawei.com Email: tina.tsou.zouting@huawei.com
10. Acknowledgements 10. Acknowledgements
Thanks to Ralph Droms for the inspiration from his expired draft Thanks to Ralph Droms for the inspiration from his expired
(RAAN option), to the DHC working group members, Bernie Volz, Ole [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04], to the DHC working group
Troan and Roberta Maglione for the discussion in the mailing list, to members, Bernie Volz, Ole Troan and Roberta Maglione for the
Christian Jacquenet for pointing out the draft shall cover one more discussion in the mailing list, to Christian Jacquenet for pointing
use case of ISP-Customer network where CPE is directly connected to out the draft shall cover one more use case of ISP-Customer network
PE, to Sven Ooghe for some revisions in the email review, to where CPE is directly connected to PE, to Sven Ooghe for some
Shrinivas Ashok Joshi for pointing out the draft shall cover the revisions in the email review, to Shrinivas Ashok Joshi for pointing
robust mechanism against the case of reboot, to Adrian Farrel for the out the draft shall cover the mechanism against the case of reboot,
orientation guide on this draft in IETF80 at Prague. to Adrian Farrel for the orientation guide on this draft in IETF80 at
Prague.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
skipping to change at page 13, line 21 skipping to change at page 12, line 33
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
February 2009. February 2009.
11.2. Informative References 11.2. Informative References
[BBF TR-177] [BBF TR-177]
Broadband Forum, "IPv6 in the context of TR-101, Issue 1", Broadband Forum, "IPv6 in the context of TR-101, Issue 1",
November 2010. November 2010.
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04]
Delegation", RFC 3769, June 2004. Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent
Assignment Notification (RAAN) Option", July 2009.
Authors' Addresses Authors' Addresses
Leaf Y. Yeh Leaf Y. Yeh
Huawei Technologies Huawei Technologies
Shenzhen, Shenzhen,
P. R. China P. R. China
Email: leaf.y.yeh@huawei.com Email: leaf.y.yeh@huawei.com
Ted Lemon Ted Lemon
Nominum, Inc Nominum, Inc
USA USA
Email: Ted.Lemon@nominum.com Email: Ted.Lemon@nominum.com
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
Rennes, Rennes,
France France
 End of changes. 42 change blocks. 
168 lines changed or deleted 152 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/