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

Abstract

The manageability, security, privacy protection, and traceability of networks can be supported by extending DHCPv6 protocol. This document analyzes the current extension practices and typical DHCP server software on extensions, defines a DHCP general model, lists the unresolved problem, and provides the possible directions to solve the problems.

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 September 20, 2018.

Copyright Notice

Copyright (c) 2018 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. Unresolved Problems
• 4.2.1. DHCP Messages
• 4.2.2. Options
• 4.2.3. Message Processing Functions
• 4.2.4. Address Generation Mechanisms
• 4.2.5. Extension Principles
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

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

Even if DHCPv6 provides more and more comprehensive functionality and many DHCPv6 server software have provided extension interfaces to allow users to alter and customize the way how they handle and respond to DHCPv6 messages, a general insight of how to solve the extension problem effectively is lack. We should figure out where and how to conduct extensions in the 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 extension problems.

In summary, multiple extensions can be conducted on DHCPv6 to support the user's self-defined functionality. As DHCPv6 is such an important and useful protocol related to IPv6 addresses generation, it can provide more extended and flexible functionality to meet users' 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 the user modify the open-source DHCP servers to solve their own problem. However, a great amount of time will be taken to understand the open source DHCP server code, 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 code of the server software may change (new functionality 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 users' specific problems are very necessary and significant.

This document describes the current extension practices and typical DHCP server software on extensions and provides a problem statement by defining a DHCP general model, analyzing the unresolved multi-requirement extension problems, and providing possible directions for new work that could solve these problems.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this memo are to be interpreted as described in [RFC2119].

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

3. Current Extension Practices

3.1. Standardized and Non-standardized DHCPv6 Extension Cases

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

Extended options

Most extensions for DHCPv6 are implemented in this way, e.g., DNS configurations [RFC3646], NIS configurations [RFC3898], SNTP configurations [RFC4075], information refresh time configurations [RFC4242], remote-id [RFC4649], FQDN configurations [RFC4704], relay agent echo request [RFC4994], network boot [RFC5970], client link-layer address [RFC6939]. New-defined options carry specific parameters in the DHCPv6 messages, which helps DHCPv6 clients or servers know the detailed situation with each other.

Extended messages

Some documents define new protocols to achieve specific purposes, e.g., secure DHCPv6 [draft-ietf-dhc-sedhcpv6-21], active leasequery [RFC7653], GAGMS [GAGMS]. These protocols often requires defining new messages and new options.

Extended entities

Some documents introduce extra entities into the communications of DHCPv6 to achieve specific purpose, e.g., authentication [RFC7037].

3.2. Current DHCPv6 Server Software Cases

Many commercial and open source DHCP server software 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], etc. Commercial and open source DHCPv6 software often consider the extensions of DHCPv6 servers because they all cannot always meet the requirements that the users want. In this section, we introduce two typical DHCPv6 software: Cisco Prime Network Registrar and Kea DHCP, respectively.

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 allows user to write extensions and functions to alter and customize how it handles and responds to DHCP requests. A network operator usually decides what packets 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 can find that the server will do what he/her wants the server to do.

3.2.2. Kea DHCP Hook Mechanisms

Kea DHCP provides hook mechanisms, a defined interface for third-party or user-written 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 will do what the network operator require. Additionally, Kea DHCP allows users to use logging in the hooks library.

4. Problem Statement

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

4.1. DHCP General Model

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

+-------------------+                            +-------------------+
|   DHCPv6 client   |                            |   DHCPv6 relay    |
| +---------------+ | DHCP messages with options | +---------------+ |
| |   Message     | |<-------------------------> | |   Message     | |
| |  processing   | |                            | |  processing   | |
| |  functions    | |                            | |  functions    | |
| +---------------+ |                            | +---------------+ |
+-------------------+                            +-------------------+
                                                         ^
                                                         |
                              DHCP messages with options | 
                                                         |
                                                         V
                                                 +-------------------+
                                                 |   DHCPv6 server   |
    +------------+                               | +---------------+ |
    |  Address   |                               | |   Message     | |
    | generation |<------------------------------+-|  processing   | |
    | mechanisms |                               | |  functions    | |
    +------------+                               | +---------------+ |
                                                 +-------------------+
          

Figure 1: DHCP general model and its possible extensions.

4.2. Unresolved Problems

Currently, DHCPv6 protocol solves the problem that basic options are transmitted in plaintext. However, there are still many problems left to be resolved. Section 4.2.1, Section 4.2.2, Section 4.2.3, and Section 4.2.4 discuss these problems.

4.2.1. DHCP Messages

People are always concerned about the security and privacy issues of DHCP protocol. [RFC7819] and [RFC7824] consider the privacy issues associated with the use of DHCPv4 and DHCPv6 by the Internet users, respectively. The current DHCP protocol does not resolve the problem that the options are transmitted in ciphertext. That is to say, any other nodes can see the options transmitted in the DHCPv6 messages between a DHCPv6 client and servers. Secure DHCPv6 [draft-ietf-dhc-sedhcpv6-21] considers using public cryptography to provide a deployable security mechanism, which can transmit basic options in DHCP messages exchanged between clients and servers. However, this draft is currently dead in IESG. In fact, new messages can be designed and added to DHCPv6 protocol, and DHCP messages can be exchanged in either plaintext or ciphertext.

4.2.2. Options

In other cases, network operators may require DHCP messages to transmit some self-defined options between clients and servers. However, no such mechanisms in the current DHCP protocol support this requirement. DHCP clients do not allow users to transmit options not defined in standards, and not all DHCP server software support transmitting non-standardized options, either. For example, [NIDTGA] modifies the DHCPv6 message exchanges by adding some new options with cryptographic options. However, current DHCP standards do not provide related and flexible interfaces to meet such requirements. In fact, not only DHCP server software can provide interfaces for users to alter the way that they handle and respond to DHCP messages to meet their requirements, but DHCP client software can also provide such interfaces.

4.2.3. Message Processing Functions

Although current commercial or open-source DHCP server software provide comprehensive functionality, they still cannot meet all customers' requirements of processing DHCP requests. Therefore, improved commercial or open-source DHCP server software 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. 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 also utilized in DHCPv6 protocol. The many types of IPv6 address generation mechanisms available have brought about flexibility and diversity. 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 consider this extension.

4.2.4. Address Generation Mechanisms

Different networks may prefer different address generation mechanisms. However, current DHCPv6 protocol only considers generating random IPv6 addresses. Corresponding interfaces should be open and defined to allow other address generation mechanisms to be configured.

4.2.5. Extension Principles

The principles used to conduct multi-requirement extensions for DHCPv6 are summarized as follows:

• 1) Do not change the current DHCP general model.
• 2) Use simpler interfaces to define and support more extensions.

5. Security Considerations

Security issues related with DHCPv6 are described in Section 23 of [RFC3315].

Secure DHCPv6 [draft-ietf-dhc-sedhcpv6-21] attempts to provide a deployable security mechanism for end-to-end communication between DHCP clients and servers.

6. IANA Considerations

This document does not include an IANA request.

7. 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.

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses