Problem Statement of Multi-requirement Extensions for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-problem-statement-of-mredhcpv6-01

Abstract

The manageability, security, privacy protection, and traceability of networks can be supported by extending DHCPv6 protocol according to requirements. This document analyzes current extension practices and typical DHCP server software on extensions, defines a DHCP general model, discusses some extension points, and present extension cases.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 13, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Current Extension Practices
• 3.1. Standardized and Non-standardized DHCPv6 Extension Cases
• 3.2. Current DHCPv6 Server Software Cases
• 3.2.1. Cisco Prime Network Registrar DHCP Server Extension APIs
• 3.2.2. Kea DHCP Hook Mechanisms
• 4. Problem Statement
• 4.1. DHCP General Model
• 4.2. Extension Discussion
• 4.2.1. Messages
• 4.2.2. Options
• 4.2.3. Message Processing Functions
• 4.2.4. Address Generation Mechanisms
• 5. Extension Cases
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgements
• 9. Normative References
• Authors' Addresses

1. Introduction

The IP address plays a significant role in the communication of the Internet. IP address generation is also closely related to the manageability, security, privacy protection, and traceability of networks. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC8415] is an important network protocol that can be used to dynamically provide IPv6 addresses and other network configuration parameters to IPv6 nodes. Actually, DHCPv6 continues to be extended and improved through new options, protocols or message processing mechanisms.

Although DHCPv6 provides more and more comprehensive functionalities and DHCPv6 server software also provides extension interfaces to allow administrators to alter and customize the way how they handle and respond to DHCPv6 messages, there is still a lack of a general insight into where and how to conduct extensions in DHCPv6 effectively. The extensions to DHCPv6 can be various according to multiple requirements. The goal of multi-requirement extensions for DHCPv6 is to use simple interfaces to define and support more extensions without changing the basic design of DHCPv6. Therefore, a detailed analysis is required to clarify the problems, design principles, and extract and unify the design specifications to help better solve the multi-requirement extension problems.

In summary, multi-requirement extensions for DHCPv6 can be conducted to support the administrator's self-defined functionalities. As DHCPv6 is an important and useful protocol related to IPv6 addresses generation, it can provide more extended and flexible functionalities to meet administrators' requirements. According to well-designed principles, extended interfaces can be defined to support more self-defined multi-requirement extensions without sacrificing the stability of DHCPv6.

Some people would suggest administrators modify the open-source DHCP servers to solve their problems. However, a great amount of time will be taken to understand the open source DHCP server codes, not to say the consuming time debugging the bugs, failures or system crash caused by modifying the complicated modules. Another problem is that as the open source software evolves, the source codes of the server software may change (new functionalities or fixing bugs). Users may need to re-write their codes once the new version of open-source server software comes out [kea_dhcp_hook_developers_guide] . Hence, the multi-requirement extensions for DHCPv6 to solve administrators' specific problems are very necessary and significant.

This document describes current extension practices and typical DHCP server software on extensions and provides a problem statement by defining a DHCP general model, discussing the extension problems, and presenting extension cases.

2. Terminology

Familiarity with DHCPv6 and its terminology, as defined in [RFC8415], is assumed.

3. Current Extension Practices

3.1. Standardized and Non-standardized DHCPv6 Extension Cases

Many documents attempt to extend DHCPv6. They can be classified into three categories.

Extended options

Most extensions for DHCPv6 are implemented in this way. New-defined options carry specific parameters in DHCPv6 messages, which helps DHCPv6 clients or servers know the detailed situation with each other.

Extended messages

Some documents define new protocols that aim to achieve specific goals, e.g., active leasequery [RFC7653], GAGMS [GAGMS].

Extended entities

Some documents introduce third-party entities into the communications of DHCPv6 to achieve specific goals and provide better services, e.g., authentication [RFC7037].

3.2. Current DHCPv6 Server Software Cases

