idnits 2.17.1 draft-ietf-dhc-dhcpv6-prefix-pool-opt-02.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 == 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). == 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: Multiple prefix pools MAY 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. -- The document date (February 10, 2013) is 4087 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-IANA' is mentioned on line 310, but not defined == Missing Reference: 'TBD' is mentioned on line 381, but not defined ** 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 (~~), 6 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: August 14, 2013 Nominum, Inc 6 M. Boucadair 7 France Telecom 8 February 10, 2013 10 Prefix Pool Option for DHCPv6 Relay Agent on the Provider Edge Routers 11 draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 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 August 14, 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 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 9. Contributors List . . . . . . . . . . . . . . . . . . . . . . 11 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 11.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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. The DHCPv6 servers always 83 maintain authoritative information associated with their operations 84 including, but not limited to, the binding data of the delegated IPv6 85 prefixes, the lease data of the delegated IPv6 prefixes, the status 86 of their prefix pools, etc. A prefix pool configured and maintained 87 on the server can usually be a short prefix (e.g., a /40 prefix), out 88 of which a longer prefixes (e.g., a /56 prefixes) are delegated to 89 customer networks. 91 In the scenarios 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 the 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 the 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. It will make the number of route 103 entries in the routing table on the ISP routers be unacceptable 104 large. Hence, it is desirable to aggregate the routes directing to 105 the 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. When the 111 PE router acts as the relay agent, it can not be aware about the 112 status of the prefix pools in general. The way to make the 113 aggregation routes (e.g., black-hole routes) pointing to each of the 114 prefix pools could be to configure them manually and permanently, but 115 it is meant to a large amount of the handwork on each PE router for 116 its operation and maintenance. 118 This document proposes a new Prefix Pool option for the DHCPv6 relay 119 agent implemented on PE routers, allowing the DHCPv6 server to notify 120 the DHCPv6 relay agent the information about the prefix pools. After 121 the PE router received the prefix pools, the aggregation route 122 entries can be added or withdrawn in the routing table of the PE 123 router according to the provision status of the prefix pools. The 124 aggregation routes will then be advertised into the ISP network 125 through the routing protocol enabled on the PE's network-facing 126 interface. 128 DHCPv6 Bulk Leasequery [RFC5460] specifies a mechanism for bulk 129 transfer of the binding data of each delegated prefix from the server 130 to the requestor, typically a relay agent, to support the replacement 131 or reboot event of a relay agent. In this document, the capability 132 of DHCPv6 Bulk Leasequery will be extended to support the bulk 133 transfer of the prefix and its status of the prefix pools for the 134 route aggregation. 136 The automatic mechanisms described in this document depend on the 137 existing DHCPv6 protocols and implementations without requiring a new 138 DHCPv6 message or a new interface for the configuration of the 139 aggregation route. The administrator of the ISP network can decide 140 whether to inject the aggregation route or not based on the policies 141 defined on the DHCPv6 server. 143 2. Terminology and Conventions 145 This document defines a new DHCPv6 option to communicate the prefix 146 and its status of an IPv6 prefix pool. Definitions for terms and 147 acronyms not specified in this document are defined in [RFC3315], 148 [RFC3633], [RFC5007] and [RFC5460]. 150 The following terms have been employed in this document: 152 o Requesting Router (RR): A router defined in [RFC3633] that acts as 153 a DHCPv6 client, and is requesting prefix 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 prefix pool of the delegated prefixes. 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:3450::/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:3450::/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:3456:7800:/56) 202 | 203 _________|_________ 204 / \ 205 | Customer Network | 206 \___________________/ 208 Figure 1: ISP-to-Customer network where CE is directly connected to 209 PE 211 +------+------+ 212 | DHCPv6 | DHCPv6 Server 213 | Server | (e.g. Binding entry 214 | | pe#3_cfi#4 - 2001:db8:1200::/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:1200::/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: ISP-to-Customer network where CE is connected to PE through 248 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 (TBA-IANA) 269 option-length: 2 + length of ipv6-prefix in Octets 270 status: Status of the prefix pool, indicating the 271 availability of the prefix pool maintained 272 on the server. 273 pfx-pool-len: Length for the prefix pool in Bits 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 server permits to support route 292 aggregation on the relay agent, the status of prefix pool can be 293 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 relay agent, the status of the prefix pool will 299 always be 'Released'. 301 Prefix Pool Option MAY be included by the DHCPv6 server in RELAY-REPL 302 (13), LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) message, and MAY 303 be included by the DHCPv6 relay agent in the RELAY-FORW (12). 305 5. Relay Agent Behavior 307 The DHCPv6 relay agent who needs the information of prefix pools, 308 SHOULD include the associated requested-option-code in Option Request 309 option (OPTION_ORO, 6) to request the Prefix Pool option 310 (OPTION_PREFIX_POOL, [TBD-IANA]) from the DHCPv6 server, who 311 maintains the status of the prefix pools associated with the relay 312 agent itself (Figure 1) or its particular customer-facing interface 313 (Figure 2), when receiving the DHCPv6-PD message from clients. The 314 relay agent SHOULD include this Option Request option for the Prefix 315 Pool option in the RELAY-FORW (12) message of SOLICIT (1), REQUEST 316 (3), RENEW(5), REBIND (6) and RELEASE (8). The relay agent MAY also 317 include the Prefix Pool option with the values of 'pfx-pool-len' and 318 'ip6-prefix' to indicate its preference for which prefix pool the 319 relay agent would like the server to return. 321 The relay agent SHOULD include the Interface ID option 322 (OPTION_INTERFACE_ID, 18) so that the server can identify the relay 323 agent itself or its particular customer-facing interface with which 324 the prefix pool is associated, if the server would not like to use 325 the link-address field specified in the encapsulation of the DHCPv6 326 RELAY-FORW message to identify the interface of the link on which the 327 clients are located. 329 The PE router acting as the relay agent MAY set up a table for the 330 lease or status of the prefix pools on it according to the leases of 331 the delegated customer prefixes within the prefix pools. The lease 332 of the prefix pool SHOULD dynamically set to be the maximum lease of 333 the delegated customer prefix within it. If there is no route entry 334 directing to the customer network within the aggregation route 335 associated with the prefix pool or the lease of prefix pool runs out, 336 the PE router acting as the relay agent SHOULD automatically withdraw 337 the aggregation route. 339 After receiving the Prefix Pool option for the relay agent itself or 340 its particular customer-facing interface in the RELAY-REPL (13) 341 message of REPLY (7) from the server, the PE router acting as the 342 relay agent SHOULD confirm the status of the prefix pool according to 343 the leases of delegated customer prefixes within it. If the status 344 of the prefix pool received and confirmed is 'Active', the PE router 345 acting as the relay agent SHOULD add an aggregation route entry in 346 its routing table, if the same entry has not been added before. If 347 the status of the prefix pool received is 'Released', the PE router 348 acting as the relay agent SHOULD withdraw the associated aggregation 349 route entry in its routing table, if the same entry has not been 350 withdrawn before. 352 The PE router acting as the relay agent advertises its routing table 353 including the entries of the aggregation routes based on the 354 information of prefix pools when the routing protocol is enabled on 355 its network-facing interface. 357 The PE router acting as the relay agent (i.e., Requestor) can use the 358 DHCPv6 Bulk Leasequery [RFC5460] to query the binding data of prefix 359 pools in the 'Active' status from the server. After established a 360 TCP connection with the server, the relay agent SHOULD include Query 361 option (OPTION_LQ_QUERY, 44) and set the proper query-type 362 (QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS or QUERY_BY_REMOTE_ID), 363 link-address and query-options in the LEASEQUERY (14) message. The 364 query options SHOULD include Option Request option to request the 365 Prefix Pool option from the server. 367 6. Server Behavior 369 According to DHCPv6-PD [RFC3633], if the prefix of the customer 370 network requested in RELAY-FORW (12) message of SOLICIT (1), REQUEST 371 (3), RENEW(5), REBIND (6) from the DHCPv6 client (i.e., the RR) has a 372 valid lease, the DHCPv6 server (i.e., the DR) will delegate the 373 prefix with the relevant parameters in the RELAY-REPL (13) message of 374 REPLY (7). In order to give a meaningful reply, the server has to 375 maintain the binding data of the delegated IPv6 prefixes with the 376 identification of the client. The Interface ID option 377 (OPTION_INTERFACE_ID, 18) nested in the RELAY-FORW message is usually 378 used to identify the access line of the client. 380 After receiving the Option Request option (OPTION_ORO, 6) requesting 381 the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the RELAY-FORW 382 messages of the DHCPv6-PD, the server SHOULD include the Prefix Pool 383 option with the status indicated for the associated relay agent 384 itself (Figure 1) or its customer-facing interface (Figure 2) in the 385 RELAY-REPL messages, if the RELAY-FORW messages received are valid. 387 The server MAY use the link-address specified in RELAY-FORW message 388 to identify the relay agent itself or its particular customer-facing 389 interface where the prefix pool is associated, but the server has to 390 maintain the binding data of prefix pools in association with these 391 link-addresses. To be more readable, the server can alternatively 392 use the Interface ID option included in the RELAY-FORW message by the 393 relay agent to identify the relay agent itself or its particular 394 customer-facing interface where the prefix pool is associated. In 395 order to give a meaningful reply, the server has to maintain the 396 binding data of prefix pools in association with the information 397 derived from the Interface ID option. According to DHCPv6 [RFC3315], 398 the server SHOULD copy the Interface ID option from the RELAY-FORW 399 message into the RELAY-REPL message. 401 If the administrative policy on the server permits to support route 402 aggregation on the relay agents for some particular prefix pool, the 403 status of prefix pool can be determined by the delegated prefixes 404 within the associated prefix pool. If there is at least one 405 delegated prefix within the pool that has a valid lease, the server 406 SHOULD set the status of the associated prefix pool to be 'Active'. 407 After the last prefix released in the associated prefix pool, the 408 server SHOULD set the status of the associated prefix pool to be 409 'Released'. If the administrative policy on the server does not 410 permit to support route aggregation on the relay agents, the server 411 shall set the status of the associated prefix pools always to be 412 'Released'. 414 When the administrator of the server changes the setting to support 415 route aggregation on the relay agent for the particular prefix pool, 416 the status of the prefix pool SHOULD change from 'Released' to be 417 'Active' if at least one delegated prefix within the prefix pool has 418 the valid lease. When the administrator of the server changes the 419 setting not to support route aggregation on the relay agent for the 420 particular prefix pool, the status of the prefix pool SHOULD change 421 from 'Active' to be 'Released' if at least one delegated prefix 422 within the prefix pool has the valid lease. The server MAY initiate 423 a RELAY-REPL message of RECONFIGURE (10) to immediately trigger RENEW 424 (5) / REPLY (7) prefix delegation message exchange with Prefix Pool 425 option between one active client and the server. 427 Multiple prefix pools MAY be associated with the same PE router 428 acting as the relay agent, or its customer-facing interface in the 429 binding table on the server. Note that these prefix pools SHOULD not 430 overlay, and the delegated customer prefix is only from one prefix 431 pool. 433 After receiving the LEASEQUERY (14) message from the relay agent with 434 the OPTION_LQ_QUERY (44) including the OPTION_ORO (6) to request the 435 Prefix Pool option, the server SHOULD include the OPTION_PREFIX_POOL 436 (TBD) in the LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) messages 437 to convey the binding data of the associated prefix pools through the 438 established TCP connection according to mechanism defined in the 439 DHCPv6 Bulk Leasequery [RFC5460]. Each LEASEQUERY-REPLY (15) and 440 LEASEQUERY-DATA (17) message MAY only contain one OPTION_PREFIX_POOL, 441 or and the associated OPTION_INTERFACE_ID, if the status of the 442 prefix pool is 'active'. In order to be able to provide meaningful 443 replies to different query types, the server has to maintain the 444 relevant association of prefix pools with the Relay_ID, link 445 addresses or Remote_IDs of the relay agent in its binding database. 447 7. Security Considerations 449 Security issues related DHCPv6 are described in Section 23 of 450 [RFC3315] and Section 15 of [RFC3633]. 452 8. IANA Considerations 454 This document requests to assign a new option code for 455 Option_Prefix_Pool in the registry of DHCPv6 Option Codes (http:// 456 www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml). 458 9. Contributors List 460 Juergen Schoenwaelder 461 Jacobs University Bremen 462 Bremen 463 Germany 465 Email: j.schoenwaelder@jacobs-university.de 467 Jie Hu 468 China Telecom 469 Beijing, 470 P. R. China 472 Email: huj@ctbri.com.cn 474 10. Acknowledgements 476 Thanks to Ralph Droms for the inspiration from his expired 477 [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04], to Tomek Mrugalski, Ole 478 Troan and Alexandru Petrescu for their discussion in the mailing list 479 of DHC, to Acee Lindem for his discussion in the mailing list of 480 routing-discussion, to Christian Jacquenet for pointing out the draft 481 shall cover one more use case of ISP-to-Customer network where CPE is 482 directly connected to PE, to Sven Ooghe for some revisions in the 483 email review, to Shrinivas Ashok Joshi for pointing out the draft 484 shall cover the mechanism against the case of reboot, to Adrian 485 Farrel for the orientation guide on this draft in IETF80 at Prague. 487 11. References 489 11.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 495 and M. Carney, "Dynamic Host Configuration Protocol for 496 IPv6 (DHCPv6)", RFC 3315, July 2003. 498 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 499 Host Configuration Protocol (DHCP) version 6", RFC 3633, 500 December 2003. 502 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 503 "DHCPv6 Leasequery", RFC 5007, September 2007. 505 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 506 February 2009. 508 11.2. Informative References 510 [BBF TR-177] 511 Broadband Forum, "IPv6 in the context of TR-101, Issue 1", 512 November 2010. 514 [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04] 515 Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent 516 Assignment Notification (RAAN) Option", July 2009. 518 Authors' Addresses 520 Leaf Y. Yeh 521 Freelancer Technologies 522 P. R. China 524 Email: leaf.yeh.sdo@gmail.com 526 Ted Lemon 527 Nominum, Inc 528 USA 530 Email: Ted.Lemon@nominum.com 531 Mohamed Boucadair 532 France Telecom 533 France 535 Email: mohamed.boucadair@orange.com