idnits 2.17.1 draft-ietf-dhc-problem-statement-of-mredhcpv6-05.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 (May 11, 2020) is 1445 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: November 12, 2020 Tsinghua University 6 May 11, 2020 8 DHCPv6 Extension Practices and Considerations 9 draft-ietf-dhc-problem-statement-of-mredhcpv6-05 11 Abstract 13 The manageability, security, privacy protection, and traceability of 14 networks can be supported by extending the DHCPv6 protocol according 15 to requirements. This document provides current extension practices 16 and typical DHCPv6 server softwares on extensions, defines a DHCPv6 17 general model, discusses some extension points, and presents 18 extension cases. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 12, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Current Extension Practices . . . . . . . . . . . . . . . . . 3 57 3.1. Standardized and Non-standardized DHCPv6 Extension Cases 3 58 3.2. Current DHCPv6 Server Software Cases . . . . . . . . . . 4 59 4. Extension Discussion . . . . . . . . . . . . . . . . . . . . 4 60 4.1. DHCPv6 General Model . . . . . . . . . . . . . . . . . . 4 61 4.2. Extension Points . . . . . . . . . . . . . . . . . . . . 5 62 4.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2.3. Message Processing Functions . . . . . . . . . . . . 6 65 4.2.4. Address Generation Mechanisms . . . . . . . . . . . . 6 66 5. Extension Cases . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 9.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 The IP address plays a significant role in the communication of the 78 Internet. IP address generation is also closely related to the 79 manageability, security, privacy protection, and traceability of 80 networks. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 81 [RFC8415] is a critical network protocol that can be used to 82 dynamically provide IPv6 addresses and other network configuration 83 parameters to IPv6 nodes. DHCPv6 continues to be extended and 84 improved through new options, protocols, and message processing 85 mechanisms. 87 Although DHCPv6 provides more and more comprehensive functionalities 88 and DHCPv6 server softwares also provide extension interfaces to 89 allow administrators to alter and customize the way how they handle 90 and respond to DHCPv6 messages, there is still a lack of 91 comprehensive insight into where and how to conduct extensions in 92 DHCPv6 effectively. The extensions to DHCPv6 can be various 93 according to multiple and varied requirements. The goal of multi- 94 requirement extensions for DHCPv6 is to use simple interfaces to 95 define and support more extensions without changing the basic design 96 of DHCPv6. Therefore, a detailed analysis is required to clarify the 97 problems, design principles, and extract and unify the design 98 specifications to help better solve the multi-requirement extension 99 problems. 101 In summary, multi-requirement extensions for DHCPv6 can be conducted 102 to support the administrator's self-defined functionalities. As 103 DHCPv6 is an essential and useful protocol related to IPv6 addresses 104 generation, it can provide more extended and flexible features to 105 meet administrators' requirements. According to well-designed 106 principles, extended interfaces can be defined to support more self- 107 defined multi-requirement extensions without sacrificing the 108 stability of DHCPv6. 110 Some people would suggest administrators modify the open-source 111 DHCPv6 servers to solve their problems. However, a considerable 112 amount of time will be taken to understand the open-source DHCPv6 113 server codes, not to say the consuming time debugging the bugs, 114 failures or system crash caused by modifying the complicated modules. 115 Another problem is that as the open-source software evolves, the 116 source codes of the server softwares may change (new functionalities 117 or fixing bugs). Users may need to re-write their codes once the 118 latest version of open-source server softwares come out 119 [kea_dhcp_hook_developers_guide]. Hence, the multi-requirement 120 extensions for DHCPv6 to solve administrators' specific problems are 121 essential and significant. 123 This document provides a survey of current extension practices and 124 typical DHCPv6 server softwares on extensions and gives DHCPv6 125 extension considerations by defining a DHCPv6 general model, 126 discussing the extension problems, and presenting extension cases. 128 2. Terminology 130 Familiarity with DHCPv6 and its terminology, as defined in [RFC8415], 131 is assumed. 133 3. Current Extension Practices 135 3.1. Standardized and Non-standardized DHCPv6 Extension Cases 137 Many documents attempt to extend DHCPv6. They can be classified into 138 three categories. 140 Extended options Most extensions for DHCPv6 are implemented in 141 this way. New-defined options carry specific 142 parameters in DHCPv6 messages, which helps DHCPv6 143 clients or servers know the detailed situation 144 with each other. 146 Extended messages Some documents define new protocols that aim to 147 achieve specific goals, e.g., active leasequery 148 [RFC7653], General Address Generation and 149 Management System [GAGMS]. 151 Extended entities Some documents introduce third-party entities 152 into the communications of DHCPv6 to achieve 153 specific goals and provide better services, e.g., 154 authentication [RFC7037]. 156 3.2. Current DHCPv6 Server Software Cases 158 A lot of commercial and open source DHCPv6 servers exist, including 159 Cisco Prime Network Registrar (CPNR) DHCP [CPNR], DHCP Broadband 160 [DHCP_Broadband], FreeRADIUS DHCP [FreeRADIUS_DHCP], ISC DHCP 161 [ISC_DHCP], Kea DHCP [Kea_DHCP], Microsoft DHCP [Microsoft_DHCP], 162 Nominum DHCP [Nominum_DHCP], VitalQIP [VitalQIP], and WIDE DHCPv6 163 [WIDE_DHCPv6]. Commercial and open-source DHCPv6 software often 164 considers the extensions of DHCPv6 servers because they cannot always 165 meet the requirements that the administrators want. For example, 166 CPNR DHCP server provides extension APIs and allows administrators to 167 write extensions and functions to alter and customize how it handles 168 and responds to DHCP requests. A network operator usually decides 169 what packet process to modify, how to modify, and which extension 170 point to attach the extension. Then the network operator writes the 171 extension and adds the well-written extension to the extension point 172 of the DHCP server. Finally, the network operator reloads the DHCP 173 server and debugs whether the server runs as it expects. Similarly, 174 Kea DHCP provides hook mechanisms, a well-designed interface for 175 third-party code, to solve the problem that the DHCP server does not 176 quite do what a network operator require. 178 4. Extension Discussion 180 This section elaborates multi-requirement extensions for DHCPv6. 181 Section 4.1 describes the general model of DHCPv6, while Section 4.2 182 analyzes the extension points and requirements. 184 4.1. DHCPv6 General Model 186 Figure 1 summarizes the DHCPv6 general model and its possible 187 extensions: messages, options, message processing functions, and 188 address generation mechanisms. 190 +-----------------+ +----------------+ 191 | DHCPv6 client | DHCPv6 messages | DHCPv6 relay | 192 | +-------------+ | with options | +------------+ | External inputs 193 | | Message | |<---------------->| | Message | |<---------------- 194 | | processing | | | | relaying | | e.g., RADIUS 195 | | functions | | | | functions | | option [RFC7037] 196 | +-------------+ | | +------------+ | 197 +-----------------+ +----------------+ 198 ^ 199 DHCPv6 messages | 200 with options | 201 | 202 V 203 +-----------------+ +----------------------------+ 204 | | Extended | DHCPv6 server | 205 | | messages | +-----------+ +----------+ | 206 |External entities|<------------->| | Address | | Message | | 207 | | e.g., Active | | generation| |processing| | 208 | | leasequery | | mechanisms| |functions | | 209 | | [RFC7653] | +-----------+ +----------+ | 210 +-----------------+ +----------------------------+ 212 Figure 1: DHCPv6 general model and its possible extensions. 214 4.2. Extension Points 216 4.2.1. Messages 218 On the one hand, new messages can be designed and added to the DHCPv6 219 protocol to enrich its functionalities. For example, [RFC5007] 220 defines new leasequery messages to allow a requestor to retrieve 221 information on the bindings for a client from one or more servers. 222 [RFC5460] expands on the Leasequery protocol by defines new messages 223 and allowing for bulk transfer of DHCPv6 binding data via TCP. 224 [RFC7653] defines active leasequery messages to keep the requestor up 225 to date with DHCPv6 bindings. [RFC8156] defines failover messages to 226 provide a mechanism for running two servers with the capability for 227 either server to take over clients' leases in case of server failure 228 or network partition. 230 On the other hand, people are concerned about the security and 231 privacy issues of the DHCPv6 protocol. [RFC7824] describes the 232 privacy issues associated with the use of DHCPv6, respectively. 233 DHCPv6 does not provide privacy protection on messages and options. 234 Other nodes can see the options transmitted in DHCPv6 messages 235 between DHCPv6 clients and servers. Extended messages can be 236 designed to secure exchanges between DHCPv6 entities. 238 4.2.2. Options 240 DHCPv6 allows defining options to transmit parameters between DHCPv6 241 entities for common requirements, e.g., DNS configurations [RFC3646], 242 NIS configurations [RFC3898], SNTP configurations [RFC4075], relay 243 agent subscriber-id [RFC4580], relay agent remote-id [RFC4649], FQDN 244 configurations [RFC4704], relay agent echo request [RFC4994], network 245 boot [RFC5970], Relay-Supplied Options [RFC6422], virtual subnet 246 selection [RFC6607], client link-layer address [RFC6939], and 247 softwire source binding prefix hint [RFC8539]. Also, these 248 parameters may come from external entities. For example, [RFC7037] 249 defines RADIUS option to exchange authorization and identification 250 information between the DHCPv6 relay agent and DHCPv6 server. 252 In other cases, network operators may require DHCPv6 messages to 253 transmit some self-defined options between clients and servers. 254 Currently, the vendor-specific information option allows clients and 255 servers to exchange vendor-specific information. Therefore, 256 administrative domains can define and use the sub-options of the 257 vendor-specific information option to serve their private purposes. 258 The content of the self-defined options may come from two sources: 259 devices and users. If the content of self-defined options comes from 260 users, two methods can be used to solve the problem. The first one 261 is that the clients provide related interfaces to receive such 262 information, which is currently merely supported. The second one is 263 that DHCPv6 relays obtain such information and add it to the clients' 264 requests. But this always depends on other protocols to allow DHCPv6 265 relays to get the information first. 267 4.2.3. Message Processing Functions 269 Although current commercial or open-source DHCPv6 server softwares 270 provide comprehensive functionalities, they still cannot meet all 271 customers' requirements of processing DHCPv6 requests. Therefore, 272 they will offer interfaces that customers can use to write their 273 specific extensions to affect the way how DHCPv6 servers handle and 274 respond to DHCP requests. For example, a network operator may want 275 his DHCPv6 server to communicate with external servers. Thus, he may 276 alter his DHCPv6 server through the given extensions to achieve such 277 a goal. However, not all DHCPv6 software considers this extension. 279 4.2.4. Address Generation Mechanisms 281 Currently, the DHCPv6 servers assign addresses, prefixes and other 282 configuration options according to their configured policies. 283 Generally, different networks may prefer different address generation 284 mechanisms. Several address generation mechanisms for SLAAC 285 [RFC4862] (e.g., IEEE 64-bit EUI-64 [RFC2464], Constant, semantically 286 opaque [Microsoft], Temporary [RFC4941], and Stable, semantically 287 opaque [RFC7217]) proposed for different requirements can be utilized 288 in DHCPv6 protocol as well. Note that [RFC7943] is the DHCPv6 289 version of Stable, semantically opaque [RFC7217]. The many types of 290 IPv6 address generation mechanisms available have brought about 291 flexibility and diversity. Therefore, corresponding interfaces could 292 be open and defined to allow other address generation mechanisms to 293 be configured. 295 5. Extension Cases 297 Administrative domains may enforce local policies according to their 298 requirements, e.g., authentication, accountability. Several kinds of 299 multi-requirement extensions are presented in this section, including 300 configurations in current DHCPv6 software, option definition and 301 server modification, and message definition between DHCPv6 entities 302 and third-party entities. 304 Currently, many DHCPv6 servers provide administrative mechanisms, 305 e.g., host reservation and client classification. Host reservation 306 is often used to assign certain parameters (e.g., IP addresses) to 307 specific devices. Client classification is often used to 308 differentiate between different types of clients and treat them 309 accordingly in certain cases. 311 More complicated extensions of DHCPv6 are needed to meet specific 312 requirements. For example, considering such a requirement that 313 DHCPv6 servers assign IPv6 addresses generated by user identifiers to 314 the clients in a network to hold users accountable, two extensions 315 should be fulfilled to meet this requirement. The first one is that 316 clients send their user identifiers to servers. This can be achieved 317 by defining and using sub-options of vendor-specific information 318 option. The second one is that servers use user identifiers to 319 generate IP addresses. To achieve this goal, extension mechanisms 320 provided by the server software such as extension points in CPNR 321 [CPNR] and hook mechanisms in Kea DHCP [Kea_DHCP] can be used. 323 Some extensions for DHCPv6 may need the support of third-party 324 entities. For example, [RFC7037] introduces RADIUS entities into the 325 message exchanges between DHCPv6 entities for better service 326 provision. The authentication in [RFC7037] can also be used to meet 327 the accountability requirement mentioned above because it is 328 important to authenticate users first before assigning IP addresses 329 generated from user identifiers. Usually, this kind of extension 330 requires the definition of messages communicated between DHCPv6 331 entities and third-party entities, e.g., active leasequery [RFC7653]. 333 IPv6 addresses are related to manageability, security, traceability, 334 and accountability of networks. As DHCPv6 assigns IPv6 addresses to 335 IPv6 nodes, it is important that DHCPv6 provides interfaces to allow 336 administrative domains to conduct extensions to meet their multi- 337 requirements. 339 6. Security Considerations 341 Security issues related with DHCPv6 are described in Section 22 of 342 [RFC8415]. 344 7. IANA Considerations 346 This document does not include an IANA request. 348 8. Acknowledgements 350 The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng 351 Jiang, and Jinmei Tatuya for their comments and suggestions that 352 improved the [draft-ren-dhc-mredhcpv6]. Some ideas and thoughts of 353 [draft-ren-dhc-mredhcpv6] are contained in this document. 355 9. References 357 9.1. Normative References 359 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 360 Address Autoconfiguration", RFC 4862, 361 DOI 10.17487/RFC4862, September 2007, 362 . 364 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 365 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 366 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 367 RFC 8415, DOI 10.17487/RFC8415, November 2018, 368 . 370 9.2. Informative References 372 [CPNR] Cisco, "Cisco Prime Network Registrar", 2018, 373 . 376 [DHCP_Broadband] 377 Weird Solutions, "DHCP Broadband", 2018, 378 . 381 [draft-ren-dhc-mredhcpv6] 382 Ren, G., He, L., and Y. Liu, "Multi-requirement Extensions 383 for Dynamic Host Configuration Protocol for IPv6 384 (DHCPv6)", March 2017. 386 [FreeRADIUS_DHCP] 387 FreeRADIUS, "FreeRADIUS DHCP", 2017, 388 . 390 [GAGMS] Liu, Y., He, L., and G. Ren, "GAGMS: A Requirement-Driven 391 General Address Generation and Management System", 392 November 2017. 394 [ISC_DHCP] 395 Internet System Consortium, "ISC DHCP", 2018, 396 . 398 [Kea_DHCP] 399 Internet System Consortium, "Kea DHCP", 2018, 400 . 402 [kea_dhcp_hook_developers_guide] 403 Internet Systems Consortium, "Hook Developer's Guide", 404 2018, . 407 [Microsoft] 408 Microsoft, "IPv6 interface identifiers", 2013, . 412 [Microsoft_DHCP] 413 Microsoft, "Microsoft DHCP", 2008, 414 . 417 [Nominum_DHCP] 418 Nominum, "Nominum DHCP", 2012, 419 . 423 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 424 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 425 . 427 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 428 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 429 DOI 10.17487/RFC3646, December 2003, 430 . 432 [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) 433 Configuration Options for Dynamic Host Configuration 434 Protocol for IPv6 (DHCPv6)", RFC 3898, 435 DOI 10.17487/RFC3898, October 2004, 436 . 438 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 439 Configuration Option for DHCPv6", RFC 4075, 440 DOI 10.17487/RFC4075, May 2005, 441 . 443 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 444 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, 445 DOI 10.17487/RFC4580, June 2006, 446 . 448 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 449 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 450 DOI 10.17487/RFC4649, August 2006, 451 . 453 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 454 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 455 Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, 456 . 458 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 459 Extensions for Stateless Address Autoconfiguration in 460 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 461 . 463 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 464 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 465 DOI 10.17487/RFC4994, September 2007, 466 . 468 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 469 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 470 September 2007, . 472 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 473 DOI 10.17487/RFC5460, February 2009, 474 . 476 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 477 Options for Network Boot", RFC 5970, DOI 10.17487/RFC5970, 478 September 2010, . 480 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 481 RFC 6422, DOI 10.17487/RFC6422, December 2011, 482 . 484 [RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet 485 Selection Options for DHCPv4 and DHCPv6", RFC 6607, 486 DOI 10.17487/RFC6607, April 2012, 487 . 489 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 490 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 491 May 2013, . 493 [RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 494 Relay Agent", RFC 7037, DOI 10.17487/RFC7037, October 495 2013, . 497 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 498 Interface Identifiers with IPv6 Stateless Address 499 Autoconfiguration (SLAAC)", RFC 7217, 500 DOI 10.17487/RFC7217, April 2014, 501 . 503 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 504 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 505 October 2015, . 507 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 508 Considerations for DHCPv6", RFC 7824, 509 DOI 10.17487/RFC7824, May 2016, 510 . 512 [RFC7943] Gont, F. and W. Liu, "A Method for Generating Semantically 513 Opaque Interface Identifiers (IIDs) with the Dynamic Host 514 Configuration Protocol for IPv6 (DHCPv6)", RFC 7943, 515 DOI 10.17487/RFC7943, September 2016, 516 . 518 [RFC8156] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Protocol", 519 RFC 8156, DOI 10.17487/RFC8156, June 2017, 520 . 522 [RFC8539] Farrer, I., Sun, Q., Cui, Y., and L. Sun, "Softwire 523 Provisioning Using DHCPv4 over DHCPv6", RFC 8539, 524 DOI 10.17487/RFC8539, March 2019, 525 . 527 [VitalQIP] 528 Nokia, "Nokia VitalQIP", 2017, 529 . 532 [WIDE_DHCPv6] 533 KAME project, "WIDE DHCPv6", 2008, 534 . 536 Authors' Addresses 538 Gang Ren 539 Tsinghua University 540 Beijing 100084 541 P.R.China 543 Phone: +86-010 6260 3227 544 Email: rengang@cernet.edu.cn 546 Lin He 547 Tsinghua University 548 Beijing 100084 549 P.R.China 551 Email: he-l14@mails.tsinghua.edu.cn 553 Ying Liu 554 Tsinghua University 555 Beijing 100084 556 P.R.China 558 Email: liuying@cernet.edu.cn