idnits 2.17.1 draft-ietf-dhc-problem-statement-of-mredhcpv6-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 (May 23, 2019) is 1799 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 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: November 24, 2019 Tsinghua University 6 May 23, 2019 8 Problem Statement of Multi-requirement Extensions for Dynamic Host 9 Configuration Protocol for IPv6 (DHCPv6) 10 draft-ietf-dhc-problem-statement-of-mredhcpv6-00 12 Abstract 14 The manageability, security, privacy protection, and traceability of 15 networks can be supported by extending DHCPv6 protocol according to 16 requirements. This document analyzes current extension practices and 17 typical DHCP server software on extensions, defines a DHCP general 18 model, discusses some extension points, and present 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 24, 2019. 37 Copyright Notice 39 Copyright (c) 2019 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. DHCP General Model . . . . . . . . . . . . . . . . . . . 5 64 4.2. Extension Discussion . . . . . . . . . . . . . . . . . . 5 65 4.2.1. DHCP Messages . . . . . . . . . . . . . . . . . . . . 5 66 4.2.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2.3. Message Processing Functions . . . . . . . . . . . . 6 68 4.2.4. Address Generation Mechanisms . . . . . . . . . . . . 6 69 4.2.5. Extension Principles . . . . . . . . . . . . . . . . 7 70 5. Extension Cases . . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The IP address plays a significant role in the communication of the 80 Internet. IP address generation is also closely related to the 81 manageability, security, privacy protection, and traceability of 82 networks. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 83 [RFC8415] is an important network protocol that can be used to 84 dynamically provide IPv6 addresses and other network configuration 85 parameters to IPv6 nodes. Actually, DHCPv6 continues to be extended 86 and improved through new options, protocols or message processing 87 mechanisms. 89 Although DHCPv6 provides more and more comprehensive functionalities 90 and DHCPv6 server software also provides 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 a general 93 insight into where and how to conduct extensions in DHCPv6 94 effectively. The extensions to DHCPv6 can be various according to 95 multiple requirements. Therefore, a detailed analysis is required to 96 clarify the problems, design principles, and extract and unify the 97 design specifications to help better solve the multi-requirement 98 extension problems. 100 In summary, multi-requirement extensions for DHCPv6 can be conducted 101 to support the administrator's self-defined functionalities. As 102 DHCPv6 is an important and useful protocol related to IPv6 addresses 103 generation, it can provide more extended and flexible functionalities 104 to meet administrators' requirements. According to well-designed 105 principles, extended interfaces can be defined to support more self- 106 defined multi-requirement extensions without sacrificing the 107 stability of DHCPv6. 109 Some people would suggest administrators modify the open-source DHCP 110 servers to solve their problems. However, a great amount of time 111 will be taken to understand the open source DHCP server codes, not to 112 say the consuming time debugging the bugs, failures or system crash 113 caused by modifying the complicated modules. Another problem is that 114 as the open source software evolves, the source codes of the server 115 software may change (new functionalities or fixing bugs). Users may 116 need to re-write their codes once the new version of open-source 117 server software comes out [kea_dhcp_hook_developers_guide] . Hence, 118 the multi-requirement extensions for DHCPv6 to solve administrators' 119 specific problems are very necessary and significant. 121 This document describes current extension practices and typical DHCP 122 server software on extensions and provides a problem statement by 123 defining a DHCP general model, discussing the extension problems, and 124 presenting extension cases. 126 2. Terminology 128 Familiarity with DHCPv6 and its terminology, as defined in [RFC8415], 129 is assumed. 131 3. Current Extension Practices 133 3.1. Standardized and Non-standardized DHCPv6 Extension Cases 135 Many documents attempt to extend DHCPv6. They can be classified into 136 three categories. 138 Extended options Most extensions for DHCPv6 are implemented in 139 this way. New-defined options carry specific 140 parameters in DHCPv6 messages, which helps DHCPv6 141 clients or servers know the detailed situation 142 with each other. 144 Extended messages Some documents define new protocols that aim to 145 achieve specific goals, e.g., active leasequery 146 [RFC7653], GAGMS [GAGMS]. 148 Extended entities Some documents introduce third-party entities 149 into the communications of DHCPv6 to achieve 150 specific goals and provide better services, e.g., 151 authentication [RFC7037]. 153 3.2. Current DHCPv6 Server Software Cases 155 A lot of commercial and open source DHCP servers exist, including 156 Cisco Prime Network Registrar [CPNR], Microsoft DHCP 157 [Microsoft_DHCP], VitalQIP [VitalQIP], Nominum DHCP [Nominum_DHCP], 158 ISC DHCP [ISC_DHCP], Kea DHCP [Kea_DHCP], FreeRADIUS DHCP 159 [FreeRADIUS_DHCP], WIDE DHCPv6 [WIDE_DHCPv6], and DHCP Broadband 160 [DHCP_Broadband]. Commercial and open source DHCPv6 software often 161 considers the extensions of DHCPv6 servers because they cannot always 162 meet the requirements that the administrators want. In this section, 163 we introduce two typical DHCPv6 servers: Cisco Prime Network 164 Registrar and Kea DHCP. 166 3.2.1. Cisco Prime Network Registrar DHCP Server Extension APIs 168 Cisco Prime Network Registrar (CPNR) [CPNR] is an appliance which 169 provides integrated Domain Name Server, DHCP, and IP Address 170 Management services for IPv4 and IPv6. At the same time, CPNR DHCP 171 server provides extension APIs and allows administrators to write 172 extensions and functions to alter and customize how it handles and 173 responds to DHCP requests. A network operator usually decides what 174 packet process to modify, how to modify, and which extension point to 175 attach the extension. Then the network operator just writes the 176 extension and adds the well-written extension to the extension point 177 of the DHCP server. Finally, the network operator reloads the DHCP 178 server and debugs whether the server runs as it expects. 180 3.2.2. Kea DHCP Hook Mechanisms 182 Kea DHCP provides hook mechanisms, a well-designed interface for 183 third-party code, to solve the problem that the DHCP server does not 184 quite do what a network operator require. A network operator can use 185 several well-defined framework functions to load and initialize a 186 library and write specific callout functions to attach to the hook 187 points. After building and configuring the hooks library, the server 188 runs as the network operator requires. Additionally, Kea DHCP allows 189 the network operator to use logging in the hooks library. 191 4. Problem Statement 193 This section elaborates the problem statement of multi-requirement 194 extensions for DHCPv6. Section 4.1 describes the general model of 195 DHCP, while Section 4.2 analyzes the extension points and 196 requirements, suggesting possible future work. 198 4.1. DHCP General Model 200 Figure 1 summarizes the DHCP general model and its possible 201 extensions: DHCP messages, options, message processing functions, and 202 address generation mechanisms. 204 +-------------------+ +------------------+ 205 | DHCPv6 client | | DHCPv6 relay | 206 | +---------------+ | DHCP messages with options| +--------------+ | 207 | | Message | |<------------------------->| | Message | | 208 | | processing | | | | relaying | | 209 | | functions | | | | functions | | 210 | +---------------+ | | +--------------+ | 211 +-------------------+ +------------------+ 212 ^ 213 | 214 DHCP messages with options | 215 | 216 V 217 +------------------+ 218 | DHCPv6 server | 219 +------------+ | +--------------+ | 220 | Address | | | Message | | 221 | generation |<-----------------------------+-| processing | | 222 | mechanisms | | | functions | | 223 +------------+ | +--------------+ | 224 +------------------+ 226 Figure 1: DHCP general model and its possible extensions. 228 4.2. Extension Discussion 230 4.2.1. DHCP Messages 232 In fact, new messages can be designed and added to DHCPv6 protocol, 233 e.g., active leasequery [RFC7653]. But currently, people are 234 concerned about the security and privacy issues of DHCP protocol. 235 [RFC7819] and [RFC7824] describe the privacy issues associated with 236 the use of DHCPv4 and DHCPv6, respectively. DHCPv6 does not provide 237 the privacy protection on messages and options. That is to say, 238 other nodes can see the options transmitted in the DHCPv6 messages 239 between DHCPv6 clients and servers. 241 4.2.2. Options 243 DHCPv6 allows defining options for common requirements, e.g., DNS and 244 NTP. In other cases, network operators may require DHCP messages to 245 transmit some self-defined options between clients and servers. 246 Currently, vendor-specific information option allows clients and 247 servers to exchange vendor-specific information. Therefore, 248 administrative domains can define and use sub-options of vendor- 249 specific option to serve their private purposes. The content of the 250 self-defined options may come from two sources: devices and users. 251 If the content of self-defined options comes from users, two methods 252 can be used to solve the problem. The first one is that the clients 253 provide related interfaces to receive such information, which is 254 currently merely supported. The second one is that DHCPv6 relays 255 obtain such information and add it into the clients' requests. But 256 this always depends on other protocols to allow DHCPv6 relays to get 257 the information first. 259 4.2.3. Message Processing Functions 261 Although current commercial or open-source DHCP server software 262 provides comprehensive functionalities, they still cannot meet all 263 customers' requirements of processing DHCP requests. Therefore, they 264 will provide interfaces that customers can use to write their 265 specific extensions to affect the way how DHCP servers handle and 266 respond to DHCP requests. For example, not all networks prefer to 267 use DHCPv6 servers to assign the privacy-preserving random-form 268 addresses generated by some fixed address generation mechanism to 269 DHCPv6 clients. Several address generation mechanisms for SLAAC 270 [RFC4862] (e.g., IEEE 64-bit EUI-64 [RFC2464], Constant, semantically 271 opaque [Microsoft], Temporary [RFC4941], and Stable, semantically 272 opaque [RFC7217]) proposed for different requirements can be utilized 273 in DHCPv6 protocol as well. The many types of IPv6 address 274 generation mechanisms available have brought about flexibility and 275 diversity. Thus, network operators may alter their DHCPv6 servers 276 through the given extensions to use their own preferred address 277 generation mechanisms to assign addresses to DHCPv6 clients. 278 However, not all DHCP software considers this extension. 280 4.2.4. Address Generation Mechanisms 282 Currently, the DHCPv6 servers assign addresses, prefixes and other 283 configuration options according to their configured policies. 284 Generally, different networks may prefer different address generation 285 mechanisms. Corresponding interfaces could be open and defined to 286 allow other address generation mechanisms to be configured. 288 4.2.5. Extension Principles 290 The principles used to conduct multi-requirement extensions for 291 DHCPv6 are summarized as follows: 293 1) Do not change the current DHCP general model. 295 2) Use simpler interfaces to define and support more extensions. 297 5. Extension Cases 299 Administrative domains may enforce local policies according to their 300 requirements, e.g., authentication, accountability. Several kinds of 301 multi-requirement extensions are presented in this section, including 302 configurations in current DHCP software, option definition and server 303 modification, and message definition between DHCP entities and third- 304 party entities. 306 Currently, many DHCP servers provide administrative mechanisms, e.g., 307 host reservation and client classification. Host reservation is 308 often used to assign certain parameters (e.g., IP addresses) to 309 specific devices. Client classification is often used to 310 differentiate between different types of clients and treat them 311 accordingly in certain cases. 313 To meet specific requirements, more complicated extensions of DHCPv6 314 are needed. For example, considering such a requirement that DHCP 315 servers assign IP addresses generated by user identifiers to the 316 clients in a network to hold users accountable, two extensions should 317 be fulfilled to meet this requirement. The first one is that clients 318 send their user identifiers to servers. This can be achieved by 319 defining and using sub-options of vendor specific information option. 320 The second one is that servers use user identifiers to generate IP 321 addresses. To achieve this goal, extension mechanisms provided by 322 the server software such as extension points in CPNR [CPNR] and hook 323 mechanisms in Kea DHCP [Kea_DHCP] can be used. 325 Some extensions for DHCPv6 may need the support of third-party 326 entities. For example, [RFC7037] introduces RADIUS entities into the 327 message exchanges between DHCPv6 entities for better service 328 provision. In fact, the authentication in [RFC7037] can be also used 329 to meet the accountability requirement mentioned above because it is 330 important to authenticate users first before assigning IP addresses 331 generated from user identifiers. Usually, this kind of extension 332 requires the definition of messages communicated between DHCP 333 entities and third-party entities, e.g., active leasequery [RFC7653]. 335 IPv6 addresses are related to manageability, security, traceability, 336 and accountability of networks. As DHCPv6 assigns IPv6 addresses to 337 IPv6 nodes, it is important that DHCPv6 provides interfaces to allow 338 administrative domains to conduct extensions to meet their multi- 339 requirements. 341 6. Security Considerations 343 Security issues related with DHCPv6 are described in Section 22 of 344 [RFC8415]. 346 7. IANA Considerations 348 This document does not include an IANA request. 350 8. Acknowledgements 352 The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng 353 Jiang, and Jinmei Tatuya for their comments and suggestions that 354 improved the [draft-ren-dhc-mredhcpv6]. Some ideas and thoughts of 355 [draft-ren-dhc-mredhcpv6] are contained in this document. 357 9. Normative References 359 [CPNR] Cisco, "Cisco Prime Network Registrar", 2018, 360 . 363 [DHCP_Broadband] 364 Weird Solutions, "DHCP Broadband", 2018, 365 . 368 [draft-ren-dhc-mredhcpv6] 369 Ren, G., He, L., and Y. Liu, "Multi-requirement Extensions 370 for Dynamic Host Configuration Protocol for IPv6 371 (DHCPv6)", March 2017. 373 [FreeRADIUS_DHCP] 374 FreeRADIUS, "FreeRADIUS DHCP", 2017, 375 . 377 [GAGMS] Liu, Y., He, L., and G. Ren, "GAGMS: A Requirement-Driven 378 General Address Generation and Management System", 379 November 2017. 381 [ISC_DHCP] 382 Internet System Consortium, "ISC DHCP", 2018, 383 . 385 [Kea_DHCP] 386 Internet System Consortium, "Kea DHCP", 2018, 387 . 389 [kea_dhcp_hook_developers_guide] 390 Internet Systems Consortium, "Hook Developer's Guide", 391 2018, . 394 [Microsoft] 395 Microsoft, "IPv6 interface identifiers", 2013, . 399 [Microsoft_DHCP] 400 Microsoft, "Microsoft DHCP", 2008, 401 . 404 [Nominum_DHCP] 405 Nominum, "Nominum DHCP", 2012, 406 . 410 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 411 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 412 . 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 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 420 Extensions for Stateless Address Autoconfiguration in 421 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 422 . 424 [RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 425 Relay Agent", RFC 7037, DOI 10.17487/RFC7037, October 426 2013, . 428 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 429 Interface Identifiers with IPv6 Stateless Address 430 Autoconfiguration (SLAAC)", RFC 7217, 431 DOI 10.17487/RFC7217, April 2014, 432 . 434 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 435 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 436 October 2015, . 438 [RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy 439 Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, 440 April 2016, . 442 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 443 Considerations for DHCPv6", RFC 7824, 444 DOI 10.17487/RFC7824, May 2016, 445 . 447 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 448 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 449 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 450 RFC 8415, DOI 10.17487/RFC8415, November 2018, 451 . 453 [VitalQIP] 454 Nokia, "Nokia VitalQIP", 2017, 455 . 458 [WIDE_DHCPv6] 459 KAME project, "WIDE DHCPv6", 2008, 460 . 462 Authors' Addresses 464 Gang Ren 465 Tsinghua University 466 Beijing 100084 467 P.R.China 469 Phone: +86-010 6260 3227 470 Email: rengang@cernet.edu.cn 471 Lin He 472 Tsinghua University 473 Beijing 100084 474 P.R.China 476 Email: he-l14@mails.tsinghua.edu.cn 478 Ying Liu 479 Tsinghua University 480 Beijing 100084 481 P.R.China 483 Email: liuying@cernet.edu.cn