idnits 2.17.1 draft-ietf-dhc-dhcpv6-prefix-pool-opt-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 10, 2012) is 4238 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) == Missing Reference: 'TBD' is mentioned on line 448, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group L. Yeh 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track T. Lemon 5 Expires: March 14, 2013 Nominum, Inc 6 M. Boucadair 7 France Telecom 8 September 10, 2012 10 Prefix Pool Option for DHCPv6 Relay Agents on Provider Edge Routers 11 draft-ietf-dhc-dhcpv6-prefix-pool-opt-00 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 by adding or removing aggregation routes 21 according to the status of the prefix pools. The advertising of the 22 aggregation routes in the routing protocol enabled on the network- 23 facing interface of PE routers will dramatically decreases the number 24 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 March 14, 2013. 43 Copyright Notice 45 Copyright (c) 2012 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 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 9. Contributors List . . . . . . . . . . . . . . . . . . . . . . 12 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 11.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 The DHCPv6 protocol [RFC3315] specifies a mechanism for the 78 assignment of IPv6 address and configuration information to IPv6 79 nodes. The DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] specifies 80 a mechanism for the delegation of IPv6 prefixes from the Delegating 81 Router (DR) acting as the DHCPv6 server to the Requesting Routers 82 (RR) acting as the DHCPv6 Clients. DHCPv6 servers always maintain 83 authoritative information associated to their operations including, 84 but not limited to, the binding data of the delegated IPv6 prefixes, 85 the lease data of the delegated IPv6 prefixes, and the status of 86 their prefix pools. A prefix pool configured and maintained on the 87 server can usually be a short prefix (e.g., a /40 prefix) out of 88 which the longer prefixes (e.g., /56 prefixes) are delegated to 89 customer networks. 91 In the scenario of a centralized DHCPv6 server, the Provider Edge 92 (PE) routers act as DHCPv6 relay agents when the DHCPv6 server and 93 the Customer Edge (CE) router (a.k.a. Routed-RG or Routed-CPE) 94 acting as RRs and DHCPv6 clients are not on the same link. For 95 ensuring reachability, the PE routers always need to add or withdraw 96 the route entries directing to each customer network in their routing 97 table to reflect the status of IPv6 prefixes delegated by the DHCPv6 98 server to CE routers (see Section 6.2, [BBF TR-177]). 100 When a routing protocol is enabled on the network-facing interface of 101 the PE router, all the routes directing to the customer networks are 102 advertised in the ISP network. This will make the number of route 103 entries in the routing table on the ISP router be unacceptable large. 104 Hence, it is desirable to aggregate the routes directing to the 105 customer networks on the PE router. 107 Because the prefixes of the customer networks can not be guaranteed 108 to be active and continuous, the routing protocol enabled on the PE 109 router in general can not create one aggregation route automatically 110 to cover all the prefixes delegated within the prefix pool. One way 111 to make the aggregation routes (e.g., black-hole routes) pointing to 112 each of the prefix pools is to configure them manually and 113 permanently, but the PE router is not really aware about the status 114 of the prefix pools, especially when it acts as the relay agent. 116 This document proposes a new Prefix Pool option for the DHCPv6 relay 117 agent implemented on PE routers, allowing the DHCPv6 server to notify 118 the DHCPv6 relay agent about the prefix of pools. After the PE 119 router received information about the prefix pools, the aggregation 120 route entries per the provision status of the prefix pools can be 121 added or withdrawn in the routing table of the PE router. The 122 aggregation routes will then be advertised into the ISP network 123 through the routing protocol enabled on the PE's network-facing 124 interface. 126 DHCPv6 Bulk Leasequery [RFC5460] specifies a mechanism for bulk 127 transfer of the binding data of each delegated prefix from the server 128 to the requestor, typically a DHCPv6 relay agent, to support the 129 replacement or reboot event of a relay agent. In this document, the 130 capability of DHCPv6 Bulk Leasequery will be extended to support the 131 bulk transfer of the status of the prefix pools for route 132 aggregation. 134 The automatic mechanisms described in this document depend on the 135 existing DHCPv6 protocols and implementations without requiring a new 136 DHCPv6 message or a new interface for the configuration of the 137 aggregation route. The administrator of the ISP network can decide 138 whether to inject the aggregation route or not based on the policies 139 defined on the DHCPv6 server. 141 2. Terminology and Conventions 143 This document defines a new DHCPv6 option to communicate the prefix 144 of an IPv6 prefix pool. This document SHOULD be read in conjunction 145 with the DHCPv6 specifications, [RFC3315], [RFC3633], [RFC5007] and 146 [RFC5460], for understanding the complete mechanism. Definitions for 147 terms and acronyms not specified in this document are defined in 148 [RFC3315], [RFC3633], [RFC3769], [RFC5007] and [RFC5460]. 150 The following terms can be found in this document: 152 o Requesting Router (RR): A router defined in [RFC3633] that acts as 153 a DHCPv6 client, and is requesting prefix(es) to be delegated. 155 o Delegating Router (DR): A router defined in [RFC3633] that acts as 156 a DHCPv6 server, and is responding to the prefix request. 158 o Prefix Pool: An IPv6 address space allocated with a common prefix 159 out of which the longer prefixes are delegated via prefix 160 delegation. 162 o aggregation Route: A route entry created on an edge router, is 163 based on the knowledge of a delegated prefix pool. 165 o Requestor: A node defined in [RFC5007] that acts as the leasequery 166 client. 168 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 169 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 170 document, are to be interpreted as described in BCP 14, [RFC2119]. 172 3. Scenario and Network Architecture 174 Figure 1 and Figure 2 illustrate two typical cases of the targeted 175 network architectures. 177 +------+------+ DHCPv6 Server 178 | DHCPv6 | (e.g. Binding entry 179 | Server | pe#1 - 2001:db8:1230::/44 180 | | extract PE_ID=pe#1 181 +------+------+ from the Interface_ID=pe#1_cfi#2) 182 | 183 _________|_________ 184 / \ 185 | ISP Core Network | 186 \___________________/ 187 | 188 | Network-facing interface 189 +------+------+ 190 | Provider | DHCPv6 Relay Agent, DHCPv6 Requestor 191 | Edge | (e.g. prefix pool=2001:db8:1230::/44) 192 | Router | 193 +------+------+ 194 | Customer-facing interface 195 | (e.g. Interface_ID=pe#1_cfi#2) 196 | 197 +------+------+ 198 | Customer | DHCPv6 Client 199 | Edge | DHCPv6-PD Requesting Router 200 | Router | (e.g. customer network 201 +------+------+ =2001:db8:1234:5600:/56) 202 | 203 _________|_________ 204 / \ 205 | Customer Network | 206 \___________________/ 208 Figure 1: Use case of ISP-Customer network where CPE is directly 209 connected to PE 211 +------+------+ 212 | DHCPv6 | DHCPv6 Server 213 | Server | (e.g. Binding entry 214 | | pe#3_cfi#4 - 2001:db8:3400::/40) 215 +------+------+ 216 | 217 _________|_________ 218 / \ 219 | ISP Core Network | 220 \___________________/ 221 | 222 | Network-facing interface 223 +------+------+ 224 | Provider | DHCPv6 Relay Agent, DHCPv6 Requestor 225 | Edge | (e.g. prefix pool=2001:db8:3400::/40) 226 | Router | 227 +------+------+ 228 | Customer-facing interface 229 | (e.g. Interface_ID=pe#3_cfi#4) 230 _________|_________ 231 / \ 232 | Access Network | 233 \___________________/ 234 | 235 | 236 +------+------+ 237 | Customer | DHCPv6 Client 238 | Edge | DHCPv6-PD Requesting Router 239 | Router | (e.g. customer network 240 +------+------+ =2001:db8:1234:5600:/56) 241 | 242 _________|_________ 243 / \ 244 | Customer Network | 245 \___________________/ 247 Figure 2: Use case of ISP-Customer network where CPE is connected to 248 PE through access network 250 4. Prefix Pool Option 252 The format of the Prefix Pool option is shown in Figure 3. 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | OPTION_PREFIX_POOL | option-length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | status | pfx-pool-len | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 261 | | 262 | ipv6-prefix (variable length) | 263 | | 264 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 option-code: OPTION_PREFIX_POOL (TBD) 269 option-length: 2 + length of ipv6-prefix (in Octets) 270 pfx-pool-len: Length for the prefix pool in bits 271 status: Status of the prefix pool, indicating the 272 availability of the prefix pool maintained 273 on the server. 274 ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16 275 octets in length. Bits outsides of the 276 pfx-pool-len, if included, MUST be zero. 278 The codes of the status are defined in the following table. 280 Name Code 281 Active 0 282 Released 1 283 Reserved 2~255 285 The 'Active' status of the prefix pool indicated in this option can 286 be used to add the prefix pool and its associated aggregation route 287 on the relay agent; while the 'Released' status of prefix pool 288 indicated in this option can be used to withdraw the prefix pool and 289 its associated aggregation route on the relay agent. 291 If the administrative policy on the DHCPv6 server permits to support 292 route aggregation on the relay agent, the status of prefix pool can 293 be determined by the delegated prefixes within the associated prefix 294 pool. If there is one delegated prefix within the pool that has a 295 valid lease, the status of the prefix pool will be 'Active'. 296 Otherwise, the status of the prefix pool is 'Released'. If the 297 administrative policy on the server does not permit to support route 298 aggregation on the DHCPv6 relay agent, the status of the prefix pool 299 will always be 'Released'. 301 Discussion: 303 The alternative option might include the lease information in the 304 prefix pool, then populate it to relay agent, make the state 305 machine on the relay agent keep synchronizing the lease and status 306 of the associated prefix pool with the server. But the solution 307 proposed in this draft is to let relay agent confirm the received 308 status of the prefix pool by itself as per the leases of delegated 309 customer prefixes within it, and build its own lease for the 310 prefix pool. 312 Prefix Pool Option MAY be included by the DHCPv6 server in RELAY-REPL 313 (13), LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) message, or MAY 314 be included by the DHCPv6 relay agent in the RELAY-FORW (12). 316 5. Relay Agent Behavior 318 The relay agent who needs the information of prefix pools, MUST 319 include the associated requested-option-code in Option Request option 320 (OPTION_ORO, 6) to request the Prefix Pool option 321 (OPTION_PREFIX_POOL, [TBD]) from the DHCPv6 server, who maintains the 322 status of the prefix pools associated to the relay agent itself 323 (Figure 1) or its particular customer-facing interface (Figure 2), 324 when receiving the DHCPv6-PD message from clients. The DHCPv6 relay 325 agent MAY include this Option Request option for the Prefix Pool 326 option in the RELAY-FORW (12) message of SOLICIT (1), REQUEST (3), 327 RENEW(5), REBIND (6) and RELEASE (8). The relay agent MAY also 328 include the Prefix Pool option with the values of pfx-pool-len and 329 IPv6-prefix to indicate its preference, which prefix pool the relay 330 agent would like the server to return. 332 The relay agent SHOULD include the Interface ID option 333 (OPTION_INTERFACE_ID, 18) so that the DHCPv6 server can identify the 334 relay agent itself or its particular customer-facing interface to 335 which the prefix pool is associated, if the server would not like to 336 use the link-address field specified in the encapsulation of the 337 DHCPv6 relay-forward message to identify the interface of the link on 338 which the clients are located. 340 The relay agent MAY set up a table for the leases and/or status of 341 the prefix pools on it as per the delegated customer prefixes within 342 it. The lease of the prefix pools MUST dynamically set to be the 343 maximum lease of the delegated customer prefixes. If there is no 344 route entry directing to the customer network within the aggregation 345 route associated with the prefix pool, the relay agent shall 346 automatically withdraw the aggregation route. 348 After receiving the Prefix Pool option for the relay agent itself or 349 its particular customer-facing interface in the relay-reply message 350 (13) of REPLY (7) from the DHCPv6 server, the relay agent acting as 351 the PE router shall confirm the status of the prefix pool as per the 352 leases of delegated customer prefixes within it, then add the 353 aggregation route entry per the status of the prefix pool. If the 354 status of the prefix pool received and confirmed is 'Active', the 355 relay agent shall add an aggregation route entry in its routing 356 table, if the same entry has not been added in before. If the status 357 of the prefix pool received is 'Released', the relay agent shall 358 withdraw the associated aggregation route entry in its routing table, 359 if the same entry has not been withdrawn before. 361 The relay agent advertises its routing table including the entries of 362 the aggregation routes based on the information of prefix pools when 363 the routing protocol is enabled on its network-facing interface. 365 The Relay Agent (i.e., Requestor) can use the DHCPv6 Bulk Leasequery 366 [RFC5460] to query the binding data of prefix pools in the 'Active' 367 status from the server. After established a TCP connection with the 368 DHCPv6 server, the relay agent MUST include Query option 369 (OPTION_LQ_QUERY, 44) and set the proper query-type 370 (QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, QUERY_BY_REMOTE_ID), link- 371 address and query-options in the LEASEQUERY (14) message. The query 372 options MUST include Option Request option (OPTION_ORO, 6) to request 373 the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) from the server. 375 6. Server Behavior 377 Per DHCPv6-PD [RFC3633], if the prefix of the customer network 378 requested in relay-forward (12) message of SOLICIT, REQUEST, RENEW, 379 REBIND from the DHCPv6 client (i.e., the RR) has a valid lease, the 380 DHCPv6 server (i.e., the DR) will delegate the prefix with the 381 relevant parameters in the relay-reply (13) message of REPLY. In 382 order to give a meaningful reply, the server has to be able to 383 maintain the binding data of the delegated IPv6 prefixes with the 384 identification of the client. The Interface ID option 385 (OPTION_INTERFACE_ID, 18) nested in the relay-forward message is 386 usually used to identify the access line of the client. 388 After receiving the Option Request option (OPTION_ORO, 6) requesting 389 the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay- 390 forward messages of the DHCPv6-PD, the server MUST include the Prefix 391 Pool option with the status indicated for the associated relay agent 392 itself (Figure 1) or its customer-facing interface (Figure 2) in the 393 relay-reply messages if the relay-forward messages received are 394 valid. 396 The server MAY use the link-address specified in relay-forward 397 message to identify the relay agent itself or its particular 398 customer-facing interface where the prefix pool is associated, but 399 the server has to maintain the binding data of prefix pools in 400 association with these link-addresses. To be more readable, the 401 server can alternatively use the Interface ID option 402 (OPTION_INTERFACE_ID, 18) included in the relay-forward message by 403 the relay agent to identify the relay agent itself (Figure 1) or its 404 particular customer-facing interface (Figure 2) where the prefix pool 405 is associated. In order to give a meaningful reply, the server has 406 to maintain the binding data of prefix pools in association with the 407 information derived from the Interface ID option. 409 Per DHCPv6 [RFC3315], the server shall copy the same Interface ID 410 option received via the relay-forward message into the relay-reply 411 message. 413 If the administrative policy on the DHCPv6 server permits to support 414 route aggregation on the relay agent for some particular prefix, the 415 status of prefix pool can be determined by the delegated prefixes 416 within the associated prefix pool. If there is at least one 417 delegated prefix within the pool that has a valid lease, the server 418 shall set the status of the associated prefix pool to be 'Active'. 419 After the last prefix releasing in the associated prefix pool, the 420 server shall set the status of the associated prefix pool to be 421 'Released'. If the administrative policy on the server does not 422 permit to support route aggregation on the DHCPv6 relay agent, the 423 server shall set the status of the prefix pools always to be 424 'Released'. 426 When the administrator of the server changes the setting to support 427 route aggregation on the relay agent for the particular prefix pool, 428 the status of the prefix pool MAY change from 'Released' to be 429 'Active' if at least one delegated prefix within the prefix pool has 430 the valid lease. When the administrator of the server changes the 431 setting not to support route aggregation on the relay agent for the 432 particular prefix pool, the status of the prefix pool MAY change from 433 'Active' to be 'Released' if at least one delegated prefix within the 434 prefix pool has the valid lease. Then the server MAY send a relay- 435 reply message of RECONFIGURE (10) to initiate immediately a Renew (5) 436 / Reply (7) PD message exchange with Prefix Pool option between one 437 active client and the server. 439 Multiple prefix pools MAY be associated with the same PE router 440 implementing a DHCPv6 relay agent (Figure 1) or its customer-facing 441 interface (Figure 2) in the binding table on the server. Note that 442 these prefix pools don't overlay, and the delegated customer prefix 443 is only from one prefix pool. 445 After receiving the LEASEQUERY (14) message from the relay agent with 446 the Query option (OPTION_LQ_QUERY, 44) including the Option Request 447 option (OPTION_ORO, 6) to request the Prefix Pool option 448 (OPTION_PREFIX_POOL, [TBD]), the server MUST include the Client Data 449 options (OPTION_CLIENT_DATA, 45) in the LEASEQUERY-REPLY (15) and 450 LEASEQUERY-DATA (17) message to convey the binding data of the 451 associated prefix pools with the 'Active' status through the 452 established TCP connection per [RFC5460]. Each Client Data option 453 shall contain a Prefix Pool option, and MAY contain the Interface ID 454 option (OPTION_INTERFACE_ID, 18). In order to be able to provide 455 meaningful replies to different query types, the server has to be 456 able to maintain the relevant association of prefix pools with the 457 RELAY_ID, link addresses or Remote_ID of the relay agent in its 458 binding database. 460 7. Security Considerations 462 Security issues related DHCPv6 are described in Section 23 of 463 [RFC3315] and Section 15 of [RFC3633]. 465 8. IANA Considerations 467 IANA is requested to assign an option code to Option_Prefix_Pool from 468 the "DHCPv6 and DHCPv6 options" registry 469 (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6- 470 parameters.xml). 472 9. Contributors List 474 Juergen Schoenwaelder 475 Jacobs University Bremen 476 Bremen 477 Germany 479 Email: j.schoenwaelder@jacobs-university.de 481 Jie Hu 482 China Telecom 483 Beijing, 484 P. R. China 486 Email: huj@ctbri.com.cn 488 Tina Tsou 489 Huawei Technologies 490 Santa Clara, CA 491 USA 493 Email: tina.tsou.zouting@huawei.com 495 10. Acknowledgements 497 Thanks to Ralph Droms for the inspiration from his expired draft 498 (RAAN option), to the DHC working group members, Bernie Volz, Ole 499 Troan and Roberta Maglione for the discussion in the mailing list, to 500 Christian Jacquenet for pointing out the draft shall cover one more 501 use case of ISP-Customer network where CPE is directly connected to 502 PE, to Sven Ooghe for some revisions in the email review, to 503 Shrinivas Ashok Joshi for pointing out the draft shall cover the 504 robust mechanism against the case of reboot, to Adrian Farrel for the 505 orientation guide on this draft in IETF80 at Prague. 507 11. References 509 11.1. Normative References 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 515 and M. Carney, "Dynamic Host Configuration Protocol for 516 IPv6 (DHCPv6)", RFC 3315, July 2003. 518 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 519 Host Configuration Protocol (DHCP) version 6", RFC 3633, 520 December 2003. 522 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 523 "DHCPv6 Leasequery", RFC 5007, September 2007. 525 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 526 February 2009. 528 11.2. Informative References 530 [BBF TR-177] 531 Broadband Forum, "IPv6 in the context of TR-101, Issue 1", 532 November 2010. 534 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 535 Delegation", RFC 3769, June 2004. 537 Authors' Addresses 539 Leaf Y. Yeh 540 Huawei Technologies 541 Shenzhen, 542 P. R. China 544 Email: leaf.y.yeh@huawei.com 546 Ted Lemon 547 Nominum, Inc 548 USA 550 Email: Ted.Lemon@nominum.com 552 Mohamed Boucadair 553 France Telecom 554 Rennes, 555 France 557 Email: mohamed.boucadair@orange.com