draft-ietf-dhc-dhcpv6-prefix-pool-opt-01.txt   draft-ietf-dhc-dhcpv6-prefix-pool-opt-02.txt 
DHC Working Group L. Yeh DHC Working Group L. Yeh
Internet-Draft Huawei Technologies Internet-Draft Freelancer Technologies
Intended status: Standards Track T. Lemon Intended status: Standards Track T. Lemon
Expires: April 22, 2013 Nominum, Inc Expires: August 14, 2013 Nominum, Inc
M. Boucadair M. Boucadair
France Telecom France Telecom
October 19, 2012 February 10, 2013
Prefix Pool Option for DHCPv6 Relay Agents on Provider Edge Routers Prefix Pool Option for DHCPv6 Relay Agent on the Provider Edge Routers
draft-ietf-dhc-dhcpv6-prefix-pool-opt-01 draft-ietf-dhc-dhcpv6-prefix-pool-opt-02
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 through adding or removing aggregation aggregation on the PE router through adding or removing aggregation
routes according to the status of the prefix pools. The advertising routes according to the status of the prefix pools. The advertising
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 April 22, 2013. This Internet-Draft will expire on August 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 12 skipping to change at page 3, line 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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. The DHCPv6 servers always
authoritative information associated with their operations including, maintain authoritative information associated with their operations
but not limited to, the binding data of the delegated IPv6 prefixes, including, but not limited to, the binding data of the delegated IPv6
the lease data of the delegated IPv6 prefixes, and the status of prefixes, the lease data of the delegated IPv6 prefixes, the status
their prefix pools. A prefix pool configured and maintained on the of their prefix pools, etc. A prefix pool configured and maintained
server can usually be a short prefix (e.g., a /40 prefix), out of on the server can usually be a short prefix (e.g., a /40 prefix), out
which the longer prefixes (e.g., /56 prefixes) are delegated to of which a longer prefixes (e.g., a /56 prefixes) are delegated to
customer networks. customer networks.
In the scenario of a centralized DHCPv6 server, the Provider Edge In the scenarios 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 the 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 the 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. It 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 routers be unacceptable
Hence, it is desirable to aggregate the routes directing to the large. Hence, it is desirable to aggregate the routes directing to
customer networks on the PE router. the 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. When the to cover all the prefixes delegated within the prefix pool. When the
PE router acts as the relay agent, it in general can not be aware PE router acts as the relay agent, it can not be aware about the
about the status of the prefix pools. One way to make the status of the prefix pools in general. The way to make the
aggregation routes (e.g., black-hole routes) pointing to each of the aggregation routes (e.g., black-hole routes) pointing to each of the
prefix pools is to configure them manually and permanently, but it is prefix pools could be to configure them manually and permanently, but
meant to a large amount of the handwork on each PE router for its it is meant to a large amount of the handwork on each PE router for
operation and maintenance. 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 the information about the prefix pools. After
router received information about the prefix pools, the aggregation the PE router received the prefix pools, the aggregation route
route entries can be added or withdrawn in the routing table of the entries can be added or withdrawn in the routing table of the PE
PE router according to the provision status of the prefix pools. The 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 relay agent, to support the replacement to the requestor, typically a relay agent, to support the replacement
or reboot event of a relay agent. In this document, the capability or reboot event of a relay agent. In this document, the capability
of DHCPv6 Bulk Leasequery will be extended to support the bulk of DHCPv6 Bulk Leasequery will be extended to support the bulk
transfer of the prefix and its status of the prefix pools for route transfer of the prefix and its status of the prefix pools for the
aggregation. route 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
skipping to change at page 5, line 13 skipping to change at page 5, line 13
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:3450::/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
+------+------+ +------+------+
| Provider | DHCPv6 Relay Agent, DHCPv6 Requestor | Provider | DHCPv6 Relay Agent, DHCPv6 Requestor
| Edge | (e.g. prefix pool=2001:db8:1230::/44) | Edge | (e.g. prefix pool=2001:db8:3450::/44)
| Router | | Router |
+------+------+ +------+------+
| Customer-facing interface | Customer-facing interface
| (e.g. Interface_ID=pe#1_cfi#2) | (e.g. Interface_ID=pe#1_cfi#2)
| |
+------+------+ +------+------+
| Customer | DHCPv6 Client | Customer | DHCPv6 Client
| Edge | DHCPv6-PD Requesting Router | Edge | DHCPv6-PD Requesting Router
| Router | (e.g. customer network | Router | (e.g. customer network
+------+------+ =2001:db8:1234:5600:/56) +------+------+ =2001:db8:3456:7800:/56)
| |
_________|_________ _________|_________
/ \ / \
| Customer Network | | Customer Network |
\___________________/ \___________________/
Figure 1: Use case of ISP-Customer network where CPE is directly Figure 1: ISP-to-Customer network where CE is directly connected to
connected to PE PE
+------+------+ +------+------+
| DHCPv6 | DHCPv6 Server | DHCPv6 | DHCPv6 Server
| Server | (e.g. Binding entry | Server | (e.g. Binding entry
| | pe#3_cfi#4 - 2001:db8:3400::/40) | | pe#3_cfi#4 - 2001:db8:1200::/40)
+------+------+ +------+------+
| |
_________|_________ _________|_________
/ \ / \
| ISP Core Network | | ISP Core Network |
\___________________/ \___________________/
| |
| Network-facing interface | Network-facing interface
+------+------+ +------+------+
| Provider | DHCPv6 Relay Agent, DHCPv6 Requestor | Provider | DHCPv6 Relay Agent, DHCPv6 Requestor
| Edge | (e.g. prefix pool=2001:db8:3400::/40) | Edge | (e.g. prefix pool=2001:db8:1200::/40)
| Router | | Router |
+------+------+ +------+------+
| Customer-facing interface | Customer-facing interface
| (e.g. Interface_ID=pe#3_cfi#4) | (e.g. Interface_ID=pe#3_cfi#4)
_________|_________ _________|_________
/ \ / \
| Access Network | | Access Network |
\___________________/ \___________________/
| |
| |
skipping to change at page 6, line 41 skipping to change at page 6, line 41
| Customer | DHCPv6 Client | Customer | DHCPv6 Client
| Edge | DHCPv6-PD Requesting Router | Edge | DHCPv6-PD Requesting Router
| Router | (e.g. customer network | Router | (e.g. customer network
+------+------+ =2001:db8:1234:5600:/56) +------+------+ =2001:db8:1234:5600:/56)
| |
_________|_________ _________|_________
/ \ / \
| Customer Network | | Customer Network |
\___________________/ \___________________/
Figure 2: Use case of ISP-Customer network where CPE is connected to Figure 2: ISP-to-Customer network where CE is connected to PE through
PE through access network access network
4. Prefix Pool Option 4. Prefix Pool Option
The format of the Prefix Pool option is shown in Figure 3. The format of the Prefix Pool option is shown in Figure 3.
0 1 2 3 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 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 | | OPTION_PREFIX_POOL | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status | pfx-pool-len | | | status | pfx-pool-len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
| ipv6-prefix (variable length) | | ipv6-prefix (variable length) |
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_PREFIX_POOL (TBA-IANA) 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
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.
pfx-pool-len: Length for the prefix pool in Bits
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.
Name Code Name Code
Active 0 Active 0
Released 1 Released 1
Reserved 2~255 Reserved 2~255
skipping to change at page 8, line 10 skipping to change at page 8, line 10
aggregation on the relay agent, the status of the prefix pool will aggregation on the relay agent, the status of the prefix pool will
always be 'Released'. always be 'Released'.
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, and 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 DHCPv6 relay agent who needs the information of prefix pools, The DHCPv6 relay agent who needs the information of prefix pools,
MUST include the associated requested-option-code in Option Request SHOULD include the associated requested-option-code in Option Request
option (OPTION_ORO, 6) to request the Prefix Pool option option (OPTION_ORO, 6) to request the Prefix Pool option
(OPTION_PREFIX_POOL, [TBD-IANA]) from the DHCPv6 server, who (OPTION_PREFIX_POOL, [TBD-IANA]) from the DHCPv6 server, who
maintains the status of the prefix pools associated with the relay maintains the status of the prefix pools associated with the relay
agent itself (Figure 1) or its particular customer-facing interface agent itself (Figure 1) or its particular customer-facing interface
(Figure 2), when receiving the DHCPv6-PD message from clients. The (Figure 2), when receiving the DHCPv6-PD message from clients. The
relay agent MAY include this Option Request option for the Prefix relay agent SHOULD include this Option Request option for the Prefix
Pool option in the RELAY-FORW (12) message of SOLICIT (1), REQUEST Pool option in the RELAY-FORW (12) message of SOLICIT (1), REQUEST
(3), 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
'ip6-prefix' to indicate its preference for which prefix pool the 'ip6-prefix' to indicate its preference for which prefix pool the
relay 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 server can identify the relay (OPTION_INTERFACE_ID, 18) so that the server can identify the relay
agent itself or its particular customer-facing interface with which agent itself or its particular customer-facing interface with which
the prefix pool is associated, if the server would not like to use the prefix pool is associated, if the server would not like to use
the link-address field specified in the encapsulation of the DHCPv6 the link-address field specified in the encapsulation of the DHCPv6
relay-forward message to identify the interface of the link on which RELAY-FORW message to identify the interface of the link on which the
the clients are located. clients are located.
The relay agent MAY set up a table for the lease or status of the The PE router acting as the relay agent MAY set up a table for the
prefix pool on it according to the leases of the delegated customer lease or status of the prefix pools on it according to the leases of
prefixes within it. The lease of the prefix pools MUST dynamically the delegated customer prefixes within the prefix pools. The lease
set to be the maximum lease of the delegated customer prefixes. If of the prefix pool SHOULD dynamically set to be the maximum lease of
there is no route entry directing to the customer network within the the delegated customer prefix within it. If there is no route entry
aggregation route associated with the prefix pool or the lease of directing to the customer network within the aggregation route
prefix pool runs out, the relay agent Should automatically withdraw associated with the prefix pool or the lease of prefix pool runs out,
the PE router acting as the relay agent SHOULD automatically withdraw
the aggregation route. 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-REPL (13) its particular customer-facing interface in the RELAY-REPL (13)
message of REPLY (7) from the server, the relay agent acting as the message of REPLY (7) from the server, the PE router acting as the
PE router Should confirm the status of the prefix pool according to relay agent SHOULD confirm the status of the prefix pool according to
the leases of delegated customer prefixes within it. If the status the leases of delegated customer prefixes within it. If the status
of the prefix pool received and confirmed is 'Active', the relay of the prefix pool received and confirmed is 'Active', the PE router
agent Should add an aggregation route entry in its routing table, if acting as the relay agent SHOULD add an aggregation route entry in
the same entry has not been added before. If the status of the its routing table, if the same entry has not been added before. If
prefix pool received is 'Released', the relay agent Should withdraw the status of the prefix pool received is 'Released', the PE router
the associated aggregation route entry in its routing table, if the acting as the relay agent SHOULD withdraw the associated aggregation
same entry has not been withdrawn before. route entry in its routing table, if the same entry has not been
withdrawn before.
The relay agent advertises its routing table including the entries of The PE router acting as the relay agent advertises its routing table
the aggregation routes based on the information of prefix pools when including the entries of the aggregation routes based on the
the routing protocol is enabled on its network-facing interface. 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 The PE router acting as the relay agent (i.e., Requestor) can use the
[RFC5460] to query the binding data of prefix pools in the 'Active' DHCPv6 Bulk Leasequery [RFC5460] to query the binding data of prefix
status from the server. After established a TCP connection with the pools in the 'Active' status from the server. After established a
server, the relay agent MUST include Query option (OPTION_LQ_QUERY, TCP connection with the server, the relay agent SHOULD include Query
44) and set the proper query-type (QUERY_BY_RELAY_ID, option (OPTION_LQ_QUERY, 44) and set the proper query-type
QUERY_BY_LINK_ADDRESS or QUERY_BY_REMOTE_ID), link-address and query- (QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS or QUERY_BY_REMOTE_ID),
options in the LEASEQUERY (14) message. The query options MUST link-address and query-options in the LEASEQUERY (14) message. The
include Option Request option (OPTION_ORO, 6) to request the Prefix query options SHOULD include Option Request option to request the
Pool option (OPTION_PREFIX_POOL, [TBD]) from the server. Prefix Pool option from the server.
6. Server Behavior 6. Server Behavior
According to DHCPv6-PD [RFC3633], if the prefix of the customer According to DHCPv6-PD [RFC3633], if the prefix of the customer
network requested in RELAY-FORW (12) message of SOLICIT, REQUEST, network requested in RELAY-FORW (12) message of SOLICIT (1), REQUEST
RENEW, REBIND from the DHCPv6 client (i.e., the RR) has a valid (3), RENEW(5), REBIND (6) from the DHCPv6 client (i.e., the RR) has a
lease, the DHCPv6 server (i.e., the DR) will delegate the prefix with valid lease, the DHCPv6 server (i.e., the DR) will delegate the
the relevant parameters in the RELAY-REPL (13) message of REPLY. In prefix with the relevant parameters in the RELAY-REPL (13) message of
order to give a meaningful reply, the server has to maintain the REPLY (7). In order to give a meaningful reply, the server has to
binding data of the delegated IPv6 prefixes with the identification maintain the binding data of the delegated IPv6 prefixes with the
of the client. The Interface ID option (OPTION_INTERFACE_ID, 18) identification of the client. The Interface ID option
nested in the relay-forward message is usually used to identify the (OPTION_INTERFACE_ID, 18) nested in the RELAY-FORW message is usually
access line of the client. used to identify the 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-FORW
forward messages of the DHCPv6-PD, the server MUST include the Prefix messages of the DHCPv6-PD, the server SHOULD include the Prefix Pool
Pool option with the status indicated for the associated relay agent 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-REPL messages, if the RELAY-FORW 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-FORW message
message to identify the relay agent itself or its particular to identify the relay agent itself or its particular customer-facing
customer-facing interface where the prefix pool is associated, but interface where the prefix pool is associated, but the server has to
the server has to maintain the binding data of prefix pools in maintain the binding data of prefix pools in association with these
association with these link-addresses. To be more readable, the link-addresses. To be more readable, the server can alternatively
server can alternatively use the Interface ID option included in the use the Interface ID option included in the RELAY-FORW message by the
relay-forward message by the relay agent to identify the relay agent relay agent to identify the relay agent itself or its particular
itself or its particular customer-facing interface where the prefix customer-facing interface where the prefix pool is associated. In
pool is associated. In order to give a meaningful reply, the server order to give a meaningful reply, the server has to maintain the
has to maintain the binding data of prefix pools in association with binding data of prefix pools in association with the information
the information derived from the Interface ID option. According to derived from the Interface ID option. According to DHCPv6 [RFC3315],
DHCPv6 [RFC3315], the server MUST copy the Interface ID option from the server SHOULD copy the Interface ID option from the RELAY-FORW
the relay-forward message into the relay-reply message. message into the RELAY-REPL message.
If the administrative policy on the server permits to support route If the administrative policy on the server permits to support route
aggregation on the relay agent for some particular prefix pool, the aggregation on the relay agents 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
Should 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 released in the associated prefix pool, the After the last prefix released in the associated prefix pool, the
server Should 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 relay agent, the server permit to support route aggregation on the relay agents, the server
shall set the status of the prefix pools always to be 'Released'. shall set the status of the associated prefix pools always to be
'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 SHOULD 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 SHOULD change
'Active' to be 'Released' if at least one delegated prefix within the from 'Active' to be 'Released' if at least one delegated prefix
prefix pool has the valid lease. Then the server MAY send a relay- within the prefix pool has the valid lease. The server MAY initiate
reply message of RECONFIGURE (10) to initiate immediately a Renew (5) a RELAY-REPL message of RECONFIGURE (10) to immediately trigger RENEW
/ Reply (7) prefix delegation message exchange with Prefix Pool (5) / REPLY (7) prefix delegation message exchange with Prefix Pool
option between one 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 the relay agent, or its customer-facing interface in the acting as the relay agent, or its customer-facing interface in the
binding table on the server. Note that these prefix pools Should not binding table on the server. Note that these prefix pools SHOULD not
overlay, and the delegated customer prefix is only from one prefix overlay, and the delegated customer 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 OPTION_LQ_QUERY (44) including the OPTION_ORO (6) to request the the OPTION_LQ_QUERY (44) including the OPTION_ORO (6) to request the
OPTION_PREFIX_POOL (TBD), the server MUST include the Prefix Pool Prefix Pool option, the server SHOULD include the OPTION_PREFIX_POOL
option in the LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) messages (TBD) in the LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) messages
to convey the binding data of the associated prefix pools through the to convey the binding data of the associated prefix pools through the
established TCP connection according to mechanism defined in the established TCP connection according to mechanism defined in the
DHCPv6 Bulk Leasequery [RFC5460]. Each LEASEQUERY-REPLY (15) and DHCPv6 Bulk Leasequery [RFC5460]. Each LEASEQUERY-REPLY (15) and
LEASEQUERY-DATA (17) message only contains one OPTION_PREFIX_POOL or LEASEQUERY-DATA (17) message MAY only contain one OPTION_PREFIX_POOL,
and the associated OPTION_INTERFACE_ID (18) if the status of the or and the associated OPTION_INTERFACE_ID, if the status of the
prefix pool is 'active'. In order to be able to provide meaningful prefix pool is 'active'. In order to be able to provide meaningful
replies to different query types, the server has to maintain the replies to different query types, the server has to maintain the
relevant association of prefix pools with the RELAY_ID, link relevant association of prefix pools with the Relay_ID, link
addresses or Remote_ID of the relay agent in its binding database. addresses or Remote_IDs of the relay agent in its 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 This document requests to assign a new option code for
the DHCPv6 registry (http://www.iana.org/assignments/ Option_Prefix_Pool in the registry of DHCPv6 Option Codes (http://
dhcpv6-parameters/dhcpv6-parameters.xml). www.iana.org/assignments/dhcpv6-parameters/dhcpv6-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
Jie Hu Jie Hu
China Telecom China Telecom
Beijing, Beijing,
P. R. China P. R. China
Email: huj@ctbri.com.cn Email: huj@ctbri.com.cn
Tina Tsou
Huawei Technologies
Santa Clara, CA
USA
Email: tina.tsou.zouting@huawei.com
10. Acknowledgements 10. Acknowledgements
Thanks to Ralph Droms for the inspiration from his expired Thanks to Ralph Droms for the inspiration from his expired
[I-D.ietf-dhc-dhcpv6-agentopt-delegate-04], to the DHC working group [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04], to Tomek Mrugalski, Ole
members, Bernie Volz, Ole Troan and Roberta Maglione for the Troan and Alexandru Petrescu for their discussion in the mailing list
discussion in the mailing list, to Christian Jacquenet for pointing of DHC, to Acee Lindem for his discussion in the mailing list of
out the draft shall cover one more use case of ISP-Customer network routing-discussion, to Christian Jacquenet for pointing out the draft
where CPE is directly connected to PE, to Sven Ooghe for some shall cover one more use case of ISP-to-Customer network where CPE is
revisions in the email review, to Shrinivas Ashok Joshi for pointing directly connected to PE, to Sven Ooghe for some revisions in the
out the draft shall cover the mechanism against the case of reboot, email review, to Shrinivas Ashok Joshi for pointing out the draft
to Adrian Farrel for the orientation guide on this draft in IETF80 at shall cover the mechanism against the case of reboot, to Adrian
Prague. 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 12, line 40 skipping to change at page 12, line 39
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.
[I-D.ietf-dhc-dhcpv6-agentopt-delegate-04] [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04]
Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent
Assignment Notification (RAAN) Option", July 2009. Assignment Notification (RAAN) Option", July 2009.
Authors' Addresses Authors' Addresses
Leaf Y. Yeh Leaf Y. Yeh
Huawei Technologies Freelancer Technologies
Shenzhen,
P. R. China P. R. China
Email: leaf.y.yeh@huawei.com Email: leaf.yeh.sdo@gmail.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,
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
 End of changes. 53 change blocks. 
143 lines changed or deleted 137 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/