idnits 2.17.1 draft-ietf-dhc-problem-statement-of-mredhcpv6-06.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 date (November 15, 2020) is 1250 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration (DHC) G. Ren 3 Internet-Draft L. He 4 Intended status: Informational Y. Liu 5 Expires: May 19, 2021 Tsinghua University 6 November 15, 2020 8 DHCPv6 Extension Practices and Considerations 9 draft-ietf-dhc-problem-statement-of-mredhcpv6-06 11 Abstract 13 IP addresses as the communication identifier bear more and more 14 properties to meet different requirements. The privacy protection, 15 accountability, security, and manageability of networks can be 16 supported by extending the DHCPv6 protocol according to requirements. 17 This document provides current extension practices and typical DHCPv6 18 server softwares on extensions, defines a DHCPv6 general model, 19 discusses some extension points, and presents extension cases. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 19, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Current Extension Practices . . . . . . . . . . . . . . . . . 4 58 3.1. Standardized and Non-standardized DHCPv6 Extension Cases 4 59 3.2. Current DHCPv6 Server Software Cases . . . . . . . . . . 4 60 4. Extension Discussion . . . . . . . . . . . . . . . . . . . . 5 61 4.1. DHCPv6 General Model . . . . . . . . . . . . . . . . . . 5 62 4.2. Extension Points . . . . . . . . . . . . . . . . . . . . 5 63 4.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2.3. Message Processing Functions . . . . . . . . . . . . 6 66 4.2.4. Address Generation Mechanisms . . . . . . . . . . . . 7 67 4.3. Extension Principles . . . . . . . . . . . . . . . . . . 8 68 5. Extension Cases . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 9.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 The IP address plays a significant role in the communication on the 80 Internet. IP address generation is also closely related to the 81 privacy protection, accountability, security, and manageability of 82 networks. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 83 [RFC8415] is a critical network protocol that can be used to 84 dynamically provide IPv6 addresses and other network configuration 85 parameters to IPv6 nodes. DHCPv6 continues to be extended and 86 improved through new options, protocols, and message processing 87 mechanisms. 89 Although DHCPv6 provides more and more comprehensive functionalities 90 and DHCPv6 server softwares also provide extension interfaces to 91 allow administrators to alter and customize the way how they handle 92 and respond to DHCPv6 messages, there is still a lack of 93 comprehensive insight into where and how to conduct extensions in 94 DHCPv6 effectively. IP addresses as the communication identifier 95 bear more and more properties to meet different requirements. For 96 example, APNA [APNA] and PAVI [PAVI] use addresses to enhance source 97 accountability and privacy protection. As a result, the extensions 98 to DHCPv6 can be various according to multiple and varied 99 requirements, which is called multi-requirement extensions to DHCPv6. 100 However, it is difficult to extend the DHCPv6 to meet various 101 requirements now. Therefore, a detailed analysis is required to 102 clarify the problems, design principles, and extract and unify the 103 design specifications to help better solve the multi-requirement 104 extension problems. 106 In summary, multi-requirement extensions for DHCPv6 can be conducted 107 to support the administrator's self-defined functionalities or to 108 meet the requirements of applications. As DHCPv6 is an essential and 109 useful protocol related to IPv6 addresses generation, it can provide 110 more extended and flexible features to meet administrators' or 111 applications' requirements. According to well-designed principles, 112 extended interfaces can be defined to support more self-defined 113 multi-requirement extensions without sacrificing the stability of 114 DHCPv6. 116 Some people would suggest administrators modify the open-source 117 DHCPv6 servers to solve their problems. However, a considerable 118 amount of time will be taken to understand the open-source DHCPv6 119 server codes, not to say the consuming time debugging the bugs, 120 failures or system crash caused by modifying the complicated modules. 121 Another problem is that as the open-source software evolves, the 122 source codes of the server softwares may change (new functionalities 123 or fixing bugs). Users may need to re-write their codes once the 124 latest version of open-source server softwares come out 125 [kea_dhcp_hook_developers_guide]. Hence, the multi-requirement 126 extensions for DHCPv6 to solve administrators' specific problems are 127 essential and significant. 129 This document provides a survey of current extension practices and 130 typical DHCPv6 server softwares on extensions and gives DHCPv6 131 extension considerations by defining a DHCPv6 general model, 132 discussing the extension problems, and presenting extension cases. 134 2. Terminology 136 Familiarity with DHCPv6 and its terminology, as defined in [RFC8415], 137 is assumed. 139 Multi-requirement extensions: The extensions to DHCPv6 may cover 140 several aspects according to administrators' or applications' 141 requirements, e.g., privacy protection, accountability, and 142 security. These extensions can be conducted through the 143 definition of new messages, options, message processing functions, 144 or address generation mechanisms of DHCPv6. 146 3. Current Extension Practices 148 3.1. Standardized and Non-standardized DHCPv6 Extension Cases 150 Many documents attempt to extend DHCPv6. They can be classified into 151 three categories. 153 Extended options Most extensions for DHCPv6 are implemented in 154 this way. New-defined options carry specific 155 parameters in DHCPv6 messages, which helps DHCPv6 156 clients or servers know the detailed situation 157 with each other. 159 Extended messages Some documents define new protocols that aim to 160 achieve specific goals, e.g., active leasequery 161 [RFC7653], General Address Generation and 162 Management System [GAGMS]. 164 Extended entities Some documents introduce third-party entities 165 into the communications of DHCPv6 to achieve 166 specific goals and provide better services, e.g., 167 authentication [RFC7037]. 169 3.2. Current DHCPv6 Server Software Cases 171 A lot of commercial and open source DHCPv6 servers exist, including 172 Cisco Prime Network Registrar (CPNR) DHCP [CPNR], DHCP Broadband 173 [DHCP_Broadband], FreeRADIUS DHCP [FreeRADIUS_DHCP], ISC DHCP 174 [ISC_DHCP], Kea DHCP [Kea_DHCP], Microsoft DHCP [Microsoft_DHCP], 175 Nominum DHCP [Nominum_DHCP], VitalQIP [VitalQIP], and WIDE DHCPv6 176 [WIDE_DHCPv6]. Commercial and open-source DHCPv6 software often 177 considers the extensions of DHCPv6 servers because they cannot always 178 meet the requirements that the administrators want. For example, 179 CPNR DHCP server provides extension APIs and allows administrators to 180 write extensions and functions to alter and customize how it handles 181 and responds to DHCP requests. A network operator usually decides 182 what packet process to modify, how to modify, and which extension 183 point to attach the extension. Then the network operator writes the 184 extension and adds the well-written extension to the extension point 185 of the DHCP server. Finally, the network operator reloads the DHCP 186 server and debugs whether the server runs as it expects. Similarly, 187 Kea DHCP provides hook mechanisms, a well-designed interface for 188 third-party code, to solve the problem that the DHCP server does not 189 quite do what a network operator require. 191 4. Extension Discussion 193 This section elaborates multi-requirement extensions for DHCPv6. 194 Section 4.1 describes the general model of DHCPv6, while Section 4.2 195 analyzes the extension points and requirements. 197 4.1. DHCPv6 General Model 199 Figure 1 summarizes the DHCPv6 general model and its possible 200 extensions: messages, options, message processing functions, and 201 address generation mechanisms. 203 +-----------------+ +----------------+ 204 | DHCPv6 client | DHCPv6 messages | DHCPv6 relay | 205 | +-------------+ | with options | +------------+ | External inputs 206 | | Message | |<---------------->| | Message | |<---------------- 207 | | processing | | | | relaying | | e.g., RADIUS 208 | | functions | | | | functions | | option [RFC7037] 209 | +-------------+ | | +------------+ | 210 +-----------------+ +----------------+ 211 ^ 212 DHCPv6 messages | 213 with options | 214 | 215 V 216 +-----------------+ +----------------------------+ 217 | | Extended | DHCPv6 server | 218 | | messages | +-----------+ +----------+ | 219 |External entities|<------------->| | Address | | Message | | 220 | | e.g., Active | | generation| |processing| | 221 | | leasequery | | mechanisms| |functions | | 222 | | [RFC7653] | +-----------+ +----------+ | 223 +-----------------+ +----------------------------+ 225 Figure 1: DHCPv6 general model and its possible extensions. 227 4.2. Extension Points 229 4.2.1. Messages 231 On the one hand, new messages can be designed and added to the DHCPv6 232 protocol to enrich its functionalities. For example, [RFC5007] 233 defines new leasequery messages to allow a requestor to retrieve 234 information on the bindings for a client from one or more servers. 235 [RFC5460] expands on the Leasequery protocol by defines new messages 236 and allowing for bulk transfer of DHCPv6 binding data via TCP. 237 [RFC7653] defines active leasequery messages to keep the requestor up 238 to date with DHCPv6 bindings. [RFC8156] defines failover messages to 239 provide a mechanism for running two servers with the capability for 240 either server to take over clients' leases in case of server failure 241 or network partition. 243 On the other hand, people are concerned about the security and 244 privacy issues of the DHCPv6 protocol. [RFC7824] describes the 245 privacy issues associated with the use of DHCPv6, respectively. 246 DHCPv6 does not provide privacy protection on messages and options. 247 Other nodes can see the options transmitted in DHCPv6 messages 248 between DHCPv6 clients and servers. Extended messages can be 249 designed to secure exchanges between DHCPv6 entities. 251 4.2.2. Options 253 DHCPv6 allows defining options to transmit parameters between DHCPv6 254 entities for common requirements, e.g., DNS configurations [RFC3646], 255 NIS configurations [RFC3898], SNTP configurations [RFC4075], relay 256 agent subscriber-id [RFC4580], relay agent remote-id [RFC4649], FQDN 257 configurations [RFC4704], relay agent echo request [RFC4994], network 258 boot [RFC5970], Relay-Supplied Options [RFC6422], virtual subnet 259 selection [RFC6607], client link-layer address [RFC6939], and 260 softwire source binding prefix hint [RFC8539]. Also, these 261 parameters may come from external entities. For example, [RFC7037] 262 defines RADIUS option to exchange authorization and identification 263 information between the DHCPv6 relay agent and DHCPv6 server. 265 In other cases, network operators may require DHCPv6 messages to 266 transmit some self-defined options between clients and servers. 267 Currently, the vendor-specific information option allows clients and 268 servers to exchange vendor-specific information. Therefore, 269 administrative domains can define and use the sub-options of the 270 vendor-specific information option to serve their private purposes. 271 The content of the self-defined options may come from two sources: 272 devices and users. If the content of self-defined options comes from 273 users, two methods can be used to solve the problem. The first one 274 is that the clients provide related interfaces to receive such 275 information, which is currently merely supported. The second one is 276 that DHCPv6 relays obtain such information and add it to the clients' 277 requests. But this always depends on other protocols to allow DHCPv6 278 relays to get the information first. 280 4.2.3. Message Processing Functions 282 Although current commercial or open-source DHCPv6 server softwares 283 provide comprehensive functionalities, they still cannot meet all 284 customers' requirements of processing DHCPv6 requests. Therefore, 285 they will offer interfaces that customers can use to write their 286 specific extensions to affect the way how DHCPv6 servers handle and 287 respond to DHCP requests. For example, a network operator may want 288 his DHCPv6 server to communicate with external servers. Thus, he may 289 alter his DHCPv6 server through the given extensions to achieve such 290 a goal. However, not all DHCPv6 software considers this extension. 292 4.2.4. Address Generation Mechanisms 294 Currently, the DHCPv6 servers assign addresses, prefixes and other 295 configuration options according to their configured policies. 296 Generally, different networks may prefer different address generation 297 mechanisms. Several address generation mechanisms for SLAAC 298 [RFC4862] (e.g., IEEE 64-bit EUI-64 [RFC2464], Constant, semantically 299 opaque [Microsoft], Temporary [RFC4941], and Stable, semantically 300 opaque [RFC7217]) proposed for different requirements can be utilized 301 in DHCPv6 protocol as well. Note that [RFC7943] is the DHCPv6 302 version of Stable, semantically opaque [RFC7217]. The many types of 303 IPv6 address generation mechanisms available have brought about 304 flexibility and diversity. Therefore, corresponding interfaces could 305 be open and defined to allow other address generation mechanisms to 306 be configured. 308 Moreover, several basic operations are defined to support the design 309 of IPv6 addresses generation mechanisms. A new IPv6 address 310 generation mechanism can be made up of the combination of the 311 following basic operations. Also, new basic operations can be 312 defined to support new functions. 314 Invert(x, n) invert bit n of input x. 316 Insert(x, n, s) insert s after bit n of input x. 318 Concatenate(x, y, ...) concatenate input [x, y, ...] sequentially. 320 Replace(x, n, m, s) change from bit n to bit m of input x into s. 321 Note that the length of s must be equal to 322 m-n+1. When n=m, change only one bit of input 323 x. 325 Truncate(x, n, m) truncate from bit n to bit m of input x as the 326 output 328 Encrypt(x, k) use some specific encryption algorithm to 329 encrypt input x with key k. Encryption 330 algorithms can be IDEA, AES, RSA, etc. 332 Hash(x) calculate the hash digest value of input x. 333 Hash algorithms can be MD5, SHA1, SHA256, etc. 335 For example, temporary addresses in [RFC4941] can be expressed as 336 tempAddr(eui64, history) = Replace(Truncate(Hash(Concatenate(eui64, 337 history)), 0, 63), 6, 6, 0), where eui64 means the EUI-64 identifier 338 defined in [RFC2464] and history means a history value defined in 339 [RFC4941]. 341 4.3. Extension Principles 343 The principles used to conduct multi-requirement extensions for 344 DHCPv6 are summarized as follows: 346 1) Do not change the basic design of DHCPv6. 348 2) Use simpler interfaces to define and support more extensions. 350 5. Extension Cases 352 Administrative domains may enforce local policies according to their 353 requirements, e.g., authentication, accountability. Several kinds of 354 multi-requirement extensions are presented in this section, including 355 configurations in current DHCPv6 software, option definition and 356 server modification, and message definition between DHCPv6 entities 357 and third-party entities. 359 Currently, many DHCPv6 servers provide administrative mechanisms, 360 e.g., host reservation and client classification. Host reservation 361 is often used to assign certain parameters (e.g., IP addresses) to 362 specific devices. Client classification is often used to 363 differentiate between different types of clients and treat them 364 accordingly in certain cases. 366 More complicated extensions of DHCPv6 are needed to meet specific 367 requirements. For example, considering such a requirement that 368 DHCPv6 servers assign IPv6 addresses generated by user identifiers to 369 the clients in a network to hold users accountable, two extensions 370 should be fulfilled to meet this requirement. The first one is that 371 clients send their user identifiers to servers. This can be achieved 372 by defining and using sub-options of vendor-specific information 373 option. The second one is that servers use user identifiers to 374 generate IP addresses. To achieve this goal, extension mechanisms 375 provided by the server software such as extension points in CPNR 376 [CPNR] and hook mechanisms in Kea DHCP [Kea_DHCP] can be used. 378 Some extensions for DHCPv6 may need the support of third-party 379 entities. For example, [RFC7037] introduces RADIUS entities into the 380 message exchanges between DHCPv6 entities for better service 381 provision. The authentication in [RFC7037] can also be used to meet 382 the accountability requirement mentioned above because it is 383 important to authenticate users first before assigning IP addresses 384 generated from user identifiers. Usually, this kind of extension 385 requires the definition of messages communicated between DHCPv6 386 entities and third-party entities, e.g., active leasequery [RFC7653]. 388 IPv6 addresses are related to manageability, security, traceability, 389 and accountability of networks. As DHCPv6 assigns IPv6 addresses to 390 IPv6 nodes, it is important that DHCPv6 provides interfaces to allow 391 administrative domains to conduct extensions to meet their multi- 392 requirements. 394 6. Security Considerations 396 Security issues related with DHCPv6 are described in Section 22 of 397 [RFC8415]. 399 7. IANA Considerations 401 This document does not include an IANA request. 403 8. Acknowledgements 405 The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng 406 Jiang, and Jinmei Tatuya for their comments and suggestions that 407 improved the [draft-ren-dhc-mredhcpv6]. Some ideas and thoughts of 408 [draft-ren-dhc-mredhcpv6] are contained in this document. 410 9. References 412 9.1. Normative References 414 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 415 Address Autoconfiguration", RFC 4862, 416 DOI 10.17487/RFC4862, September 2007, 417 . 419 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 420 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 421 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 422 RFC 8415, DOI 10.17487/RFC8415, November 2018, 423 . 425 9.2. Informative References 427 [APNA] Lee, T., Pappas, C., Barrera, D., Szalachowski, P., and A. 428 Perrig, "Source Accountability with Domain-brokered 429 Privacy", December 2016. 431 [CPNR] Cisco, "Cisco Prime Network Registrar", 2018, 432 . 435 [DHCP_Broadband] 436 Weird Solutions, "DHCP Broadband", 2018, 437 . 440 [draft-ren-dhc-mredhcpv6] 441 Ren, G., He, L., and Y. Liu, "Multi-requirement Extensions 442 for Dynamic Host Configuration Protocol for IPv6 443 (DHCPv6)", March 2017. 445 [FreeRADIUS_DHCP] 446 FreeRADIUS, "FreeRADIUS DHCP", 2017, 447 . 449 [GAGMS] Liu, Y., He, L., and G. Ren, "GAGMS: A Requirement-Driven 450 General Address Generation and Management System", 451 November 2017. 453 [ISC_DHCP] 454 Internet System Consortium, "ISC DHCP", 2018, 455 . 457 [Kea_DHCP] 458 Internet System Consortium, "Kea DHCP", 2018, 459 . 461 [kea_dhcp_hook_developers_guide] 462 Internet Systems Consortium, "Hook Developer's Guide", 463 2018, . 466 [Microsoft] 467 Microsoft, "IPv6 interface identifiers", 2013, . 471 [Microsoft_DHCP] 472 Microsoft, "Microsoft DHCP", 2008, 473 . 476 [Nominum_DHCP] 477 Nominum, "Nominum DHCP", 2012, 478 . 482 [PAVI] He, L., Ren, G., and Y. Liu, "Bootstrapping Accountability 483 and Privacy to IPv6 Internet without Starting from 484 Scratch", December 2019. 486 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 487 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 488 . 490 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 491 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 492 DOI 10.17487/RFC3646, December 2003, 493 . 495 [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) 496 Configuration Options for Dynamic Host Configuration 497 Protocol for IPv6 (DHCPv6)", RFC 3898, 498 DOI 10.17487/RFC3898, October 2004, 499 . 501 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 502 Configuration Option for DHCPv6", RFC 4075, 503 DOI 10.17487/RFC4075, May 2005, 504 . 506 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 507 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, 508 DOI 10.17487/RFC4580, June 2006, 509 . 511 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 512 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 513 DOI 10.17487/RFC4649, August 2006, 514 . 516 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 517 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 518 Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, 519 . 521 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 522 Extensions for Stateless Address Autoconfiguration in 523 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 524 . 526 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 527 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 528 DOI 10.17487/RFC4994, September 2007, 529 . 531 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 532 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 533 September 2007, . 535 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 536 DOI 10.17487/RFC5460, February 2009, 537 . 539 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 540 Options for Network Boot", RFC 5970, DOI 10.17487/RFC5970, 541 September 2010, . 543 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 544 RFC 6422, DOI 10.17487/RFC6422, December 2011, 545 . 547 [RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet 548 Selection Options for DHCPv4 and DHCPv6", RFC 6607, 549 DOI 10.17487/RFC6607, April 2012, 550 . 552 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 553 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 554 May 2013, . 556 [RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 557 Relay Agent", RFC 7037, DOI 10.17487/RFC7037, October 558 2013, . 560 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 561 Interface Identifiers with IPv6 Stateless Address 562 Autoconfiguration (SLAAC)", RFC 7217, 563 DOI 10.17487/RFC7217, April 2014, 564 . 566 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 567 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 568 October 2015, . 570 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 571 Considerations for DHCPv6", RFC 7824, 572 DOI 10.17487/RFC7824, May 2016, 573 . 575 [RFC7943] Gont, F. and W. Liu, "A Method for Generating Semantically 576 Opaque Interface Identifiers (IIDs) with the Dynamic Host 577 Configuration Protocol for IPv6 (DHCPv6)", RFC 7943, 578 DOI 10.17487/RFC7943, September 2016, 579 . 581 [RFC8156] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Protocol", 582 RFC 8156, DOI 10.17487/RFC8156, June 2017, 583 . 585 [RFC8539] Farrer, I., Sun, Q., Cui, Y., and L. Sun, "Softwire 586 Provisioning Using DHCPv4 over DHCPv6", RFC 8539, 587 DOI 10.17487/RFC8539, March 2019, 588 . 590 [VitalQIP] 591 Nokia, "Nokia VitalQIP", 2017, 592 . 595 [WIDE_DHCPv6] 596 KAME project, "WIDE DHCPv6", 2008, 597 . 599 Authors' Addresses 601 Gang Ren 602 Tsinghua University 603 Beijing 100084 604 P.R.China 606 Phone: +86-010 6260 3227 607 Email: rengang@cernet.edu.cn 609 Lin He 610 Tsinghua University 611 Beijing 100084 612 P.R.China 614 Email: he-l14@mails.tsinghua.edu.cn 615 Ying Liu 616 Tsinghua University 617 Beijing 100084 618 P.R.China 620 Email: liuying@cernet.edu.cn