idnits 2.17.1 draft-ren-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 : ---------------------------------------------------------------------------- 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 (March 10, 2019) is 1867 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'NIDTGA' is defined on line 378, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: September 11, 2019 Tsinghua University 6 March 10, 2019 8 Problem Statement of Multi-requirement Extensions for Dynamic Host 9 Configuration Protocol for IPv6 (DHCPv6) 10 draft-ren-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. This 16 document analyzes current extension practices and typical DHCP server 17 software on extensions, defines a DHCP general model, discusses some 18 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 http://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 September 11, 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Current Extension Practices . . . . . . . . . . . . . . . . . 4 57 3.1. Standardized and Non-standardized DHCPv6 Extension 58 Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Current DHCPv6 Server Software Cases . . . . . . . . . . . 4 60 3.2.1. Cisco Prime Network Registrar DHCP Server 61 Extension APIs . . . . . . . . . . . . . . . . . . . . 4 62 3.2.2. Kea DHCP Hook Mechanisms . . . . . . . . . . . . . . . 5 63 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. DHCP General Model . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Extension Discussion . . . . . . . . . . . . . . . . . . . 6 66 4.2.1. DHCP Messages . . . . . . . . . . . . . . . . . . . . 6 67 4.2.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2.3. Message Processing Functions . . . . . . . . . . . . . 7 69 4.2.4. Address Generation Mechanisms . . . . . . . . . . . . 7 70 4.2.5. Extension Principles . . . . . . . . . . . . . . . . . 7 71 5. Extensions Cases . . . . . . . . . . . . . . . . . . . . . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 75 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 The IP address plays a significant role in the communication of the 81 Internet. IP address generation is also closely related to the 82 manageability, security, privacy protection, and traceability of 83 networks. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 84 [I-D.ietf-dhc-rfc3315bis] is an important network protocol that can 85 be used to dynamically provide IPv6 addresses and other network 86 configuration parameters to IPv6 hosts. Actually, DHCPv6 continues 87 to be extended and improved through new options, protocols or message 88 processing mechanisms. 90 Although DHCPv6 provides more and more comprehensive functionality 91 and DHCPv6 server software also provides extension interfaces to 92 allow administrators to alter and customize the way how they handle 93 and respond to DHCPv6 messages, there is still a lack of a general 94 insight into where and how to conduct extensions in DHCPv6 95 effectively. Therefore, a detailed analysis is required to clarify 96 the problems, design principles, and extract and unify the design 97 specifications to help better solve the extension problems. 99 In summary, multiple extensions on DHCPv6 can be conducted to support 100 the administrator's self-defined functionalities. As DHCPv6 is an 101 important and useful protocol related to IPv6 addresses generation, 102 it can provide more extended and flexible functionalities to meet 103 administrators' requirements. According to well-designed principles, 104 extended interfaces can be defined to support more self-defined 105 multi-requirement extensions without sacrificing the stability of 106 DHCPv6. 108 Some people would suggest administrators modify the open-source DHCP 109 servers to solve their problems. However, a great amount of time 110 will be taken to understand the open source DHCP server codes, not to 111 say the consuming time debugging the bugs, failures or system crash 112 caused by modifying the complicated modules. Another problem is that 113 as the open source software evolves, the source codes of the server 114 software may change (new functionalities or fixing bugs). Users may 115 need to re-write their codes once the new version of open-source 116 server software comes out [kea_dhcp_hook_developers_guide] . Hence, 117 the multi-requirement extensions for DHCPv6 to solve administrators' 118 specific problems are very necessary and significant. 120 This document describes current extension practices and typical DHCP 121 server software on extensions and provides a problem statement by 122 defining a DHCP general model, discussing the extension problems, and 123 presenting extension cases. 125 2. Terminology 127 Familiarity with DHCPv6 and its terminology, as defined in 128 [I-D.ietf-dhc-rfc3315bis], is assumed. 130 3. Current Extension Practices 132 3.1. Standardized and Non-standardized DHCPv6 Extension Cases 134 Many documents attempt to extend DHCPv6. They can be classified into 135 three categories. 137 Extended options Most extensions for DHCPv6 are implemented in 138 this way. New-defined options carry specific 139 parameters in the DHCPv6 messages, which helps 140 DHCPv6 clients or servers know the detailed 141 situation with each other. 143 Extended messages Some documents define new protocols that aim to 144 achieve specific goals, e.g., active leasequery 145 [RFC7653], GAGMS [GAGMS]. 147 Extended entities Some documents introduce third-party entities 148 into the communications of DHCPv6 to achieve 149 specific goals, e.g., authentication [RFC7037]. 151 3.2. Current DHCPv6 Server Software Cases 153 A lot of commercial and open source DHCP servers exist, including 154 Cisco Prime Network Registrar [CPNR], Microsoft DHCP 155 [Microsoft_DHCP], VitalQIP [VitalQIP], Nominum DHCP [Nominum_DHCP], 156 ISC DHCP [ISC_DHCP], Kea DHCP [Kea_DHCP], FreeRADIUS DHCP 157 [FreeRADIUS_DHCP], WIDE DHCPv6 [WIDE_DHCPv6], and DHCP Broadband 158 [DHCP_Broadband]. Commercial and open source DHCPv6 software often 159 considers the extensions of DHCPv6 servers because they cannot always 160 meet the requirements that the administrators want. In this section, 161 we introduce two typical DHCPv6 servers: Cisco Prime Network 162 Registrar and Kea DHCP. 164 3.2.1. Cisco Prime Network Registrar DHCP Server Extension APIs 166 Cisco Prime Network Registrar (CPNR) [CPNR] is an appliance which 167 provides integrated Domain Name Server, DHCP, and IP Address 168 Management services for IPv4 and IPv6. At the same time, CPNR DHCP 169 server allows administrators to write extensions and functions to 170 alter and customize how it handles and responds to DHCP requests. A 171 network operator usually decides what packet process to modify, how 172 to modify, and which extension point to attach the extension. Then 173 the network operator just writes the extension and adds the well- 174 written extension to the extension point of the DHCP server. 175 Finally, the network operator reloads the DHCP server and debugs 176 whether the server runs as it expects. 178 3.2.2. Kea DHCP Hook Mechanisms 180 Kea DHCP provides hook mechanisms, a well-designed interface for 181 third-party code, to solve the problem that the DHCP server does not 182 quite do what a network operator require. A network operator can use 183 several well-defined framework functions to load and initialize a 184 library and write specific callout functions to attach to the hook 185 points. After building and configuring the hooks library, the server 186 runs as the network operator requires. Additionally, Kea DHCP allows 187 the network operator to use logging in the hooks library. 189 4. Problem Statement 191 This section elaborates the problem statement of multi-requirement 192 extensions for DHCPv6. Section 4.1 describes the general model of 193 DHCP, while Section 4.2 analyzes the extension points and 194 requirements, suggesting possible future work. 196 4.1. DHCP General Model 198 Figure 1 summarizes the DHCP general model and its possible 199 extensions: DHCP messages, options, message processing functions, and 200 address generation mechanisms. 202 +-------------------+ +-------------------+ 203 | DHCPv6 client | | DHCPv6 relay | 204 | +---------------+ | DHCP messages with options| +---------------+ | 205 | | Message | |<------------------------->| | Message | | 206 | | processing | | | | processing | | 207 | | functions | | | | functions | | 208 | +---------------+ | | +---------------+ | 209 +-------------------+ +-------------------+ 210 ^ 211 | 212 DHCP messages with options | 213 | 214 V 215 +-------------------+ 216 | DHCPv6 server | 217 +------------+ | +---------------+ | 218 | Address | | | Message | | 219 | generation |<-----------------------------+-| processing | | 220 | mechanisms | | | functions | | 221 +------------+ | +---------------+ | 222 +-------------------+ 224 Figure 1: DHCP general model and its possible extensions. 226 4.2. Extension Discussion 228 4.2.1. DHCP Messages 230 In fact, new messages can be designed and added to DHCPv6 protocol, 231 e.g., active leasequery. But currently, people are always concerned 232 about the security and privacy issues of DHCP protocol. [RFC7819] 233 and [RFC7824] describe the privacy issues associated with the use of 234 DHCPv4 and DHCPv6, respectively. DHCPv6 does not provide the privacy 235 protection on messages and options. That is to say, other nodes can 236 see the options transmitted in the DHCPv6 messages between DHCPv6 237 clients and servers. 239 4.2.2. Options 241 DHCPv6 allows defining options for common requirements, e.g., DNS and 242 NTP. In other cases, network operators may require DHCP messages to 243 transmit some self-defined options between clients and servers. 244 Currently, vendor-specific information option allows clients and 245 servers to exchange vendor-specific information. Therefore, 246 administrative domains can define and use sub-options of vendor- 247 specific option to serve their private purposes. However, the 248 content of the self-defined options may come from two sources: hosts 249 and users. If the content of self-defined options comes from the 250 user, two methods can be used to solve the problem. The first one is 251 that the clients provide related interfaces to receive such 252 information, which is currently merely supported. The second one is 253 that DHCPv6 relays obtain such information and add it into the 254 client's request. But this always depends on other protocols to get 255 the information first. 257 4.2.3. Message Processing Functions 259 Although current commercial or open-source DHCP server software 260 provide comprehensive functionality, they still cannot meet all 261 customers' requirements of processing DHCP requests. Therefore, 262 improved commercial or open-source DHCP server software will provide 263 interfaces that customers can use to write their specific extensions 264 to affect the way how DHCP servers handle and respond to DHCP 265 requests. For example, not all networks prefer to use DHCPv6 servers 266 to assign the privacy-preserving random-form addresses generated by 267 some fixed address generation mechanism to DHCPv6 clients. Several 268 address generation mechanisms for SLAAC [RFC4862] (e.g., IEEE 64-bit 269 EUI-64 [RFC2464], Constant, semantically opaque [Microsoft], 270 Temporary [RFC4941], and Stable, semantically opaque [RFC7217]) 271 proposed for different requirements can be also utilized in DHCPv6 272 protocol. The many types of IPv6 address generation mechanisms 273 available have brought about flexibility and diversity. Thus, 274 network operators may alter their DHCPv6 servers through the given 275 extensions to use their own preferred address generation mechanisms 276 to assign addresses to DHCPv6 clients. However, not all DHCP 277 software consider this extension. 279 4.2.4. Address Generation Mechanisms 281 Currently, DHCPv6 servers try to generate random addresses and assign 282 them to clients. However, different networks may prefer different 283 address generation mechanisms. Corresponding interfaces could be 284 open and defined to allow other address generation mechanisms to be 285 configured. 287 4.2.5. Extension Principles 289 The principles used to conduct multi-requirement extensions for 290 DHCPv6 are summarized as follows: 292 1) Do not change the current DHCP general model. 294 2) Use simpler interfaces to define and support more extensions. 296 3) TBD 298 5. Extensions Cases 300 Some administrative domains or countries may have control of out-of- 301 domain resources, and one method to loose the control is that the 302 administrative domains or countries can account for their users using 303 source addresses. Considering such a requirement that DHCP servers 304 assign IP addresses generated by user identifiers to the clients in a 305 network, two extensions should be fulfilled to meet this requirement. 306 The first one is that clients send their user identifiers to servers. 307 This can be achieved by defining and using sub-options of vendor 308 specific information option. For example, the network uses 802.1X to 309 authenticate users. The DHCPv6 relay which can access the user 310 identifiers in the 802.1X authenticator inserts the corresponding 311 user identifier into the client's request. Then DHCPv6 servers can 312 extract user identifier from the request. The second is that servers 313 use user identifiers to generate IP addresses. To achieve this goal, 314 extension mechanisms provided by the server software such as 315 extension points provided by CPNR [CPNR] and hook mechanisms in Kea 316 DHCP [Kea_DHCP] can be used, in which DHCP servers extract user 317 identifiers and generate IP addresses. 319 6. Security Considerations 321 Security issues related with DHCPv6 are described in Section 22 of 322 [I-D.ietf-dhc-rfc3315bis]. 324 7. IANA Considerations 326 This document does not include an IANA request. 328 8. Acknowledgements 330 The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng 331 Jiang, and Jinmei Tatuya for their comments and suggestions that 332 improved the [draft-ren-dhc-mredhcpv6]. Some ideas and thoughts of 333 [draft-ren-dhc-mredhcpv6] are contained in this document. 335 9. Normative References 337 [CPNR] Cisco, "Cisco Prime Network Registrar", 2018, . 341 [DHCP_Broadband] 342 Weird Solutions, "DHCP Broadband", 2018, . 345 [FreeRADIUS_DHCP] 346 FreeRADIUS, "FreeRADIUS DHCP", 2017, 347 . 349 [GAGMS] Liu, Y., He, L., and G. Ren, "GAGMS: A Requirement-Driven 350 General Address Generation and Management System", 351 November 2017. 353 [I-D.ietf-dhc-rfc3315bis] 354 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 355 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 356 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 357 bis", draft-ietf-dhc-rfc3315bis-13 (work in progress), 358 April 2018. 360 [ISC_DHCP] 361 Internet System Consortium, "ISC DHCP", 2018, 362 . 364 [Kea_DHCP] 365 Internet System Consortium, "Kea DHCP", 2018, 366 . 368 [Microsoft] 369 Microsoft, "IPv6 interface identifiers", 2013, . 373 [Microsoft_DHCP] 374 Microsoft, "Microsoft DHCP", 2008, . 378 [NIDTGA] Liu, Y., Ren, G., Wu J., Zhang s., He, L., and Y. Jia, 379 "Building an IPv6 address generation and traceback system 380 with NIDTGA in Address Driven Network", 2015, . 383 [Nominum_DHCP] 384 Nominum, "Nominum DHCP", 2012, . 389 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 390 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 391 . 393 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 394 Address Autoconfiguration", RFC 4862, DOI 10.17487/ 395 RFC4862, September 2007, 396 . 398 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 399 Extensions for Stateless Address Autoconfiguration in 400 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 401 . 403 [RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 404 Relay Agent", RFC 7037, DOI 10.17487/RFC7037, 405 October 2013, . 407 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 408 Interface Identifiers with IPv6 Stateless Address 409 Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/ 410 RFC7217, April 2014, 411 . 413 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 414 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 415 October 2015, . 417 [RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy 418 Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, 419 April 2016, . 421 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 422 Considerations for DHCPv6", RFC 7824, DOI 10.17487/ 423 RFC7824, May 2016, 424 . 426 [VitalQIP] 427 Nokia, "Nokia VitalQIP", 2017, . 431 [WIDE_DHCPv6] 432 KAME project, "WIDE DHCPv6", 2008, 433 . 435 [draft-ren-dhc-mredhcpv6] 436 Ren, G., He, L., and Y. Liu, "Multi-requirement Extensions 437 for Dynamic Host Configuration Protocol for IPv6 438 (DHCPv6)", March 2017. 440 [kea_dhcp_hook_developers_guide] 441 Internet Systems Consortium, "Hook Developer's Guide", 442 2018, . 445 Authors' Addresses 447 Gang Ren 448 Tsinghua University 449 Beijing, 100084 450 P.R.China 452 Phone: +86-010 6260 3227 453 Email: rengang@cernet.edu.cn 455 Lin He 456 Tsinghua University 457 Beijing, 100084 458 P.R.China 460 Email: he-l14@mails.tsinghua.edu.cn 462 Ying Liu 463 Tsinghua University 464 Beijing, 100084 465 P.R.China 467 Email: liuying@cernet.edu.cn