A lot of commercial and open source DHCP servers exist, including Cisco Prime Network Registrar, Microsoft DHCP, VitalQIP [VitalQIP], Nominum DHCP [Nominum_DHCP], ISC DHCP [ISC_DHCP], Kea DHCP [Kea_DHCP], FreeRADIUS DHCP [FreeRADIUS_DHCP], WIDE DHCPv6 [WIDE_DHCPv6], and DHCP Broadband [DHCP_Broadband]. Commercial and open source DHCPv6 software often considers the extensions of DHCPv6 servers because they cannot always meet the requirements that the administrators want. In this section, we introduce two typical DHCPv6 servers: Cisco Prime Network Registrar and Kea DHCP.

3.2.1. Cisco Prime Network Registrar DHCP Server Extension APIs

Cisco Prime Network Registrar (CPNR) [CPNR] is an appliance which provides integrated Domain Name Server, DHCP, and IP Address Management services for IPv4 and IPv6. At the same time, CPNR DHCP server provides extension APIs and allows administrators to write extensions and functions to alter and customize how it handles and responds to DHCP requests. A network operator usually decides what packet process to modify, how to modify, and which extension point to attach the extension. Then the network operator just writes the extension and adds the well-written extension to the extension point of the DHCP server. Finally, the network operator reloads the DHCP server and debugs whether the server runs as it expects.

3.2.2. Kea DHCP Hook Mechanisms

Kea DHCP provides hook mechanisms, a well-designed interface for third-party code, to solve the problem that the DHCP server does not quite do what a network operator require. A network operator can use several well-defined framework functions to load and initialize a library and write specific callout functions to attach to the hook points. After building and configuring the hooks library, the server runs as the network operator requires. Additionally, Kea DHCP allows the network operator to use logging in the hooks library.

4. Problem Statement

This section elaborates the problem statement of multi-requirement extensions for DHCPv6. Section 4.1 describes the general model of DHCP, while Section 4.2 analyzes the extension points and requirements, suggesting possible future work.

4.1. DHCP General Model

Figure 1 summarizes the DHCP general model and its possible extensions: messages, options, message processing functions, and address generation mechanisms.

+-----------------+                   +----------------+
|  DHCPv6 client  |    DHCP messages  |  DHCPv6 relay  |
| +-------------+ |    with options   | +------------+ | External inputs
| |  Message    | |<----------------->| |  Message   | |<----------------
| | processing  | |                   | | relaying   | | e.g., RADIUS
| | functions   | |                   | | functions  | | option [RFC7037]
| +-------------+ |                   | +------------+ |
+-----------------+                   +----------------+
                                              ^  
                                DHCP messages |  
                                with options  |  
                                              |  
                                              V  
+-----------------+               +----------------------------+
|                 |   Extended    |        DHCPv6 server       |
|                 |   messages    | +-----------+ +----------+ |
|External entities|<------------->| |  Address  | | Message  | |
|                 |  e.g., Active | | generation| |processing| |
|                 |  leasequery   | | mechanisms| |functions | |
|                 |  [RFC7653]    | +-----------+ +----------+ |
+-----------------+               +----------------------------+


          

Figure 1: DHCP general model and its possible extensions.

4.2. Extension Discussion

4.2.1. Messages

On the one hand, new DHCP messages can be designed and added to DHCPv6 protocol to enrich its funtionalities. For example, [RFC5007] defines new leasequery messages to allow a requestor to retrive information on the bindings for a client from one or more servers. [RFC7653] defines active leasequery messages to keep the requestor up to date with DHCPv6 bindings.

On the other hand, people are concerned about the security and privacy issues of DHCP protocol. [RFC7819] and [RFC7824] describe the privacy issues associated with the use of DHCPv4 and DHCPv6, respectively. DHCPv6 does not provide the privacy protection on messages and options. Other nodes can see the options transmitted in DHCPv6 messages between DHCPv6 clients and servers. Extended messages can be designed to secure the exchanges between DHCPv6 entities.

4.2.2. Options

DHCPv6 allows defining options to transmit parameters between DHCP entities for common requirements, e.g., DNS [RFC3646] and SNTP [RFC4075]. Also, these parameters may come from external entities. For example, [RFC7037] defines RADIUS option to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server.

