--- 1/draft-ietf-dhc-dhcpv6-prefix-pool-opt-02.txt 2013-05-02 07:58:20.062276741 +0100 +++ 2/draft-ietf-dhc-dhcpv6-prefix-pool-opt-03.txt 2013-05-02 07:58:20.630290469 +0100 @@ -1,21 +1,21 @@ DHC Working Group L. Yeh Internet-Draft Freelancer Technologies Intended status: Standards Track T. Lemon -Expires: August 14, 2013 Nominum, Inc +Expires: October 28, 2013 Nominum, Inc M. Boucadair France Telecom - February 10, 2013 + April 26, 2013 Prefix Pool Option for DHCPv6 Relay Agent on the Provider Edge Routers - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 + draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 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 through adding or removing aggregation routes according to the status of the prefix pools. The advertising @@ -31,21 +31,21 @@ 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 August 14, 2013. + This Internet-Draft will expire on October 28, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the 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 @@ -55,44 +55,45 @@ 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 Conventions . . . . . . . . . . . . . . . . . 4 3. Scenario and Network Architecture . . . . . . . . . . . . . . 5 4. Prefix Pool Option . . . . . . . . . . . . . . . . . . . . . . 6 5. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 8 + 5.1. Leasequery Requestor Behavior . . . . . . . . . . . . . . 9 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 + 6.1. Leasequery Server Behavior . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 9. Contributors List . . . . . . . . . . . . . . . . . . . . . . 11 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 11.2. Informative References . . . . . . . . . . . . . . . . . 12 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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. The DHCPv6 servers always maintain authoritative information associated with their operations including, but not limited to, the binding data of the delegated IPv6 prefixes, the lease data of the delegated IPv6 prefixes, the status of their prefix pools, etc. A prefix pool configured and maintained on the server can usually be a short prefix (e.g., a /40 prefix), out - of which a longer prefixes (e.g., a /56 prefixes) are delegated to + of which a longer prefixes (e.g., /56 prefixes) are delegated to customer networks. In the scenarios of a centralized DHCPv6 server, the Provider Edge (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) 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 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 the CE routers (see Section 6.2, [BBF TR-177]). @@ -158,82 +159,87 @@ o Prefix Pool: An IPv6 address space allocated with a common prefix, out of which the longer prefixes are delegated via prefix delegation. o aggregation route: A route entry created on an edge router, is based on the knowledge of a prefix pool of the delegated prefixes. o Requestor: A node defined in [RFC5007] that acts as the 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]. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. 3. Scenario and Network Architecture Figure 1 and Figure 2 illustrate two typical cases of the targeted network architectures. +------+------+ DHCPv6 Server - | DHCPv6 | (e.g. Binding entry - | Server | pe#1 - 2001:db8:3450::/44, - | | extract PE_ID=pe#1 - +------+------+ from the Interface_ID=pe#1_cfi#2) + | DHCPv6 | (e.g. Binding entry: + | Server | Relay=nfi-GUA#1, + | | Prefix Pool=2001:db8:3450::/44) + +------+------+ | _________|_________ / \ | ISP Core Network | \___________________/ | + | | Network-facing interface + | (e.g. IPv6 address=nfi-GUA#1) +------+------+ - | Provider | DHCPv6 Relay Agent, DHCPv6 Requestor - | Edge | (e.g. prefix pool=2001:db8:3450::/44) - | Router | + | Provider | + | Edge | DHCPv6 Relay Agent, DHCPv6 Requestor + | Router | (e.g. prefix pool=2001:db8:3450::/44) +------+------+ | Customer-facing interface - | (e.g. Interface_ID=pe#1_cfi#2) + | | +------+------+ | Customer | DHCPv6 Client | Edge | DHCPv6-PD Requesting Router | Router | (e.g. customer network +------+------+ =2001:db8:3456:7800:/56) | _________|_________ / \ | Customer Network | \___________________/ Figure 1: ISP-to-Customer network where CE is directly connected to PE - +------+------+ - | DHCPv6 | DHCPv6 Server - | Server | (e.g. Binding entry - | | pe#3_cfi#4 - 2001:db8:1200::/40) - +------+------+ + +------+------+ DHCPv6 Server + | DHCPv6 | (e.g. Binding entry: + | Server | Relay=nfi-GUA#2, + | | Interface-ID=cfi#3, + +------+------+ Prefix Pool=2001:db8:1200::/40) | _________|_________ / \ | ISP Core Network | \___________________/ | + | | Network-facing interface + | (e.g. IPv6 address=nfi-GUA#2) +------+------+ - | Provider | DHCPv6 Relay Agent, DHCPv6 Requestor - | Edge | (e.g. prefix pool=2001:db8:1200::/40) + | Provider | + | Edge | DHCPv6 Relay Agent, DHCPv6 Requestor | Router | +------+------+ | Customer-facing interface - | (e.g. Interface_ID=pe#3_cfi#4) + | (e.g. Interface-ID=cfi#3) + | Prefix Pool=2001:db8:1200::/40) _________|_________ / \ | Access Network | \___________________/ | | +------+------+ | Customer | DHCPv6 Client | Edge | DHCPv6-PD Requesting Router | Router | (e.g. customer network @@ -259,28 +265,29 @@ | status | pfx-pool-len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | ipv6-prefix (variable length) | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 status: Status of the prefix pool, indicating the availability of the prefix pool maintained 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 - octets in length. Bits outsides of the - pfx-pool-len, if included, MUST be zero. + pfx-pool-len: Length for the prefix pool in bits + ipv6-prefix: IPv6 prefix of the prefix pool, which is + floor((pfx-pool-len+7)/8) octets in length. + Bits outsides of the pfx-pool-len, if included, + MUST be zero. The codes of the status are defined in the following table. Name Code Active 0 Released 1 Reserved 2~255 The 'Active' status of the prefix pool indicated in this option can be used to add the prefix pool and its associated aggregation route @@ -300,113 +307,120 @@ Prefix Pool Option MAY be included by the DHCPv6 server in RELAY-REPL (13), LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) message, and MAY be included by the DHCPv6 relay agent in the RELAY-FORW (12). 5. Relay Agent Behavior The DHCPv6 relay agent who needs the information of prefix pools, SHOULD include the associated requested-option-code in Option Request option (OPTION_ORO, 6) to request the Prefix Pool option - (OPTION_PREFIX_POOL, [TBD-IANA]) from the DHCPv6 server, who - maintains the status of the prefix pools associated with the relay - agent itself (Figure 1) or its particular customer-facing interface - (Figure 2), when receiving the DHCPv6-PD message from clients. The - relay agent SHOULD include this Option Request option for the Prefix - 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 - include the Prefix Pool option with the values of 'pfx-pool-len' and - 'ip6-prefix' to indicate its preference for 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 server can identify the relay - agent itself or its particular customer-facing interface with 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-FORW message to identify the interface of the link on which the - clients are located. + (OPTION_PREFIX_POOL, TBD) from the DHCPv6 server, who maintains the + status of the prefix pools associated with the relay agent itself + (Figure 1) or its particular customer-facing interface (Figure 2), + when receiving the DHCPv6-PD message from clients. The relay agent + SHOULD include this Option Request option for the Prefix 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 include the + Prefix Pool option with the values of 'pfx-pool-len' and 'ip6-prefix' + to indicate its preference for which prefix pool the relay agent + would like the server to return. - The PE router acting as the relay agent MAY set up a table for the - lease or status of the prefix pools on it according to the leases of - the delegated customer prefixes within the prefix pools. The lease - of the prefix pool SHOULD dynamically set to be the maximum lease of - the delegated customer prefix within it. If there is no route entry - directing to the customer network within the aggregation route - 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 relay agent SHOULD include Interface-ID option + (OPTION_INTERFACE_ID, 18) so that the server can identify the + particular customer-facing interface of the relay agent (i.e., the PE + router) with which the prefix pool is associated, if the server can + not use the link-address field specified in the encapsulation of the + DHCPv6 RELAY-FORW message to identify the interface of the link on + which the client is located. After receiving the Prefix Pool option for the relay agent itself or its particular customer-facing interface in the RELAY-REPL (13) message of REPLY (7) from the server, the PE router acting as the relay agent SHOULD confirm the status of the prefix pool according to the leases of delegated customer prefixes within it. If the status of the prefix pool received and confirmed is 'Active', the PE router acting as the relay agent SHOULD add an aggregation route entry in its routing table, if the same entry has not been added before. If the status of the prefix pool received is 'Released', the PE router acting as the relay agent SHOULD withdraw the associated aggregation route entry in its routing table, if the same entry has not been withdrawn before. + The PE router acting as the relay agent MAY set up a table for the + lease or status of the prefix pools on it according to the leases of + the delegated customer prefixes within the prefix pools. The lease + of the prefix pool SHOULD dynamically set to be the maximum lease of + the delegated customer prefix within it. If there is no route entry + directing to the customer network within the aggregation route + 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 PE router acting as the relay agent advertises its routing table including the entries of the aggregation routes based on the information of prefix pools when the routing protocol is enabled on its network-facing interface. +5.1. Leasequery Requestor Behavior + The PE router acting as the relay agent (i.e., Requestor) can use the DHCPv6 Bulk Leasequery [RFC5460] to query the binding data of prefix pools in the 'Active' status from the server. After established a TCP connection with the server, the relay agent SHOULD include Query option (OPTION_LQ_QUERY, 44) and set the proper query-type (QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS or QUERY_BY_REMOTE_ID), link-address and query-options in the LEASEQUERY (14) message. The query options SHOULD include Option Request option to request the Prefix Pool option from the server. 6. Server Behavior According to DHCPv6-PD [RFC3633], if the prefix of the customer network requested in RELAY-FORW (12) message of SOLICIT (1), REQUEST (3), RENEW(5), REBIND (6) from 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-REPL (13) message of - REPLY (7). In order to give a meaningful reply, the server has 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-FORW message is usually - used to identify the access line of the client. + REPLY (7). In order to give a meaningful reply, the server has + always to maintain the binding data of the prefix pool in association + with the identification of the relay itself (Figure 1) or its + customer-facing interface (Figure 2). - After receiving the Option Request option (OPTION_ORO, 6) requesting - the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the RELAY-FORW - messages of the DHCPv6-PD, the server SHOULD include the Prefix Pool - option with the status indicated for the associated relay agent - itself (Figure 1) or its customer-facing interface (Figure 2) in the - RELAY-REPL messages, if the RELAY-FORW messages received are valid. + The source address in the IPv6 packet header of RELAY-FORW message + can be used to identify the DHCPv6 relay agent (i.e., the PE router) + in the case when there is only one relay between the server and the + client; or the peer-address nested in the RELAY-FORW message can be + used to identify the DHCPv6 relay agent (i.e., the PE router) in the + case when there are multiple relays between the server and the + client. The source address or the peer-address mentioned here is + always the globe unique address (GUA) of the network-facing interface + of the PE router. The Interface ID option (OPTION_INTERFACE_ID, 18) + nested in the RELAY-FORW message can be used to identify the access + line of the client. The server MAY use the link-address specified in RELAY-FORW 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 included in the RELAY-FORW message by the - relay agent to identify the relay agent itself or its particular - customer-facing interface 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. According to DHCPv6 [RFC3315], - the server SHOULD copy the Interface ID option from the RELAY-FORW - message into the RELAY-REPL message. + to identify the relay agent itself and its particular customer-facing + interface where the prefix pool is associated, if these link-address + are possible GUA, but the server has to maintain the binding data of + prefix pools in association with these GUA of link-addresses. + + After receiving the Option Request option (OPTION_ORO, 6) requesting + the Prefix Pool option (OPTION_PREFIX_POOL, TBD) in the RELAY-FORW + messages of the DHCPv6-PD, the server SHOULD include the Prefix Pool + option with the prefix and its status indicated for the associated + relay agent itself or its customer-facing interface in the RELAY-REPL + messages, if the RELAY-FORW messages received are valid. As per + DHCPv6 [RFC3315], the server SHOULD copy the Interface-ID option from + the RELAY-FORW message into the RELAY-REPL message. If the administrative policy on the server permits to support route - aggregation on the relay agents for some particular prefix pool, the + aggregation on the relay agents for some particular prefix pools, the status of prefix pool can be determined by the delegated prefixes within the associated prefix pool. If there is at least one delegated prefix within the pool that has a valid lease, the server SHOULD set the status of the associated prefix pool to be 'Active'. After the last prefix released in the associated prefix pool, the server SHOULD set the status of the associated prefix pool to be 'Released'. If the administrative policy on the server does not permit to support route aggregation on the relay agents, the server shall set the status of the associated prefix pools always to be 'Released'. @@ -414,105 +428,97 @@ When the administrator of the server changes the setting to support route aggregation on the relay agent for the particular prefix pool, the status of the prefix pool SHOULD change from 'Released' to be 'Active' if at least one delegated prefix within the prefix pool has the valid lease. When the administrator of the server changes the setting not to support route aggregation on the relay agent for the particular prefix pool, the status of the prefix pool SHOULD change from 'Active' to be 'Released' if at least one delegated prefix within the prefix pool has the valid lease. The server MAY initiate a RELAY-REPL message of RECONFIGURE (10) to immediately trigger RENEW - (5) / REPLY (7) prefix delegation message exchange with Prefix Pool + (5) and REPLY (7) prefix delegation message exchange with Prefix Pool option between one active client and the server. - Multiple prefix pools MAY be associated with the same PE router + Multiple prefix pools can be associated with the same PE router acting as the relay agent, or its customer-facing interface in the - binding table on the server. Note that these prefix pools SHOULD not - overlay, and the delegated customer prefix is only from one prefix - pool. + binding table on the server. + + Note that the prefix pools SHOULD not overlap, and the delegated + customer prefix is only from one prefix pool. + +6.1. Leasequery Server Behavior After receiving the LEASEQUERY (14) message from the relay agent with the OPTION_LQ_QUERY (44) including the OPTION_ORO (6) to request the Prefix Pool option, the server SHOULD include the OPTION_PREFIX_POOL (TBD) in the LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) messages to convey the binding data of the associated prefix pools through the established TCP connection according to mechanism defined in the DHCPv6 Bulk Leasequery [RFC5460]. Each LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) message MAY only contain one OPTION_PREFIX_POOL, or and the associated OPTION_INTERFACE_ID, if the status of the prefix pool is 'active'. In order to be able to provide meaningful replies to different query types, the server has to maintain the relevant association of prefix pools with the Relay_ID, link addresses or Remote_IDs of the relay agent in its binding database. 7. Security Considerations Security issues related DHCPv6 are described in Section 23 of - [RFC3315] and Section 15 of [RFC3633]. + [RFC3315] and Section 15 of [RFC3633]. The administrator of the + DHCPv6 server should pay more attention to the configuration of the + prefix pools, for examples, a. ::/0 may cause a routing problem in + the whole ISP network; b. the configuration of prefix pool should + avoid overlap in the address plan, and etc. 8. IANA Considerations This document requests to assign a new option code for Option_Prefix_Pool in the registry of DHCPv6 Option Codes (http:// www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml). -9. Contributors List - - Juergen Schoenwaelder - Jacobs University Bremen - Bremen - Germany - - Email: j.schoenwaelder@jacobs-university.de - - Jie Hu - China Telecom - Beijing, - P. R. China - - Email: huj@ctbri.com.cn - -10. Acknowledgements +9. Acknowledgements Thanks to Ralph Droms for the inspiration from his expired - [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04], to Tomek Mrugalski, Ole - Troan and Alexandru Petrescu for their discussion in the mailing list - of DHC, to Acee Lindem for his discussion in the mailing list of - routing-discussion, to Christian Jacquenet for pointing out the draft - shall cover one more use case of ISP-to-Customer network where CPE is - directly connected to PE, to Sven Ooghe for some revisions in the + [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04], to Tomek Mrugalski, + Bernie Volz, Ole Troan and Alexandru Petrescu for their discussion in + the mailing list of DHC, to Acee Lindem for his discussion in the + mailing list of routing-discussion, to Christian Jacquenet for + pointing out the draft shall cover one more use case of ISP-to- + Customer network where CPE is directly connected to PE, to Sven + Ooghe, Juergen Schoenwaelder and Jie Hu for some revisions in the email review, to Shrinivas Ashok Joshi for pointing out the draft shall cover the mechanism against the case of reboot, to Adrian Farrel for the orientation guide on this draft in IETF80 at Prague. -11. References +10. References -11.1. Normative References +10.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 +10.2. Informative References [BBF TR-177] Broadband Forum, "IPv6 in the context of TR-101, Issue 1", November 2010. [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04] Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent Assignment Notification (RAAN) Option", July 2009. Authors' Addresses