idnits 2.17.1 draft-ietf-dhc-problem-statement-of-mredhcpv6-01.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 (October 11, 2019) is 1658 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: April 13, 2020 Tsinghua University 6 October 11, 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-01 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 April 13, 2020. 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. 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 describes current extension practices and typical DHCP 123 server software on extensions and provides a problem statement by 124 defining a DHCP general model, discussing the extension problems, and 125 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. New-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. Problem Statement 194 This section elaborates the problem statement of multi-requirement 195 extensions for DHCPv6. Section 4.1 describes the general model of 196 DHCP, while Section 4.2 analyzes the extension points and 197 requirements, suggesting possible future work. 199 4.1. DHCP General Model 201 Figure 1 summarizes the DHCP general model and its possible 202 extensions: messages, options, message processing functions, and 203 address generation mechanisms. 205 +-----------------+ +----------------+ 206 | DHCPv6 client | DHCP messages | DHCPv6 relay | 207 | +-------------+ | with options | +------------+ | External inputs 208 | | Message | |<----------------->| | Message | |<---------------- 209 | | processing | | | | relaying | | e.g., RADIUS 210 | | functions | | | | functions | | option [RFC7037] 211 | +-------------+ | | +------------+ | 212 +-----------------+ +----------------+ 213 ^ 214 DHCP messages | 215 with options | 216 | 217 V 218 +-----------------+ +----------------------------+ 219 | | Extended | DHCPv6 server | 220 | | messages | +-----------+ +----------+ | 221 |External entities|<------------->| | Address | | Message | | 222 | | e.g., Active | | generation| |processing| | 223 | | leasequery | | mechanisms| |functions | | 224 | | [RFC7653] | +-----------+ +----------+ | 225 +-----------------+ +----------------------------+ 227 Figure 1: DHCP general model and its possible extensions. 229 4.2. Extension Discussion 231 4.2.1. Messages 233 On the one hand, new DHCP messages can be designed and added to 234 DHCPv6 protocol to enrich its funtionalities. For example, [RFC5007] 235 defines new leasequery messages to allow a requestor to retrive 236 information on the bindings for a client from one or more servers. 238 [RFC7653] defines active leasequery messages to keep the requestor up 239 to date with DHCPv6 bindings. 241 On the other hand, people are concerned about the security and 242 privacy issues of DHCP protocol. [RFC7819] and [RFC7824] describe 243 the privacy issues associated with the use of DHCPv4 and DHCPv6, 244 respectively. DHCPv6 does not provide the privacy protection on 245 messages and options. Other nodes can see the options transmitted in 246 DHCPv6 messages between DHCPv6 clients and servers. Extended 247 messages can be designed to secure the exchanges between DHCPv6 248 entities. 250 4.2.2. Options 252 DHCPv6 allows defining options to transmit parameters between DHCP 253 entities for common requirements, e.g., DNS [RFC3646] and SNTP 254 [RFC4075]. Also, these parameters may come from external entities. 255 For example, [RFC7037] defines RADIUS option to exchange 256 authorization and identification information between the DHCPv6 relay 257 agent and DHCPv6 server. 259 In other cases, network operators may require DHCP messages to 260 transmit some self-defined options between clients and servers. 261 Currently, vendor-specific information option allows clients and 262 servers to exchange vendor-specific information. Therefore, 263 administrative domains can define and use sub-options of vendor- 264 specific option to serve their private purposes. The content of the 265 self-defined options may come from two sources: devices and users. 266 If the content of self-defined options comes from users, two methods 267 can be used to solve the problem. The first one is that the clients 268 provide related interfaces to receive such information, which is 269 currently merely supported. The second one is that DHCPv6 relays 270 obtain such information and add it into the clients' requests. But 271 this always depends on other protocols to allow DHCPv6 relays to get 272 the information first. 274 4.2.3. Message Processing Functions 276 Although current commercial or open-source DHCP server software 277 provides comprehensive functionalities, they still cannot meet all 278 customers' requirements of processing DHCP requests. Therefore, they 279 will provide interfaces that customers can use to write their 280 specific extensions to affect the way how DHCP servers handle and 281 respond to DHCP requests. For example, not all networks prefer to 282 use DHCPv6 servers to assign the privacy-preserving random-form 283 addresses generated by some fixed address generation mechanism to 284 DHCPv6 clients. Thus, network operators may alter their DHCPv6 285 servers through the given extensions to use their own preferred 286 address generation mechanisms to assign addresses to DHCPv6 clients. 287 However, not all DHCP software considers this extension. 289 4.2.4. Address Generation Mechanisms 291 Currently, the DHCPv6 servers assign addresses, prefixes and other 292 configuration options according to their configured policies. 293 Generally, different networks may prefer different address generation 294 mechanisms. Several address generation mechanisms for SLAAC 295 [RFC4862] (e.g., IEEE 64-bit EUI-64 [RFC2464], Constant, semantically 296 opaque [Microsoft], Temporary [RFC4941], and Stable, semantically 297 opaque [RFC7217]) proposed for different requirements can be utilized 298 in DHCPv6 protocol as well. The many types of IPv6 address 299 generation mechanisms available have brought about flexibility and 300 diversity. Therefore, corresponding interfaces could be open and 301 defined to allow other address generation mechanisms to be 302 configured. 304 5. Extension Cases 306 Administrative domains may enforce local policies according to their 307 requirements, e.g., authentication, accountability. Several kinds of 308 multi-requirement extensions are presented in this section, including 309 configurations in current DHCP software, option definition and server 310 modification, and message definition between DHCP entities and third- 311 party entities. 313 Currently, many DHCP servers provide administrative mechanisms, e.g., 314 host reservation and client classification. Host reservation is 315 often used to assign certain parameters (e.g., IP addresses) to 316 specific devices. Client classification is often used to 317 differentiate between different types of clients and treat them 318 accordingly in certain cases. 320 To meet specific requirements, more complicated extensions of DHCPv6 321 are needed. For example, considering such a requirement that DHCP 322 servers assign IP addresses generated by user identifiers to the 323 clients in a network to hold users accountable, two extensions should 324 be fulfilled to meet this requirement. The first one is that clients 325 send their user identifiers to servers. This can be achieved by 326 defining and using sub-options of vendor specific information option. 327 The second one is that servers use user identifiers to generate IP 328 addresses. To achieve this goal, extension mechanisms provided by 329 the server software such as extension points in CPNR [CPNR] and hook 330 mechanisms in Kea DHCP [Kea_DHCP] can be used. 332 Some extensions for DHCPv6 may need the support of third-party 333 entities. For example, [RFC7037] introduces RADIUS entities into the 334 message exchanges between DHCPv6 entities for better service 335 provision. In fact, the authentication in [RFC7037] can be also used 336 to meet the accountability requirement mentioned above because it is 337 important to authenticate users first before assigning IP addresses 338 generated from user identifiers. Usually, this kind of extension 339 requires the definition of messages communicated between DHCP 340 entities and third-party entities, e.g., active leasequery [RFC7653]. 342 IPv6 addresses are related to manageability, security, traceability, 343 and accountability of networks. As DHCPv6 assigns IPv6 addresses to 344 IPv6 nodes, it is important that DHCPv6 provides interfaces to allow 345 administrative domains to conduct extensions to meet their multi- 346 requirements. 348 6. Security Considerations 350 Security issues related with DHCPv6 are described in Section 22 of 351 [RFC8415]. 353 7. IANA Considerations 355 This document does not include an IANA request. 357 8. Acknowledgements 359 The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng 360 Jiang, and Jinmei Tatuya for their comments and suggestions that 361 improved the [draft-ren-dhc-mredhcpv6]. Some ideas and thoughts of 362 [draft-ren-dhc-mredhcpv6] are contained in this document. 364 9. Normative References 366 [CPNR] Cisco, "Cisco Prime Network Registrar", 2018, 367 . 370 [DHCP_Broadband] 371 Weird Solutions, "DHCP Broadband", 2018, 372 . 375 [draft-ren-dhc-mredhcpv6] 376 Ren, G., He, L., and Y. Liu, "Multi-requirement Extensions 377 for Dynamic Host Configuration Protocol for IPv6 378 (DHCPv6)", March 2017. 380 [FreeRADIUS_DHCP] 381 FreeRADIUS, "FreeRADIUS DHCP", 2017, 382 . 384 [GAGMS] Liu, Y., He, L., and G. Ren, "GAGMS: A Requirement-Driven 385 General Address Generation and Management System", 386 November 2017. 388 [ISC_DHCP] 389 Internet System Consortium, "ISC DHCP", 2018, 390 . 392 [Kea_DHCP] 393 Internet System Consortium, "Kea DHCP", 2018, 394 . 396 [kea_dhcp_hook_developers_guide] 397 Internet Systems Consortium, "Hook Developer's Guide", 398 2018, . 401 [Microsoft] 402 Microsoft, "IPv6 interface identifiers", 2013, . 406 [Microsoft_DHCP] 407 Microsoft, "Microsoft DHCP", 2008, 408 . 411 [Nominum_DHCP] 412 Nominum, "Nominum DHCP", 2012, 413 . 417 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 418 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 419 . 421 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 422 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 423 DOI 10.17487/RFC3646, December 2003, 424 . 426 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 427 Configuration Option for DHCPv6", RFC 4075, 428 DOI 10.17487/RFC4075, May 2005, 429 . 431 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 432 Address Autoconfiguration", RFC 4862, 433 DOI 10.17487/RFC4862, September 2007, 434 . 436 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 437 Extensions for Stateless Address Autoconfiguration in 438 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 439 . 441 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 442 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 443 September 2007, . 445 [RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 446 Relay Agent", RFC 7037, DOI 10.17487/RFC7037, October 447 2013, . 449 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 450 Interface Identifiers with IPv6 Stateless Address 451 Autoconfiguration (SLAAC)", RFC 7217, 452 DOI 10.17487/RFC7217, April 2014, 453 . 455 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 456 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 457 October 2015, . 459 [RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy 460 Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, 461 April 2016, . 463 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 464 Considerations for DHCPv6", RFC 7824, 465 DOI 10.17487/RFC7824, May 2016, 466 . 468 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 469 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 470 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 471 RFC 8415, DOI 10.17487/RFC8415, November 2018, 472 . 474 [VitalQIP] 475 Nokia, "Nokia VitalQIP", 2017, 476 . 479 [WIDE_DHCPv6] 480 KAME project, "WIDE DHCPv6", 2008, 481 . 483 Authors' Addresses 485 Gang Ren 486 Tsinghua University 487 Beijing 100084 488 P.R.China 490 Phone: +86-010 6260 3227 491 Email: rengang@cernet.edu.cn 493 Lin He 494 Tsinghua University 495 Beijing 100084 496 P.R.China 498 Email: he-l14@mails.tsinghua.edu.cn 500 Ying Liu 501 Tsinghua University 502 Beijing 100084 503 P.R.China 505 Email: liuying@cernet.edu.cn