In other cases, network operators may require DHCP messages to transmit some self-defined options between clients and servers. Currently, vendor-specific information option allows clients and servers to exchange vendor-specific information. Therefore, administrative domains can define and use sub-options of vendor-specific option to serve their private purposes. The content of the self-defined options may come from two sources: devices and users. If the content of self-defined options comes from users, two methods can be used to solve the problem. The first one is that the clients provide related interfaces to receive such information, which is currently merely supported. The second one is that DHCPv6 relays obtain such information and add it into the clients' requests. But this always depends on other protocols to allow DHCPv6 relays to get the information first.

4.2.3. Message Processing Functions

Although current commercial or open-source DHCP server software provides comprehensive functionalities, they still cannot meet all customers' requirements of processing DHCP requests. Therefore, they will provide interfaces that customers can use to write their specific extensions to affect the way how DHCP servers handle and respond to DHCP requests. For example, not all networks prefer to use DHCPv6 servers to assign the privacy-preserving random-form addresses generated by some fixed address generation mechanism to DHCPv6 clients. Thus, network operators may alter their DHCPv6 servers through the given extensions to use their own preferred address generation mechanisms to assign addresses to DHCPv6 clients. However, not all DHCP software considers this extension.

4.2.4. Address Generation Mechanisms

Currently, the DHCPv6 servers assign addresses, prefixes and other configuration options according to their configured policies. Generally, different networks may prefer different address generation mechanisms. Several address generation mechanisms for SLAAC [RFC4862] (e.g., IEEE 64-bit EUI-64, Constant, semantically opaque, Temporary, and Stable, semantically opaque) proposed for different requirements can be utilized in DHCPv6 protocol as well. The many types of IPv6 address generation mechanisms available have brought about flexibility and diversity. Therefore, corresponding interfaces could be open and defined to allow other address generation mechanisms to be configured.

5. Extension Cases

Administrative domains may enforce local policies according to their requirements, e.g., authentication, accountability. Several kinds of multi-requirement extensions are presented in this section, including configurations in current DHCP software, option definition and server modification, and message definition between DHCP entities and third-party entities.

Currently, many DHCP servers provide administrative mechanisms, e.g., host reservation and client classification. Host reservation is often used to assign certain parameters (e.g., IP addresses) to specific devices. Client classification is often used to differentiate between different types of clients and treat them accordingly in certain cases.

To meet specific requirements, more complicated extensions of DHCPv6 are needed. For example, considering such a requirement that DHCP servers assign IP addresses generated by user identifiers to the clients in a network to hold users accountable, two extensions should be fulfilled to meet this requirement. The first one is that clients send their user identifiers to servers. This can be achieved by defining and using sub-options of vendor specific information option. The second one is that servers use user identifiers to generate IP addresses. To achieve this goal, extension mechanisms provided by the server software such as extension points in CPNR [CPNR] and hook mechanisms in Kea DHCP [Kea_DHCP] can be used.

Some extensions for DHCPv6 may need the support of third-party entities. For example, [RFC7037] introduces RADIUS entities into the message exchanges between DHCPv6 entities for better service provision. In fact, the authentication in [RFC7037] can be also used to meet the accountability requirement mentioned above because it is important to authenticate users first before assigning IP addresses generated from user identifiers. Usually, this kind of extension requires the definition of messages communicated between DHCP entities and third-party entities, e.g., active leasequery [RFC7653].

IPv6 addresses are related to manageability, security, traceability, and accountability of networks. As DHCPv6 assigns IPv6 addresses to IPv6 nodes, it is important that DHCPv6 provides interfaces to allow administrative domains to conduct extensions to meet their multi-requirements.

6. Security Considerations

Security issues related with DHCPv6 are described in Section 22 of [RFC8415].

7. IANA Considerations

This document does not include an IANA request.

8. Acknowledgements

The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng Jiang, and Jinmei Tatuya for their comments and suggestions that improved the [draft-ren-dhc-mredhcpv6]. Some ideas and thoughts of [draft-ren-dhc-mredhcpv6] are contained in this document.

9. Normative References

Authors' Addresses