idnits 2.17.1 draft-ietf-dhc-problem-statement-of-mredhcpv6-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 12, 2020) is 1564 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: July 15, 2020 Tsinghua University 6 January 12, 2020 8 DHCPv6 Extension Survey and Considerations 9 draft-ietf-dhc-problem-statement-of-mredhcpv6-02 11 Abstract 13 The manageability, security, privacy protection, and traceability of 14 networks can be supported by extending DHCPv6 protocol according to 15 requirements. This document provides a survey of current extension 16 practices and typical DHCP server software on extensions, defines a 17 DHCPv6 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 July 15, 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 3.2.1. Cisco Prime Network Registrar DHCP Server Extension 60 APIs . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2.2. Kea DHCP Hook Mechanisms . . . . . . . . . . . . . . 4 62 4. Extension Points . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. DHCPv6 General Model . . . . . . . . . . . . . . . . . . 5 64 4.2. Extension Discussion . . . . . . . . . . . . . . . . . . 5 65 4.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2.3. Message Processing Functions . . . . . . . . . . . . 6 68 4.2.4. Address Generation Mechanisms . . . . . . . . . . . . 7 69 5. Extension Cases . . . . . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 The IP address plays a significant role in the communication of the 79 Internet. IP address generation is also closely related to the 80 manageability, security, privacy protection, and traceability of 81 networks. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 82 [RFC8415] is an important network protocol that can be used to 83 dynamically provide IPv6 addresses and other network configuration 84 parameters to IPv6 nodes. Actually, DHCPv6 continues to be extended 85 and improved through new options, protocols or message processing 86 mechanisms. 88 Although DHCPv6 provides more and more comprehensive functionalities 89 and DHCPv6 server software also provides extension interfaces to 90 allow administrators to alter and customize the way how they handle 91 and respond to DHCPv6 messages, there is still a lack of a general 92 insight into where and how to conduct extensions in DHCPv6 93 effectively. The extensions to DHCPv6 can be various according to 94 multiple requirements. The goal of multi-requirement extensions for 95 DHCPv6 is to use simple interfaces to define and support more 96 extensions without changing the basic design of DHCPv6. Therefore, a 97 detailed analysis is required to clarify the problems, design 98 principles, and extract and unify the design specifications to help 99 better solve the multi-requirement extension 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 important and useful protocol related to IPv6 addresses 104 generation, it can provide more extended and flexible functionalities 105 to 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 DHCP 111 servers to solve their problems. However, a great amount of time 112 will be taken to understand the open source DHCP server codes, not to 113 say the consuming time debugging the bugs, failures or system crash 114 caused by modifying the complicated modules. Another problem is that 115 as the open source software evolves, the source codes of the server 116 software may change (new functionalities or fixing bugs). Users may 117 need to re-write their codes once the new version of open-source 118 server software comes out [kea_dhcp_hook_developers_guide] . Hence, 119 the multi-requirement extensions for DHCPv6 to solve administrators' 120 specific problems are very necessary and significant. 122 This document provides a survey of current extension practices and 123 typical DHCP server software on extensions and gives DHCPv6 extension 124 considerations by defining a DHCPv6 general model, discussing the 125 extension problems, and presenting extension cases. 127 2. Terminology 129 Familiarity with DHCPv6 and its terminology, as defined in [RFC8415], 130 is assumed. 132 3. Current Extension Practices 134 3.1. Standardized and Non-standardized DHCPv6 Extension Cases 136 Many documents attempt to extend DHCPv6. They can be classified into 137 three categories. 139 Extended options Most extensions for DHCPv6 are implemented in 140 this way. Newly-defined options carry specific 141 parameters in DHCPv6 messages, which helps DHCPv6 142 clients or servers know the detailed situation 143 with each other. 145 Extended messages Some documents define new protocols that aim to 146 achieve specific goals, e.g., active leasequery 147 [RFC7653], GAGMS [GAGMS]. 149 Extended entities Some documents introduce third-party entities 150 into the communications of DHCPv6 to achieve 151 specific goals and provide better services, e.g., 152 authentication [RFC7037]. 154 3.2. Current DHCPv6 Server Software Cases 156 A lot of commercial and open source DHCP servers exist, including 157 Cisco Prime Network Registrar [CPNR], Microsoft DHCP 158 [Microsoft_DHCP], VitalQIP [VitalQIP], Nominum DHCP [Nominum_DHCP], 159 ISC DHCP [ISC_DHCP], Kea DHCP [Kea_DHCP], FreeRADIUS DHCP 160 [FreeRADIUS_DHCP], WIDE DHCPv6 [WIDE_DHCPv6], and DHCP Broadband 161 [DHCP_Broadband]. Commercial and open source DHCPv6 software often 162 considers the extensions of DHCPv6 servers because they cannot always 163 meet the requirements that the administrators want. In this section, 164 we introduce two typical DHCPv6 servers: Cisco Prime Network 165 Registrar and Kea DHCP. 167 3.2.1. Cisco Prime Network Registrar DHCP Server Extension APIs 169 Cisco Prime Network Registrar (CPNR) [CPNR] is an appliance which 170 provides integrated Domain Name Server, DHCP, and IP Address 171 Management services for IPv4 and IPv6. At the same time, CPNR DHCP 172 server provides extension APIs and allows administrators to write 173 extensions and functions to alter and customize how it handles and 174 responds to DHCP requests. A network operator usually decides what 175 packet process to modify, how to modify, and which extension point to 176 attach the extension. Then the network operator just writes the 177 extension and adds the well-written extension to the extension point 178 of the DHCP server. Finally, the network operator reloads the DHCP 179 server and debugs whether the server runs as it expects. 181 3.2.2. Kea DHCP Hook Mechanisms 183 Kea DHCP provides hook mechanisms, a well-designed interface for 184 third-party code, to solve the problem that the DHCP server does not 185 quite do what a network operator require. A network operator can use 186 several well-defined framework functions to load and initialize a 187 library and write specific callout functions to attach to the hook 188 points. After building and configuring the hooks library, the server 189 runs as the network operator requires. Additionally, Kea DHCP allows 190 the network operator to use logging in the hooks library. 192 4. Extension Points 194 This section elaborates multi-requirement extensions for DHCPv6. 195 Section 4.1 describes the general model of DHCPv6, while Section 4.2 196 analyzes the extension points and requirements. 198 4.1. DHCPv6 General Model 200 Figure 1 summarizes the DHCPv6 general model and its possible 201 extensions: messages, options, message processing functions, and 202 address generation mechanisms. 204 +-----------------+ +----------------+ 205 | DHCPv6 client | DHCP messages | DHCPv6 relay | 206 | +-------------+ | with options | +------------+ | External inputs 207 | | Message | |<----------------->| | Message | |<---------------- 208 | | processing | | | | relaying | | e.g., RADIUS 209 | | functions | | | | functions | | option [RFC7037] 210 | +-------------+ | | +------------+ | 211 +-----------------+ +----------------+ 212 ^ 213 DHCP messages | 214 with options | 215 | 216 V 217 +-----------------+ +----------------------------+ 218 | | Extended | DHCPv6 server | 219 | | messages | +-----------+ +----------+ | 220 |External entities|<------------->| | Address | | Message | | 221 | | e.g., Active | | generation| |processing| | 222 | | leasequery | | mechanisms| |functions | | 223 | | [RFC7653] | +-----------+ +----------+ | 224 +-----------------+ +----------------------------+ 226 Figure 1: DHCPv6 general model and its possible extensions. 228 4.2. Extension Discussion 230 4.2.1. Messages 232 On the one hand, new messages can be designed and added to DHCPv6 233 protocol to enrich its funtionalities. For example, [RFC5007] 234 defines new leasequery messages to allow a requestor to retrive 235 information on the bindings for a client from one or more servers. 236 [RFC7653] defines active leasequery messages to keep the requestor up 237 to date with DHCPv6 bindings. 239 On the other hand, people are concerned about the security and 240 privacy issues of DHCP protocol. [RFC7819] and [RFC7824] describe 241 the privacy issues associated with the use of DHCPv4 and DHCPv6, 242 respectively. DHCPv6 does not provide the privacy protection on 243 messages and options. Other nodes can see the options transmitted in 244 DHCPv6 messages between DHCPv6 clients and servers. Extended 245 messages can be designed to secure the exchanges between DHCPv6 246 entities. 248 4.2.2. Options 250 DHCPv6 allows defining options to transmit parameters between DHCPv6 251 entities for common requirements, e.g., DNS [RFC3646] and SNTP 252 [RFC4075]. Also, these parameters may come from external entities. 253 For example, [RFC7037] defines RADIUS option to exchange 254 authorization and identification information between the DHCPv6 relay 255 agent and DHCPv6 server. 257 In other cases, network operators may require DHCPv6 messages to 258 transmit some self-defined options between clients and servers. 259 Currently, vendor-specific information option allows clients and 260 servers to exchange vendor-specific information. Therefore, 261 administrative domains can define and use sub-options of vendor- 262 specific option to serve their private purposes. The content of the 263 self-defined options may come from two sources: devices and users. 264 If the content of self-defined options comes from users, two methods 265 can be used to solve the problem. The first one is that the clients 266 provide related interfaces to receive such information, which is 267 currently merely supported. The second one is that DHCPv6 relays 268 obtain such information and add it into the clients' requests. But 269 this always depends on other protocols to allow DHCPv6 relays to get 270 the information first. 272 4.2.3. Message Processing Functions 274 Although current commercial or open-source DHCP server software 275 provides comprehensive functionalities, they still cannot meet all 276 customers' requirements of processing DHCP requests. Therefore, they 277 will provide interfaces that customers can use to write their 278 specific extensions to affect the way how DHCP servers handle and 279 respond to DHCP requests. For example, not all networks prefer to 280 use DHCPv6 servers to assign the privacy-preserving random-form 281 addresses generated by some fixed address generation mechanism to 282 DHCPv6 clients. Thus, network operators may alter their DHCPv6 283 servers through the given extensions to use their own preferred 284 address generation mechanisms to assign addresses to DHCPv6 clients. 285 However, not all DHCP software considers this extension. 287 4.2.4. Address Generation Mechanisms 289 Currently, the DHCPv6 servers assign addresses, prefixes and other 290 configuration options according to their configured policies. 291 Generally, different networks may prefer different address generation 292 mechanisms. Several address generation mechanisms for SLAAC 293 [RFC4862] (e.g., IEEE 64-bit EUI-64 [RFC2464], Constant, semantically 294 opaque [Microsoft], Temporary [RFC4941], and Stable, semantically 295 opaque [RFC7217]) proposed for different requirements can be utilized 296 in DHCPv6 protocol as well. The many types of IPv6 address 297 generation mechanisms available have brought about flexibility and 298 diversity. Therefore, corresponding interfaces could be open and 299 defined to allow other address generation mechanisms to be 300 configured. 302 5. Extension Cases 304 Administrative domains may enforce local policies according to their 305 requirements, e.g., authentication, accountability. Several kinds of 306 multi-requirement extensions are presented in this section, including 307 configurations in current DHCP software, option definition and server 308 modification, and message definition between DHCPv6 entities and 309 third-party entities. 311 Currently, many DHCPv6 servers provide administrative mechanisms, 312 e.g., host reservation and client classification. Host reservation 313 is often used to assign certain parameters (e.g., IP addresses) to 314 specific devices. Client classification is often used to 315 differentiate between different types of clients and treat them 316 accordingly in certain cases. 318 To meet specific requirements, more complicated extensions of DHCPv6 319 are needed. For example, considering such a requirement that DHCP 320 servers assign IP addresses generated by user identifiers to the 321 clients in a network to hold users accountable, two extensions should 322 be fulfilled to meet this requirement. The first one is that clients 323 send their user identifiers to servers. This can be achieved by 324 defining and using sub-options of vendor specific information option. 325 The second one is that servers use user identifiers to generate IP 326 addresses. To achieve this goal, extension mechanisms provided by 327 the server software such as extension points in CPNR [CPNR] and hook 328 mechanisms in Kea DHCP [Kea_DHCP] can be used. 330 Some extensions for DHCPv6 may need the support of third-party 331 entities. For example, [RFC7037] introduces RADIUS entities into the 332 message exchanges between DHCPv6 entities for better service 333 provision. In fact, the authentication in [RFC7037] can be also used 334 to meet the accountability requirement mentioned above because it is 335 important to authenticate users first before assigning IP addresses 336 generated from user identifiers. Usually, this kind of extension 337 requires the definition of messages communicated between DHCP 338 entities and third-party entities, e.g., active leasequery [RFC7653]. 340 IPv6 addresses are related to manageability, security, traceability, 341 and accountability of networks. As DHCPv6 assigns IPv6 addresses to 342 IPv6 nodes, it is important that DHCPv6 provides interfaces to allow 343 administrative domains to conduct extensions to meet their multi- 344 requirements. 346 6. Security Considerations 348 Security issues related with DHCPv6 are described in Section 22 of 349 [RFC8415]. 351 7. IANA Considerations 353 This document does not include an IANA request. 355 8. Acknowledgements 357 The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng 358 Jiang, and Jinmei Tatuya for their comments and suggestions that 359 improved the [draft-ren-dhc-mredhcpv6]. Some ideas and thoughts of 360 [draft-ren-dhc-mredhcpv6] are contained in this document. 362 9. Normative References 364 [CPNR] Cisco, "Cisco Prime Network Registrar", 2018, 365 . 368 [DHCP_Broadband] 369 Weird Solutions, "DHCP Broadband", 2018, 370 . 373 [draft-ren-dhc-mredhcpv6] 374 Ren, G., He, L., and Y. Liu, "Multi-requirement Extensions 375 for Dynamic Host Configuration Protocol for IPv6 376 (DHCPv6)", March 2017. 378 [FreeRADIUS_DHCP] 379 FreeRADIUS, "FreeRADIUS DHCP", 2017, 380 . 382 [GAGMS] Liu, Y., He, L., and G. Ren, "GAGMS: A Requirement-Driven 383 General Address Generation and Management System", 384 November 2017. 386 [ISC_DHCP] 387 Internet System Consortium, "ISC DHCP", 2018, 388 . 390 [Kea_DHCP] 391 Internet System Consortium, "Kea DHCP", 2018, 392 . 394 [kea_dhcp_hook_developers_guide] 395 Internet Systems Consortium, "Hook Developer's Guide", 396 2018, . 399 [Microsoft] 400 Microsoft, "IPv6 interface identifiers", 2013, . 404 [Microsoft_DHCP] 405 Microsoft, "Microsoft DHCP", 2008, 406 . 409 [Nominum_DHCP] 410 Nominum, "Nominum DHCP", 2012, 411 . 415 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 416 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 417 . 419 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 420 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 421 DOI 10.17487/RFC3646, December 2003, 422 . 424 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 425 Configuration Option for DHCPv6", RFC 4075, 426 DOI 10.17487/RFC4075, May 2005, 427 . 429 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 430 Address Autoconfiguration", RFC 4862, 431 DOI 10.17487/RFC4862, September 2007, 432 . 434 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 435 Extensions for Stateless Address Autoconfiguration in 436 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 437 . 439 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 440 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 441 September 2007, . 443 [RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 444 Relay Agent", RFC 7037, DOI 10.17487/RFC7037, October 445 2013, . 447 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 448 Interface Identifiers with IPv6 Stateless Address 449 Autoconfiguration (SLAAC)", RFC 7217, 450 DOI 10.17487/RFC7217, April 2014, 451 . 453 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 454 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 455 October 2015, . 457 [RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy 458 Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, 459 April 2016, . 461 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 462 Considerations for DHCPv6", RFC 7824, 463 DOI 10.17487/RFC7824, May 2016, 464 . 466 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 467 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 468 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 469 RFC 8415, DOI 10.17487/RFC8415, November 2018, 470 . 472 [VitalQIP] 473 Nokia, "Nokia VitalQIP", 2017, 474 . 477 [WIDE_DHCPv6] 478 KAME project, "WIDE DHCPv6", 2008, 479 . 481 Authors' Addresses 483 Gang Ren 484 Tsinghua University 485 Beijing 100084 486 P.R.China 488 Phone: +86-010 6260 3227 489 Email: rengang@cernet.edu.cn 491 Lin He 492 Tsinghua University 493 Beijing 100084 494 P.R.China 496 Email: he-l14@mails.tsinghua.edu.cn 498 Ying Liu 499 Tsinghua University 500 Beijing 100084 501 P.R.China 503 Email: liuying@cernet.edu.cn