idnits 2.17.1 draft-rhl-dhc-dhcpv6-extensions-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 date (20 December 2021) is 856 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.jia-intarea-scenarios-problems-addressing' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'I-D.lhan-problems-requirements-satellite-net' is defined on line 489, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-jia-intarea-scenarios-problems-addressing-02 == Outdated reference: A later version (-06) exists of draft-lhan-problems-requirements-satellite-net-01 -- No information found for draft-ren-dhc-mredhcpv6 - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration (DHC) G.R. Ren 3 Internet-Draft L.H. He 4 Intended status: Informational Y.L. Liu 5 Expires: 23 June 2022 Tsinghua University 6 20 December 2021 8 DHCPv6 Extension Practices and Considerations 9 draft-rhl-dhc-dhcpv6-extensions-00 11 Abstract 13 IP addresses assume an increasing number of attributes as 14 communication identifiers to meet different requirements. Privacy 15 protection, accountability, security, and manageability of networks 16 can be supported by extending the DHCPv6 protocol as required. This 17 document provides current extension practices and typical DHCPv6 18 server software in terms of extensions, defines a general model of 19 DHCPv6, discusses some extension points, and presents extension 20 cases. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 23 June 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Current Extension Practices . . . . . . . . . . . . . . . . . 4 58 3.1. Standardized and Non-standardized DHCPv6 Extension 59 Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Current DHCPv6 Server Software Cases . . . . . . . . . . 4 61 4. Extension Discussion . . . . . . . . . . . . . . . . . . . . 5 62 4.1. DHCPv6 General Model . . . . . . . . . . . . . . . . . . 5 63 4.2. Extension Points . . . . . . . . . . . . . . . . . . . . 6 64 4.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2.3. Message Processing Functions . . . . . . . . . . . . 7 67 4.2.4. Address Generation Mechanisms . . . . . . . . . . . . 7 68 4.3. Extension Principles . . . . . . . . . . . . . . . . . . 8 69 5. Extension Cases . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Software Configurations . . . . . . . . . . . . . . . . . 9 71 5.2. Option Definition and Server Modification . . . . . . . . 9 72 5.3. Message Definition . . . . . . . . . . . . . . . . . . . 9 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 9.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 IP addresses play an essential role in communication over the 84 Internet. Their generation and assignment are also closely linked to 85 the privacy protection, accountability, security, and manageability 86 of the network [I-D.gont-v6ops-ipv6-addressing-considerations]. The 87 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC8415] is an 88 important network protocol that can be used to dynamically provide 89 IPv6 addresses and other network configuration parameters to IPv6 90 nodes. DHCPv6 can be continuously extended and improved through new 91 options, protocols, and message processing mechanisms. 93 IP addresses assume an increasing number of properties as 94 communication identifiers to meet different requirements. For 95 example, APNA [APNA] and PAVI [PAVI] use addresses to enhance source 96 responsibility and privacy protection. These requirements often need 97 to be reflected by IP address assignment protocols such as DHCPv6. 98 Therefore, extensions to DHCPv6 are made to meet a wide variety of 99 requirements, which is referred to as multi-requirement extensions to 100 DHCPv6. However, it is not easy to extend DHCPv6 to meet a variety 101 of requirements. Although DHCPv6 offers increasingly comprehensive 102 functionality and DHCPv6 server software provides extension 103 interfaces that allow administrators to change and customize the way 104 they process and respond to DHCPv6 messages, there is still a lack of 105 comprehensive understanding of where and how to extend in DHCPv6 106 effectively. Therefore, a detailed analysis is needed to clarify the 107 issues and design principles and extract and unify design 108 specifications to help better address the multi-demand scaling 109 problem. 111 In summary, with the large-scale deployment and application of IPv6, 112 new scenarios such as Data Center Network, Internet of Things, 113 Industrial Internet, and Integrated satellite-terrestrial networks 114 put forward new requirements for IP address allocation, e.g., the 115 scale of address allocation, the efficiency of address update and 116 synchronization, the address generation algorithms (such as 117 association with location, identifier, and other information), and 118 the scope of dynamic address configuration service relay and 119 collaboration. At the same time, it also puts forward new 120 requirements in network security, accountability, manageability, and 121 privacy protection. These are what we call "multiple requirements". 122 Multi-requirement extensions for DHCPv6 is to meet new scenarios and 123 new requirements through the expansion of new messages, options, 124 message processing functions, or address generation mechanisms for 125 DHCPv6. Based on careful design principles, interfaces can be 126 defined to support more customized multi-requirement extensions 127 without sacrificing the stability of DHCPv6. 129 Some people would suggest that administrators modify the open-source 130 DHCPv6 server to solve their problems. However, it takes 131 considerable time to understand the code of an open-source DHCPv6 132 server, not to mention the time-consuming task of debugging errors, 133 failures, or system crashes caused by modifying complex modules. 134 Another problem is that as open-source software evolves, the source 135 code of the server software may change (new features or bug fixes). 136 Once the latest version of the open-source server software comes out 137 [kea_dhcp_hook_developers_guide], users may need to rewrite their 138 code. Therefore, the multi-requirement extensions to DHCPv6 to 139 address the specific issues of administrators are essential and 140 significant. 142 This document provides a survey of current extension practices and 143 typical DHCPv6 server softwares on extensions and gives DHCPv6 144 extension considerations by defining a DHCPv6 general model, 145 discussing the extension problems, and presenting extension cases. 147 2. Terminology 149 Familiarity with DHCPv6 and its terminology, as defined in [RFC8415], 150 is assumed. 152 Multi-requirement extensions: The multi-requirement extensions for 153 DHCPv6 is to meet new scenarios and requirements by extending 154 DHCPv6 with new messages, options, message processing features, or 155 address generation mechanisms. 157 3. Current Extension Practices 159 3.1. Standardized and Non-standardized DHCPv6 Extension Cases 161 Many documents attempt to extend DHCPv6. They can be classified into 162 three categories. 164 Extended options Most extensions for DHCPv6 are implemented in 165 this way. New-defined options carry specific 166 parameters in DHCPv6 messages, which helps DHCPv6 167 clients or servers know the detailed situation 168 with each other. 170 Extended messages Some documents define new protocols that aim to 171 achieve specific goals, e.g., active leasequery 172 [RFC7653], General Address Generation and 173 Management System [GAGMS]. 175 Extended entities Some documents introduce third-party entities 176 into the communications of DHCPv6 to achieve 177 specific goals and provide better services, e.g., 178 authentication [RFC7037]. 180 3.2. Current DHCPv6 Server Software Cases 182 A lot of commercial and open source DHCPv6 servers exist, including 183 Cisco Prime Network Registrar (CPNR) DHCP [CPNR], DHCP Broadband 184 [DHCP_Broadband], FreeRADIUS DHCP [FreeRADIUS_DHCP], ISC DHCP 185 [ISC_DHCP], Kea DHCP [Kea_DHCP], Microsoft DHCP [Microsoft_DHCP], 186 Nominum DHCP [Nominum_DHCP], VitalQIP [VitalQIP], and WIDE DHCPv6 187 [WIDE_DHCPv6]. Commercial and open-source DHCPv6 software often 188 considers the extensions of DHCPv6 servers because they cannot always 189 meet the requirements that the administrators want. For example, 190 CPNR DHCP server provides extension APIs and allows administrators to 191 write extensions and functions to alter and customize how it handles 192 and responds to DHCP requests. A network operator usually decides 193 what packet process to modify, how to modify, and which extension 194 point to attach the extension. Then the network operator writes the 195 extension and adds the well-written extension to the extension point 196 of the DHCP server. Finally, the network operator reloads the DHCP 197 server and debugs whether the server runs as it expects. Similarly, 198 Kea DHCP provides hook mechanisms, a well-designed interface for 199 third-party code, to solve the problem that the DHCP server does not 200 quite do what a network operator require. 202 4. Extension Discussion 204 This section elaborates multi-requirement extensions for DHCPv6. 205 Section 4.1 describes the general model of DHCPv6, while Section 4.2 206 analyzes the extension points and requirements. 208 4.1. DHCPv6 General Model 210 Figure 1 summarizes the DHCPv6 general model and its possible 211 extensions: messages, options, message processing functions, and 212 address generation mechanisms. 214 +-----------------+ +----------------+ 215 | DHCPv6 client | DHCPv6 messages | DHCPv6 relay | 216 | +-------------+ | with options | +------------+ | External inputs 217 | | Message | |<---------------->| | Message | |<---------------- 218 | | processing | | | | relaying | | e.g., RADIUS 219 | | functions | | | | functions | | option [RFC7037] 220 | +-------------+ | | +------------+ | 221 +-----------------+ +----------------+ 222 ^ 223 DHCPv6 messages | 224 with options | 225 | 226 V 227 +-----------------+ +----------------------------+ 228 | | Extended | DHCPv6 server | 229 | | messages | +-----------+ +----------+ | 230 |External entities|<------------->| | Address | | Message | | 231 | | e.g., Active | | generation| |processing| | 232 | | leasequery | | mechanisms| |functions | | 233 | | [RFC7653] | +-----------+ +----------+ | 234 +-----------------+ +----------------------------+ 236 Figure 1: DHCPv6 general model and its possible extensions. 238 4.2. Extension Points 240 4.2.1. Messages 242 On the one hand, new messages can be designed and added to the DHCPv6 243 protocol to enrich its functionalities. For example, [RFC5007] 244 defines new leasequery messages to allow a requestor to retrieve 245 information on the bindings for a client from one or more servers. 246 [RFC5460] expands on the Leasequery protocol by defines new messages 247 and allowing for bulk transfer of DHCPv6 binding data via TCP. 248 [RFC7653] defines active leasequery messages to keep the requestor up 249 to date with DHCPv6 bindings. [RFC8156] defines failover messages to 250 provide a mechanism for running two servers with the capability for 251 either server to take over clients' leases in case of server failure 252 or network partition. 254 On the other hand, people are concerned about the security and 255 privacy issues of the DHCPv6 protocol. [RFC7824] describes the 256 privacy issues associated with the use of DHCPv6, respectively. 257 DHCPv6 does not provide privacy protection on messages and options. 258 Other nodes can see the options transmitted in DHCPv6 messages 259 between DHCPv6 clients and servers. Extended messages can be 260 designed to secure exchanges between DHCPv6 entities. 262 4.2.2. Options 264 DHCPv6 allows defining options to transmit parameters between DHCPv6 265 entities for common requirements, e.g., DNS configurations [RFC3646], 266 NIS configurations [RFC3898], SNTP configurations [RFC4075], relay 267 agent subscriber-id [RFC4580], relay agent remote-id [RFC4649], FQDN 268 configurations [RFC4704], relay agent echo request [RFC4994], network 269 boot [RFC5970], Relay-Supplied Options [RFC6422], virtual subnet 270 selection [RFC6607], client link-layer address [RFC6939], and 271 softwire source binding prefix hint [RFC8539]. Also, these 272 parameters may come from external entities. For example, [RFC7037] 273 defines RADIUS option to exchange authorization and identification 274 information between the DHCPv6 relay agent and DHCPv6 server. 276 In other cases, network operators may require DHCPv6 messages to 277 transmit some self-defined options between clients and servers. 278 Currently, the vendor-specific information option allows clients and 279 servers to exchange vendor-specific information. Therefore, 280 administrative domains can define and use the sub-options of the 281 vendor-specific information option to serve their private purposes. 282 The content of the self-defined options may come from two sources: 283 devices and users. If the content of self-defined options comes from 284 users, two methods can be used to solve the problem. The first one 285 is that the clients provide related interfaces to receive such 286 information, which is currently merely supported. The second one is 287 that DHCPv6 relays obtain such information and add it to the clients' 288 requests. But this always depends on other protocols to allow DHCPv6 289 relays to get the information first. 291 4.2.3. Message Processing Functions 293 Although current commercial or open-source DHCPv6 server softwares 294 provide comprehensive functionalities, they still cannot meet all 295 customers' requirements of processing DHCPv6 requests. Therefore, 296 they will offer interfaces that customers can use to write their 297 specific extensions to affect the way how DHCPv6 servers handle and 298 respond to DHCP requests. For example, a network operator may want 299 his DHCPv6 server to communicate with external servers. Thus, he may 300 alter his DHCPv6 server through the given extensions to achieve such 301 a goal. However, not all DHCPv6 software considers this extension. 303 4.2.4. Address Generation Mechanisms 305 Currently, the DHCPv6 servers assign addresses, prefixes and other 306 configuration options according to their configured policies. 307 Generally, different networks may prefer different address generation 308 mechanisms. Several address generation mechanisms for SLAAC 309 [RFC4862] (e.g., IEEE 64-bit EUI-64 [RFC2464], Constant, semantically 310 opaque [Microsoft], Temporary [RFC4941], and Stable, semantically 311 opaque [RFC7217]) proposed for different requirements can be utilized 312 in DHCPv6 protocol as well. Note that [RFC7943] is the DHCPv6 313 version of Stable, semantically opaque [RFC7217]. The many types of 314 IPv6 address generation mechanisms available have brought about 315 flexibility and diversity. Therefore, corresponding interfaces could 316 be open and defined to allow other address generation mechanisms to 317 be configured. 319 Moreover, several basic operations are defined to support the design 320 of IPv6 addresses generation mechanisms. A new IPv6 address 321 generation mechanism can be made up of the combination of the 322 following basic operations. Also, new basic operations can be 323 defined to support new functions. 325 Invert(x, n) invert bit n of input x. 327 Insert(x, n, s) insert s after bit n of input x. 329 Concatenate(x, y, ...) concatenate input [x, y, ...] sequentially. 331 Replace(x, n, m, s) change from bit n to bit m of input x into s. 333 Note that the length of s must be equal to 334 m-n+1. When n=m, change only one bit of input 335 x. 337 Truncate(x, n, m) truncate from bit n to bit m of input x as the 338 output 340 Encrypt(x, k) use some specific encryption algorithm to 341 encrypt input x with key k. Encryption 342 algorithms can be IDEA, AES, RSA, etc. 344 Hash(x) calculate the hash digest value of input x. 345 Hash algorithms can be MD5, SHA1, SHA256, etc. 347 For example, temporary addresses in [RFC4941] can be expressed as 348 tempAddr(eui64, history) = Replace(Truncate(Hash(Concatenate(eui64, 349 history)), 0, 63), 6, 6, 0), where eui64 means the EUI-64 identifier 350 defined in [RFC2464] and history means a history value defined in 351 [RFC4941]. 353 4.3. Extension Principles 355 The principles used to conduct multi-requirement extensions for 356 DHCPv6 are summarized as follows: 358 1) Do not change the basic design of DHCPv6. 360 2) Use simpler interfaces to define and support more extensions. 362 5. Extension Cases 364 Administrative domains may enforce local policies according to their 365 requirements, e.g., authentication, accountability. Several kinds of 366 multi-requirement extensions are presented in this section, including 367 configurations in current DHCPv6 software, option definition and 368 server modification, and message definition between DHCPv6 entities 369 and third-party entities. IPv6 addresses are related to 370 manageability, security, traceability, and accountability of 371 networks. As DHCPv6 assigns IPv6 addresses to IPv6 nodes, it is 372 important that DHCPv6 provides interfaces to allow administrative 373 domains to conduct extensions to meet their multi-requirements. 375 5.1. Software Configurations 377 Currently, many DHCPv6 servers provide administrative mechanisms, 378 e.g., host reservation and client classification. Host reservation 379 is often used to assign certain parameters (e.g., IP addresses) to 380 specific devices. For example, a client with special access rights 381 (e.g., a firewall rule that allows access based on the source's IP 382 address) needs to keep its address allowed in the firewall 383 configuration. Another use case is a device with a mission-critical 384 network service that needs access by IP address in case a DNS lookup 385 fails. Client classification is often used to differentiate between 386 different types of clients and treat them accordingly in certain 387 cases. This classification allows DHCP addresses or options to be 388 assigned based on specific device characteristics or some network 389 identifier. Grouping devices by client class makes it more 390 convenient to perform bulk configuration settings. A typical example 391 is the network access security policy. For example, a client class 392 can be configured so that devices in that class are assigned IP 393 addresses in subnets that are restricted to the public Internet due 394 to security policies applied to the subnet/network on the router or 395 firewall. 397 5.2. Option Definition and Server Modification 399 More complicated extensions of DHCPv6 are needed to meet specific 400 requirements. For example, considering such a requirement that 401 DHCPv6 servers assign IPv6 addresses generated by user identifiers to 402 the clients in a network to hold users accountable, two extensions 403 should be fulfilled to meet this requirement. The first one is that 404 clients send their user identifiers to servers. This can be achieved 405 by defining and using sub-options of vendor-specific information 406 option. The second one is that servers use user identifiers to 407 generate IP addresses. To achieve this goal, extension mechanisms 408 provided by the server software such as extension points in CPNR 409 [CPNR] and hook mechanisms in Kea DHCP [Kea_DHCP] can be used. 411 5.3. Message Definition 413 Some extensions for DHCPv6 may need the support of third-party 414 entities. For example, [RFC7037] introduces RADIUS entities into the 415 message exchanges between DHCPv6 entities for better service 416 provision. The authentication in [RFC7037] can also be used to meet 417 the accountability requirement mentioned above because it is 418 important to authenticate users first before assigning IP addresses 419 generated from user identifiers. Usually, this kind of extension 420 requires the definition of messages communicated between DHCPv6 421 entities and third-party entities, e.g., active leasequery [RFC7653]. 423 6. Security Considerations 425 Security issues related with DHCPv6 are described in Section 22 of 426 [RFC8415]. 428 7. IANA Considerations 430 This document does not include an IANA request. 432 8. Acknowledgements 434 The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng 435 Jiang, and Jinmei Tatuya for their comments and suggestions that 436 improved the [I-D.ren-dhc-mredhcpv6]. Some ideas and thoughts of 437 [I-D.ren-dhc-mredhcpv6] are contained in this document. 439 9. References 441 9.1. Normative References 443 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 444 Address Autoconfiguration", RFC 4862, 445 DOI 10.17487/RFC4862, September 2007, 446 . 448 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 449 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 450 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 451 RFC 8415, DOI 10.17487/RFC8415, November 2018, 452 . 454 9.2. Informative References 456 [APNA] Lee, T.L., Pappas, C.P., Barrera, D.B., Szalachowski, 457 P.S., and A.P. Perrig, "Source Accountability with Domain- 458 brokered Privacy", December 2016. 460 [CPNR] Cisco, "Cisco Prime Network Registrar", 2018, 461 . 464 [DHCP_Broadband] 465 Weird Solutions, "DHCP Broadband", 2018, 466 . 469 [FreeRADIUS_DHCP] 470 FreeRADIUS, "FreeRADIUS DHCP", 2017, 471 . 473 [GAGMS] Liu, Y.L., He, L.H., and G.R. Ren, "GAGMS: A Requirement- 474 Driven General Address Generation and Management System", 475 November 2017. 477 [I-D.gont-v6ops-ipv6-addressing-considerations] 478 Gont, F.G. and G.G. Gont, "IPv6 Addressing 479 Considerations", February 2021. 481 [I-D.jia-intarea-scenarios-problems-addressing] 482 Jia, Y., Trossen, D., Iannone, L., Shenoy, N., Mendes, P., 483 and P. Liu, "Challenging Scenarios and Problems in 484 Internet Addressing", Work in Progress, Internet-Draft, 485 draft-jia-intarea-scenarios-problems-addressing-02, 23 486 October 2021, . 489 [I-D.lhan-problems-requirements-satellite-net] 490 Han, L. and R. Li, "Problems and Requirements of Satellite 491 Constellation for Internet", Work in Progress, Internet- 492 Draft, draft-lhan-problems-requirements-satellite-net-01, 493 19 October 2021, . 496 [I-D.ren-dhc-mredhcpv6] 497 Ren, G.R., He, L.H., and Y.L. Liu, "Multi-requirement 498 Extensions for Dynamic Host Configuration Protocol for 499 IPv6 (DHCPv6)", March 2017. 501 [ISC_DHCP] Internet System Consortium, "ISC DHCP", 2018, 502 . 504 [Kea_DHCP] Internet System Consortium, "Kea DHCP", 2018, 505 . 507 [kea_dhcp_hook_developers_guide] 508 Internet Systems Consortium, "Hook Developer's Guide", 509 2018, . 512 [Microsoft] 513 Microsoft, "IPv6 interface identifiers", 2013, . 517 [Microsoft_DHCP] 518 Microsoft, "Microsoft DHCP", 2008, 519 . 522 [Nominum_DHCP] 523 Nominum, "Nominum DHCP", 2012, 524 . 528 [PAVI] He, L.H., Ren, G.R., Liu, Y.L., and J.Y. Yang, "PAVI: 529 Bootstrapping Accountability and Privacy to IPv6 530 Internet", April 2021. 532 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 533 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 534 . 536 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 537 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 538 DOI 10.17487/RFC3646, December 2003, 539 . 541 [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) 542 Configuration Options for Dynamic Host Configuration 543 Protocol for IPv6 (DHCPv6)", RFC 3898, 544 DOI 10.17487/RFC3898, October 2004, 545 . 547 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 548 Configuration Option for DHCPv6", RFC 4075, 549 DOI 10.17487/RFC4075, May 2005, 550 . 552 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 553 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, 554 DOI 10.17487/RFC4580, June 2006, 555 . 557 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 558 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 559 DOI 10.17487/RFC4649, August 2006, 560 . 562 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 563 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 564 Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, 565 . 567 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 568 Extensions for Stateless Address Autoconfiguration in 569 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 570 . 572 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 573 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 574 DOI 10.17487/RFC4994, September 2007, 575 . 577 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 578 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 579 September 2007, . 581 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 582 DOI 10.17487/RFC5460, February 2009, 583 . 585 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 586 Options for Network Boot", RFC 5970, DOI 10.17487/RFC5970, 587 September 2010, . 589 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 590 RFC 6422, DOI 10.17487/RFC6422, December 2011, 591 . 593 [RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet 594 Selection Options for DHCPv4 and DHCPv6", RFC 6607, 595 DOI 10.17487/RFC6607, April 2012, 596 . 598 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 599 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 600 May 2013, . 602 [RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 603 Relay Agent", RFC 7037, DOI 10.17487/RFC7037, October 604 2013, . 606 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 607 Interface Identifiers with IPv6 Stateless Address 608 Autoconfiguration (SLAAC)", RFC 7217, 609 DOI 10.17487/RFC7217, April 2014, 610 . 612 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 613 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 614 October 2015, . 616 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 617 Considerations for DHCPv6", RFC 7824, 618 DOI 10.17487/RFC7824, May 2016, 619 . 621 [RFC7943] Gont, F. and W. Liu, "A Method for Generating Semantically 622 Opaque Interface Identifiers (IIDs) with the Dynamic Host 623 Configuration Protocol for IPv6 (DHCPv6)", RFC 7943, 624 DOI 10.17487/RFC7943, September 2016, 625 . 627 [RFC8156] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Protocol", 628 RFC 8156, DOI 10.17487/RFC8156, June 2017, 629 . 631 [RFC8539] Farrer, I., Sun, Q., Cui, Y., and L. Sun, "Softwire 632 Provisioning Using DHCPv4 over DHCPv6", RFC 8539, 633 DOI 10.17487/RFC8539, March 2019, 634 . 636 [VitalQIP] Nokia, "Nokia VitalQIP", 2017, 637 . 640 [WIDE_DHCPv6] 641 KAME project, "WIDE DHCPv6", 2008, 642 . 644 Authors' Addresses 646 Gang Ren 647 Tsinghua University 648 Beijing 650 Phone: +86-010 6260 3227 651 Email: rengang@cernet.edu.cn 652 Lin He 653 Tsinghua University 654 Beijing 656 Email: he-lin@tsinghua.edu.cn 658 Ying Liu 659 Tsinghua University 660 Beijing 662 Email: liuying@cernet.edu.cn