idnits 2.17.1 draft-ietf-dhc-dhcpv6-prefix-pool-opt-01.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 (October 19, 2012) is 4206 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 378, 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 (~~), 4 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 Huawei Technologies 4 Intended status: Standards Track T. Lemon 5 Expires: April 22, 2013 Nominum, Inc 6 M. Boucadair 7 France Telecom 8 October 19, 2012 10 Prefix Pool Option for DHCPv6 Relay Agents on Provider Edge Routers 11 draft-ietf-dhc-dhcpv6-prefix-pool-opt-01 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 April 22, 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 . . . . . . . . . . . . . . . . . . . . . . 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. DHCPv6 servers always maintain 83 authoritative information associated with 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. It 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. When the 111 PE router acts as the relay agent, it in general can not be aware 112 about the status of the prefix pools. One way to make the 113 aggregation routes (e.g., black-hole routes) pointing to each of the 114 prefix pools is to configure them manually and permanently, but it is 115 meant to a large amount of the handwork on each PE router for its 116 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 about the prefix of pools. After the PE 121 router received information about the prefix pools, the aggregation 122 route entries can be added or withdrawn in the routing table of the 123 PE 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 route 134 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: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 (TBA-IANA) 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 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 MUST 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 MAY 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-forward message to identify the interface of the link on which 327 the clients are located. 329 The relay agent MAY set up a table for the lease or status of the 330 prefix pool on it according to the leases of the delegated customer 331 prefixes within it. The lease of the prefix pools MUST dynamically 332 set to be the maximum lease of the delegated customer prefixes. If 333 there is no route entry directing to the customer network within the 334 aggregation route associated with the prefix pool or the lease of 335 prefix pool runs out, the relay agent Should automatically withdraw 336 the aggregation route. 338 After receiving the Prefix Pool option for the relay agent itself or 339 its particular customer-facing interface in the RELAY-REPL (13) 340 message of REPLY (7) from the server, the relay agent acting as the 341 PE router Should confirm the status of the prefix pool according to 342 the leases of delegated customer prefixes within it. If the status 343 of the prefix pool received and confirmed is 'Active', the relay 344 agent Should add an aggregation route entry in its routing table, if 345 the same entry has not been added before. If the status of the 346 prefix pool received is 'Released', the relay agent Should withdraw 347 the associated aggregation route entry in its routing table, if the 348 same entry has not been withdrawn before. 350 The relay agent advertises its routing table including the entries of 351 the aggregation routes based on the information of prefix pools when 352 the routing protocol is enabled on its network-facing interface. 354 The Relay Agent (i.e., Requestor) can use the DHCPv6 Bulk Leasequery 355 [RFC5460] to query the binding data of prefix pools in the 'Active' 356 status from the server. After established a TCP connection with the 357 server, the relay agent MUST include Query option (OPTION_LQ_QUERY, 358 44) and set the proper query-type (QUERY_BY_RELAY_ID, 359 QUERY_BY_LINK_ADDRESS or QUERY_BY_REMOTE_ID), link-address and query- 360 options in the LEASEQUERY (14) message. The query options MUST 361 include Option Request option (OPTION_ORO, 6) to request the Prefix 362 Pool option (OPTION_PREFIX_POOL, [TBD]) from the server. 364 6. Server Behavior 366 According to DHCPv6-PD [RFC3633], if the prefix of the customer 367 network requested in RELAY-FORW (12) message of SOLICIT, REQUEST, 368 RENEW, REBIND from the DHCPv6 client (i.e., the RR) has a valid 369 lease, the DHCPv6 server (i.e., the DR) will delegate the prefix with 370 the relevant parameters in the RELAY-REPL (13) message of REPLY. In 371 order to give a meaningful reply, the server has to maintain the 372 binding data of the delegated IPv6 prefixes with the identification 373 of the client. The Interface ID option (OPTION_INTERFACE_ID, 18) 374 nested in the relay-forward message is usually used to identify the 375 access line of the client. 377 After receiving the Option Request option (OPTION_ORO, 6) requesting 378 the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay- 379 forward messages of the DHCPv6-PD, the server MUST include the Prefix 380 Pool option with the status indicated for the associated relay agent 381 itself (Figure 1) or its customer-facing interface (Figure 2) in the 382 relay-reply messages if the relay-forward messages received are 383 valid. 385 The server MAY use the link-address specified in relay-forward 386 message to identify the relay agent itself or its particular 387 customer-facing interface where the prefix pool is associated, but 388 the server has to maintain the binding data of prefix pools in 389 association with these link-addresses. To be more readable, the 390 server can alternatively use the Interface ID option included in the 391 relay-forward message by the relay agent to identify the relay agent 392 itself or its particular customer-facing interface where the prefix 393 pool is associated. In order to give a meaningful reply, the server 394 has to maintain the binding data of prefix pools in association with 395 the information derived from the Interface ID option. According to 396 DHCPv6 [RFC3315], the server MUST copy the Interface ID option from 397 the relay-forward message into the relay-reply message. 399 If the administrative policy on the server permits to support route 400 aggregation on the relay agent for some particular prefix pool, the 401 status of prefix pool can be determined by the delegated prefixes 402 within the associated prefix pool. If there is at least one 403 delegated prefix within the pool that has a valid lease, the server 404 Should set the status of the associated prefix pool to be 'Active'. 405 After the last prefix released in the associated prefix pool, the 406 server Should set the status of the associated prefix pool to be 407 'Released'. If the administrative policy on the server does not 408 permit to support route aggregation on the relay agent, the server 409 shall set the status of the prefix pools always to be 'Released'. 411 When the administrator of the server changes the setting to support 412 route aggregation on the relay agent for the particular prefix pool, 413 the status of the prefix pool MAY change from 'Released' to be 414 'Active' if at least one delegated prefix within the prefix pool has 415 the valid lease. When the administrator of the server changes the 416 setting not to support route aggregation on the relay agent for the 417 particular prefix pool, the status of the prefix pool MAY change from 418 'Active' to be 'Released' if at least one delegated prefix within the 419 prefix pool has the valid lease. Then the server MAY send a relay- 420 reply message of RECONFIGURE (10) to initiate immediately a Renew (5) 421 / Reply (7) prefix delegation message exchange with Prefix Pool 422 option between one active client and the server. 424 Multiple prefix pools MAY be associated with the same PE router 425 implementing the relay agent, or its customer-facing interface in the 426 binding table on the server. Note that these prefix pools Should not 427 overlay, and the delegated customer prefix is only from one prefix 428 pool. 430 After receiving the LEASEQUERY (14) message from the relay agent with 431 the OPTION_LQ_QUERY (44) including the OPTION_ORO (6) to request the 432 OPTION_PREFIX_POOL (TBD), the server MUST include the Prefix Pool 433 option in the LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) messages 434 to convey the binding data of the associated prefix pools through the 435 established TCP connection according to mechanism defined in the 436 DHCPv6 Bulk Leasequery [RFC5460]. Each LEASEQUERY-REPLY (15) and 437 LEASEQUERY-DATA (17) message only contains one OPTION_PREFIX_POOL or 438 and the associated OPTION_INTERFACE_ID (18) if the status of the 439 prefix pool is 'active'. In order to be able to provide meaningful 440 replies to different query types, the server has to maintain the 441 relevant association of prefix pools with the RELAY_ID, link 442 addresses or Remote_ID of the relay agent in its binding database. 444 7. Security Considerations 446 Security issues related DHCPv6 are described in Section 23 of 447 [RFC3315] and Section 15 of [RFC3633]. 449 8. IANA Considerations 451 IANA is requested to assign an option code to Option_Prefix_Pool from 452 the DHCPv6 registry (http://www.iana.org/assignments/ 453 dhcpv6-parameters/dhcpv6-parameters.xml). 455 9. Contributors List 457 Juergen Schoenwaelder 458 Jacobs University Bremen 459 Bremen 460 Germany 462 Email: j.schoenwaelder@jacobs-university.de 464 Jie Hu 465 China Telecom 466 Beijing, 467 P. R. China 469 Email: huj@ctbri.com.cn 471 Tina Tsou 472 Huawei Technologies 473 Santa Clara, CA 474 USA 476 Email: tina.tsou.zouting@huawei.com 478 10. Acknowledgements 480 Thanks to Ralph Droms for the inspiration from his expired 481 [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04], to the DHC working group 482 members, Bernie Volz, Ole Troan and Roberta Maglione for the 483 discussion in the mailing list, to Christian Jacquenet for pointing 484 out the draft shall cover one more use case of ISP-Customer network 485 where CPE is directly connected to PE, to Sven Ooghe for some 486 revisions in the email review, to Shrinivas Ashok Joshi for pointing 487 out the draft shall cover the mechanism against the case of reboot, 488 to Adrian Farrel for the orientation guide on this draft in IETF80 at 489 Prague. 491 11. References 493 11.1. Normative References 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, March 1997. 498 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 499 and M. Carney, "Dynamic Host Configuration Protocol for 500 IPv6 (DHCPv6)", RFC 3315, July 2003. 502 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 503 Host Configuration Protocol (DHCP) version 6", RFC 3633, 504 December 2003. 506 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 507 "DHCPv6 Leasequery", RFC 5007, September 2007. 509 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 510 February 2009. 512 11.2. Informative References 514 [BBF TR-177] 515 Broadband Forum, "IPv6 in the context of TR-101, Issue 1", 516 November 2010. 518 [I-D.ietf-dhc-dhcpv6-agentopt-delegate-04] 519 Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent 520 Assignment Notification (RAAN) Option", July 2009. 522 Authors' Addresses 524 Leaf Y. Yeh 525 Huawei Technologies 526 Shenzhen, 527 P. R. China 529 Email: leaf.y.yeh@huawei.com 530 Ted Lemon 531 Nominum, Inc 532 USA 534 Email: Ted.Lemon@nominum.com 536 Mohamed Boucadair 537 France Telecom 538 Rennes, 539 France 541 Email: mohamed.boucadair@orange.com