idnits 2.17.1 draft-ietf-dhc-dhcpv6-prefix-pool-opt-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Note that the prefix pools SHOULD not overlap, and the delegated customer prefix is only from one prefix pool. -- The document date (April 26, 2013) is 4017 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- No information found for draft-ietf-dhc-dhcpv6-agentopt-delegate-04 - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group L. Yeh 3 Internet-Draft Freelancer Technologies 4 Intended status: Standards Track T. Lemon 5 Expires: October 28, 2013 Nominum, Inc 6 M. Boucadair 7 France Telecom 8 April 26, 2013 10 Prefix Pool Option for DHCPv6 Relay Agent on the Provider Edge Routers 11 draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 13 Abstract 15 The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix 16 Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 17 relay agent implemented on a Provider Edge (PE) router about active 18 prefix pools allocated by the DHCPv6 server to the PE router. The 19 information of active prefix pools can be used to enforce IPv6 route 20 aggregation on the PE router through adding or removing aggregation 21 routes according to the status of the prefix pools. The advertising 22 of the aggregation routes in the routing protocol enabled on the 23 network-facing interface of PE routers will dramatically decreases 24 the number of the routing table entries in the ISP network. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 28, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 62 3. Scenario and Network Architecture . . . . . . . . . . . . . . 5 63 4. Prefix Pool Option . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Leasequery Requestor Behavior . . . . . . . . . . . . . . 9 66 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.1. Leasequery Server Behavior . . . . . . . . . . . . . . . . 11 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The DHCPv6 protocol [RFC3315] specifies a mechanism for the 79 assignment of IPv6 address and configuration information to IPv6 80 nodes. The DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] specifies 81 a mechanism for the delegation of IPv6 prefixes from the Delegating 82 Router (DR) acting as the DHCPv6 server to the Requesting Routers 83 (RR) acting as the DHCPv6 clients. The DHCPv6 servers always 84 maintain authoritative information associated with their operations 85 including, but not limited to, the binding data of the delegated IPv6 86 prefixes, the lease data of the delegated IPv6 prefixes, the status 87 of their prefix pools, etc. A prefix pool configured and maintained 88 on the server can usually be a short prefix (e.g., a /40 prefix), out 89 of which a longer prefixes (e.g., /56 prefixes) are delegated to 90 customer networks. 92 In the scenarios of a centralized DHCPv6 server, the Provider Edge 93 (PE) routers act as DHCPv6 relay agents, when the DHCPv6 server and 94 the Customer Edge (CE) router (a.k.a. Routed-RG or Routed-CPE) 95 acting as RRs and the DHCPv6 clients, are not on the same link. For 96 ensuring reachability, the PE routers always need to add or withdraw 97 the route entries directing to each customer network in their routing 98 table to reflect the status of IPv6 prefixes delegated by the DHCPv6 99 server to the CE routers (see Section 6.2, [BBF TR-177]). 101 When a routing protocol is enabled on the network-facing interface of 102 the PE router, all the routes directing to the customer networks are 103 advertised in the ISP network. It will make the number of route 104 entries in the routing table on the ISP routers be unacceptable 105 large. Hence, it is desirable to aggregate the routes directing to 106 the customer networks on the PE router. 108 Because the prefixes of the customer networks can not be guaranteed 109 to be active and continuous, the routing protocol enabled on the PE 110 router in general can not create one aggregation route automatically 111 to cover all the prefixes delegated within the prefix pool. When the 112 PE router acts as the relay agent, it can not be aware about the 113 status of the prefix pools in general. The way to make the 114 aggregation routes (e.g., black-hole routes) pointing to each of the 115 prefix pools could be to configure them manually and permanently, but 116 it is meant to a large amount of the handwork on each PE router for 117 its operation and maintenance. 119 This document proposes a new Prefix Pool option for the DHCPv6 relay 120 agent implemented on PE routers, allowing the DHCPv6 server to notify 121 the DHCPv6 relay agent the information about the prefix pools. After 122 the PE router received the prefix pools, the aggregation route 123 entries can be added or withdrawn in the routing table of the PE 124 router according to the provision status of the prefix pools. The 125 aggregation routes will then be advertised into the ISP network 126 through the routing protocol enabled on the PE's network-facing 127 interface. 129 DHCPv6 Bulk Leasequery [RFC5460] specifies a mechanism for bulk 130 transfer of the binding data of each delegated prefix from the server 131 to the requestor, typically a relay agent, to support the replacement 132 or reboot event of a relay agent. In this document, the capability 133 of DHCPv6 Bulk Leasequery will be extended to support the bulk 134 transfer of the prefix and its status of the prefix pools for the 135 route aggregation. 137 The automatic mechanisms described in this document depend on the 138 existing DHCPv6 protocols and implementations without requiring a new 139 DHCPv6 message or a new interface for the configuration of the 140 aggregation route. The administrator of the ISP network can decide 141 whether to inject the aggregation route or not based on the policies 142 defined on the DHCPv6 server. 144 2. Terminology and Conventions 146 This document defines a new DHCPv6 option to communicate the prefix 147 and its status of an IPv6 prefix pool. Definitions for terms and 148 acronyms not specified in this document are defined in [RFC3315], 149 [RFC3633], [RFC5007] and [RFC5460]. 151 The following terms have been employed in this document: 153 o Requesting Router (RR): A router defined in [RFC3633] that acts as 154 a DHCPv6 client, and is requesting prefix to be delegated. 156 o Delegating Router (DR): A router defined in [RFC3633] that acts as 157 a DHCPv6 server, and is responding to the prefix request. 159 o Prefix Pool: An IPv6 address space allocated with a common prefix, 160 out of which the longer prefixes are delegated via prefix 161 delegation. 163 o aggregation route: A route entry created on an edge router, is 164 based on the knowledge of a prefix pool of the delegated prefixes. 166 o Requestor: A node defined in [RFC5007] that acts as the leasequery 167 client. 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 3. Scenario and Network Architecture 175 Figure 1 and Figure 2 illustrate two typical cases of the targeted 176 network architectures. 178 +------+------+ DHCPv6 Server 179 | DHCPv6 | (e.g. Binding entry: 180 | Server | Relay=nfi-GUA#1, 181 | | Prefix Pool=2001:db8:3450::/44) 182 +------+------+ 183 | 184 _________|_________ 185 / \ 186 | ISP Core Network | 187 \___________________/ 188 | 189 | 190 | Network-facing interface 191 | (e.g. IPv6 address=nfi-GUA#1) 192 +------+------+ 193 | Provider | 194 | Edge | DHCPv6 Relay Agent, DHCPv6 Requestor 195 | Router | (e.g. prefix pool=2001:db8:3450::/44) 196 +------+------+ 197 | Customer-facing interface 198 | 199 | 200 +------+------+ 201 | Customer | DHCPv6 Client 202 | Edge | DHCPv6-PD Requesting Router 203 | Router | (e.g. customer network 204 +------+------+ =2001:db8:3456:7800:/56) 205 | 206 _________|_________ 207 / \ 208 | Customer Network | 209 \___________________/ 211 Figure 1: ISP-to-Customer network where CE is directly connected to 212 PE 214 +------+------+ DHCPv6 Server 215 | DHCPv6 | (e.g. Binding entry: 216 | Server | Relay=nfi-GUA#2, 217 | | Interface-ID=cfi#3, 218 +------+------+ Prefix Pool=2001:db8:1200::/40) 219 | 220 _________|_________ 221 / \ 222 | ISP Core Network | 223 \___________________/ 224 | 225 | 226 | Network-facing interface 227 | (e.g. IPv6 address=nfi-GUA#2) 228 +------+------+ 229 | Provider | 230 | Edge | DHCPv6 Relay Agent, DHCPv6 Requestor 231 | Router | 232 +------+------+ 233 | Customer-facing interface 234 | (e.g. Interface-ID=cfi#3) 235 | Prefix Pool=2001:db8:1200::/40) 236 _________|_________ 237 / \ 238 | Access Network | 239 \___________________/ 240 | 241 | 242 +------+------+ 243 | Customer | DHCPv6 Client 244 | Edge | DHCPv6-PD Requesting Router 245 | Router | (e.g. customer network 246 +------+------+ =2001:db8:1234:5600:/56) 247 | 248 _________|_________ 249 / \ 250 | Customer Network | 251 \___________________/ 253 Figure 2: ISP-to-Customer network where CE is connected to PE through 254 access network 256 4. Prefix Pool Option 258 The format of the Prefix Pool option is shown in Figure 3. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | OPTION_PREFIX_POOL | option-length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | status | pfx-pool-len | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 267 | | 268 | ipv6-prefix (variable length) | 269 | | 270 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 option-code: OPTION_PREFIX_POOL (TBA-IANA) 275 option-length: 2 + length of ipv6-prefix in octets 276 status: Status of the prefix pool, indicating the 277 availability of the prefix pool maintained 278 on the server. 279 pfx-pool-len: Length for the prefix pool in bits 280 ipv6-prefix: IPv6 prefix of the prefix pool, which is 281 floor((pfx-pool-len+7)/8) octets in length. 282 Bits outsides of the pfx-pool-len, if included, 283 MUST be zero. 285 The codes of the status are defined in the following table. 287 Name Code 288 Active 0 289 Released 1 290 Reserved 2~255 292 The 'Active' status of the prefix pool indicated in this option can 293 be used to add the prefix pool and its associated aggregation route 294 on the relay agent; while the 'Released' status of prefix pool 295 indicated in this option can be used to withdraw the prefix pool and 296 its associated aggregation route on the relay agent. 298 If the administrative policy on the server permits to support route 299 aggregation on the relay agent, the status of prefix pool can be 300 determined by the delegated prefixes within the associated prefix 301 pool: If there is one delegated prefix within the pool that has a 302 valid lease, the status of the prefix pool will be 'Active'; 303 otherwise, the status of the prefix pool is 'Released'. If the 304 administrative policy on the server does not permit to support route 305 aggregation on the relay agent, the status of the prefix pool will 306 always be 'Released'. 308 Prefix Pool Option MAY be included by the DHCPv6 server in RELAY-REPL 309 (13), LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) message, and MAY 310 be included by the DHCPv6 relay agent in the RELAY-FORW (12). 312 5. Relay Agent Behavior 314 The DHCPv6 relay agent who needs the information of prefix pools, 315 SHOULD include the associated requested-option-code in Option Request 316 option (OPTION_ORO, 6) to request the Prefix Pool option 317 (OPTION_PREFIX_POOL, TBD) from the DHCPv6 server, who maintains the 318 status of the prefix pools associated with the relay agent itself 319 (Figure 1) or its particular customer-facing interface (Figure 2), 320 when receiving the DHCPv6-PD message from clients. The relay agent 321 SHOULD include this Option Request option for the Prefix Pool option 322 in the RELAY-FORW (12) message of SOLICIT (1), REQUEST (3), RENEW(5), 323 REBIND (6) and RELEASE (8). The relay agent MAY also include the 324 Prefix Pool option with the values of 'pfx-pool-len' and 'ip6-prefix' 325 to indicate its preference for which prefix pool the relay agent 326 would like the server to return. 328 The relay agent SHOULD include Interface-ID option 329 (OPTION_INTERFACE_ID, 18) so that the server can identify the 330 particular customer-facing interface of the relay agent (i.e., the PE 331 router) with which the prefix pool is associated, if the server can 332 not use the link-address field specified in the encapsulation of the 333 DHCPv6 RELAY-FORW message to identify the interface of the link on 334 which the client is located. 336 After receiving the Prefix Pool option for the relay agent itself or 337 its particular customer-facing interface in the RELAY-REPL (13) 338 message of REPLY (7) from the server, the PE router acting as the 339 relay agent SHOULD confirm the status of the prefix pool according to 340 the leases of delegated customer prefixes within it. If the status 341 of the prefix pool received and confirmed is 'Active', the PE router 342 acting as the relay agent SHOULD add an aggregation route entry in 343 its routing table, if the same entry has not been added before. If 344 the status of the prefix pool received is 'Released', the PE router 345 acting as the relay agent SHOULD withdraw the associated aggregation 346 route entry in its routing table, if the same entry has not been 347 withdrawn before. 349 The PE router acting as the relay agent MAY set up a table for the 350 lease or status of the prefix pools on it according to the leases of 351 the delegated customer prefixes within the prefix pools. The lease 352 of the prefix pool SHOULD dynamically set to be the maximum lease of 353 the delegated customer prefix within it. If there is no route entry 354 directing to the customer network within the aggregation route 355 associated with the prefix pool or the lease of prefix pool runs out, 356 the PE router acting as the relay agent SHOULD automatically withdraw 357 the aggregation route. 359 The PE router acting as the relay agent advertises its routing table 360 including the entries of the aggregation routes based on the 361 information of prefix pools when the routing protocol is enabled on 362 its network-facing interface. 364 5.1. Leasequery Requestor Behavior 366 The PE router acting as the relay agent (i.e., Requestor) can use the 367 DHCPv6 Bulk Leasequery [RFC5460] to query the binding data of prefix 368 pools in the 'Active' status from the server. After established a 369 TCP connection with the server, the relay agent SHOULD include Query 370 option (OPTION_LQ_QUERY, 44) and set the proper query-type 371 (QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS or QUERY_BY_REMOTE_ID), 372 link-address and query-options in the LEASEQUERY (14) message. The 373 query options SHOULD include Option Request option to request the 374 Prefix Pool option from the server. 376 6. Server Behavior 378 According to DHCPv6-PD [RFC3633], if the prefix of the customer 379 network requested in RELAY-FORW (12) message of SOLICIT (1), REQUEST 380 (3), RENEW(5), REBIND (6) from the DHCPv6 client (i.e., the RR) has a 381 valid lease, the DHCPv6 server (i.e., the DR) will delegate the 382 prefix with the relevant parameters in the RELAY-REPL (13) message of 383 REPLY (7). In order to give a meaningful reply, the server has 384 always to maintain the binding data of the prefix pool in association 385 with the identification of the relay itself (Figure 1) or its 386 customer-facing interface (Figure 2). 388 The source address in the IPv6 packet header of RELAY-FORW message 389 can be used to identify the DHCPv6 relay agent (i.e., the PE router) 390 in the case when there is only one relay between the server and the 391 client; or the peer-address nested in the RELAY-FORW message can be 392 used to identify the DHCPv6 relay agent (i.e., the PE router) in the 393 case when there are multiple relays between the server and the 394 client. The source address or the peer-address mentioned here is 395 always the globe unique address (GUA) of the network-facing interface 396 of the PE router. The Interface ID option (OPTION_INTERFACE_ID, 18) 397 nested in the RELAY-FORW message can be used to identify the access 398 line of the client. 400 The server MAY use the link-address specified in RELAY-FORW message 401 to identify the relay agent itself and its particular customer-facing 402 interface where the prefix pool is associated, if these link-address 403 are possible GUA, but the server has to maintain the binding data of 404 prefix pools in association with these GUA of link-addresses. 406 After receiving the Option Request option (OPTION_ORO, 6) requesting 407 the Prefix Pool option (OPTION_PREFIX_POOL, TBD) in the RELAY-FORW 408 messages of the DHCPv6-PD, the server SHOULD include the Prefix Pool 409 option with the prefix and its status indicated for the associated 410 relay agent itself or its customer-facing interface in the RELAY-REPL 411 messages, if the RELAY-FORW messages received are valid. As per 412 DHCPv6 [RFC3315], the server SHOULD copy the Interface-ID option from 413 the RELAY-FORW message into the RELAY-REPL message. 415 If the administrative policy on the server permits to support route 416 aggregation on the relay agents for some particular prefix pools, the 417 status of prefix pool can be determined by the delegated prefixes 418 within the associated prefix pool. If there is at least one 419 delegated prefix within the pool that has a valid lease, the server 420 SHOULD set the status of the associated prefix pool to be 'Active'. 421 After the last prefix released in the associated prefix pool, the 422 server SHOULD set the status of the associated prefix pool to be 423 'Released'. If the administrative policy on the server does not 424 permit to support route aggregation on the relay agents, the server 425 shall set the status of the associated prefix pools always to be 426 'Released'. 428 When the administrator of the server changes the setting to support 429 route aggregation on the relay agent for the particular prefix pool, 430 the status of the prefix pool SHOULD change from 'Released' to be 431 'Active' if at least one delegated prefix within the prefix pool has 432 the valid lease. When the administrator of the server changes the 433 setting not to support route aggregation on the relay agent for the 434 particular prefix pool, the status of the prefix pool SHOULD change 435 from 'Active' to be 'Released' if at least one delegated prefix 436 within the prefix pool has the valid lease. The server MAY initiate 437 a RELAY-REPL message of RECONFIGURE (10) to immediately trigger RENEW 438 (5) and REPLY (7) prefix delegation message exchange with Prefix Pool 439 option between one active client and the server. 441 Multiple prefix pools can be associated with the same PE router 442 acting as the relay agent, or its customer-facing interface in the 443 binding table on the server. 445 Note that the prefix pools SHOULD not overlap, and the delegated 446 customer prefix is only from one prefix pool. 448 6.1. Leasequery Server Behavior 450 After receiving the LEASEQUERY (14) message from the relay agent with 451 the OPTION_LQ_QUERY (44) including the OPTION_ORO (6) to request the 452 Prefix Pool option, the server SHOULD include the OPTION_PREFIX_POOL 453 (TBD) in the LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) messages 454 to convey the binding data of the associated prefix pools through the 455 established TCP connection according to mechanism defined in the 456 DHCPv6 Bulk Leasequery [RFC5460]. Each LEASEQUERY-REPLY (15) and 457 LEASEQUERY-DATA (17) message MAY only contain one OPTION_PREFIX_POOL, 458 or and the associated OPTION_INTERFACE_ID, if the status of the 459 prefix pool is 'active'. In order to be able to provide meaningful 460 replies to different query types, the server has to maintain the 461 relevant association of prefix pools with the Relay_ID, link 462 addresses or Remote_IDs of the relay agent in its binding database. 464 7. Security Considerations 466 Security issues related DHCPv6 are described in Section 23 of 467 [RFC3315] and Section 15 of [RFC3633]. The administrator of the 468 DHCPv6 server should pay more attention to the configuration of the 469 prefix pools, for examples, a. ::/0 may cause a routing problem in 470 the whole ISP network; b. the configuration of prefix pool should 471 avoid overlap in the address plan, and etc. 473 8. IANA Considerations 475 This document requests to assign a new option code for 476 Option_Prefix_Pool in the registry of DHCPv6 Option Codes (http:// 477 www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml). 479 9. Acknowledgements 481 Thanks to Ralph Droms for the inspiration from his expired 482 [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04], to Tomek Mrugalski, 483 Bernie Volz, Ole Troan and Alexandru Petrescu for their discussion in 484 the mailing list of DHC, to Acee Lindem for his discussion in the 485 mailing list of routing-discussion, to Christian Jacquenet for 486 pointing out the draft shall cover one more use case of ISP-to- 487 Customer network where CPE is directly connected to PE, to Sven 488 Ooghe, Juergen Schoenwaelder and Jie Hu for some revisions in the 489 email review, to Shrinivas Ashok Joshi for pointing out the draft 490 shall cover the mechanism against the case of reboot, to Adrian 491 Farrel for the orientation guide on this draft in IETF80 at Prague. 493 10. References 495 10.1. Normative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 501 and M. Carney, "Dynamic Host Configuration Protocol for 502 IPv6 (DHCPv6)", RFC 3315, July 2003. 504 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 505 Host Configuration Protocol (DHCP) version 6", RFC 3633, 506 December 2003. 508 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 509 "DHCPv6 Leasequery", RFC 5007, September 2007. 511 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 512 February 2009. 514 10.2. Informative References 516 [BBF TR-177] 517 Broadband Forum, "IPv6 in the context of TR-101, Issue 1", 518 November 2010. 520 [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04] 521 Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent 522 Assignment Notification (RAAN) Option", July 2009. 524 Authors' Addresses 526 Leaf Y. Yeh 527 Freelancer Technologies 528 P. R. China 530 Email: leaf.yeh.sdo@gmail.com 532 Ted Lemon 533 Nominum, Inc 534 USA 536 Email: Ted.Lemon@nominum.com 537 Mohamed Boucadair 538 France Telecom 539 France 541 Email: mohamed.boucadair@orange.com