| Internet-Draft | problem statement of mredhcpv6 | December 2021 |
| Ren, et al. | Expires 23 June 2022 | [Page] |
IP addresses assume an increasing number of attributes as communication identifiers to meet different requirements. Privacy protection, accountability, security, and manageability of networks can be supported by extending the DHCPv6 protocol as required. This document provides current extension practices and typical DHCPv6 server software in terms of extensions, defines a general model of DHCPv6, discusses some extension points, and presents extension cases.¶
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 23 June 2022.¶
Copyright (c) 2021 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
IP addresses play an essential role in communication over the Internet. Their generation and assignment are also closely linked to the privacy protection, accountability, security, and manageability of the network [I-D.gont-v6ops-ipv6-addressing-considerations]. The 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. DHCPv6 can be continuously extended and improved through new options, protocols, and message processing mechanisms.¶
IP addresses assume an increasing number of properties as communication identifiers to meet different requirements. For example, APNA [APNA] and PAVI [PAVI] use addresses to enhance source responsibility and privacy protection. These requirements often need to be reflected by IP address assignment protocols such as DHCPv6. Therefore, extensions to DHCPv6 are made to meet a wide variety of requirements, which is referred to as multi-requirement extensions to DHCPv6. However, it is not easy to extend DHCPv6 to meet a variety of requirements. Although DHCPv6 offers increasingly comprehensive functionality and DHCPv6 server software provides extension interfaces that allow administrators to change and customize the way they process and respond to DHCPv6 messages, there is still a lack of comprehensive understanding of where and how to extend in DHCPv6 effectively. Therefore, a detailed analysis is needed to clarify the issues and design principles and extract and unify design specifications to help better address the multi-demand scaling problem.¶
In summary, with the large-scale deployment and application of IPv6, new scenarios such as Data Center Network, Internet of Things, Industrial Internet, and Integrated satellite-terrestrial networks put forward new requirements for IP address allocation, e.g., the scale of address allocation, the efficiency of address update and synchronization, the address generation algorithms (such as association with location, identifier, and other information), and the scope of dynamic address configuration service relay and collaboration. At the same time, it also puts forward new requirements in network security, accountability, manageability, and privacy protection. These are what we call "multiple requirements". Multi-requirement extensions for DHCPv6 is to meet new scenarios and new requirements through the expansion of new messages, options, message processing functions, or address generation mechanisms for DHCPv6. Based on careful design principles, interfaces can be defined to support more customized multi-requirement extensions without sacrificing the stability of DHCPv6.¶
Some people would suggest that administrators modify the open-source DHCPv6 server to solve their problems. However, it takes considerable time to understand the code of an open-source DHCPv6 server, not to mention the time-consuming task of debugging errors, failures, or system crashes caused by modifying complex modules. Another problem is that as open-source software evolves, the source code of the server software may change (new features or bug fixes). Once the latest version of the open-source server software comes out [kea_dhcp_hook_developers_guide], users may need to rewrite their code. Therefore, the multi-requirement extensions to DHCPv6 to address the specific issues of administrators are essential and significant.¶
This document provides a survey of current extension practices and typical DHCPv6 server softwares on extensions and gives DHCPv6 extension considerations by defining a DHCPv6 general model, discussing the extension problems, and presenting extension cases.¶
Familiarity with DHCPv6 and its terminology, as defined in [RFC8415], is assumed.¶
Many documents attempt to extend DHCPv6. They can be classified into three categories.¶
A lot of commercial and open source DHCPv6 servers exist, including Cisco Prime Network Registrar (CPNR) DHCP [CPNR], DHCP Broadband [DHCP_Broadband], FreeRADIUS DHCP [FreeRADIUS_DHCP], ISC DHCP [ISC_DHCP], Kea DHCP [Kea_DHCP], Microsoft DHCP [Microsoft_DHCP], Nominum DHCP [Nominum_DHCP], VitalQIP [VitalQIP], and WIDE DHCPv6 [WIDE_DHCPv6]. Commercial and open-source DHCPv6 software often considers the extensions of DHCPv6 servers because they cannot always meet the requirements that the administrators want. For example, 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 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. Similarly, 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.¶
This section elaborates multi-requirement extensions for DHCPv6. Section 4.1 describes the general model of DHCPv6, while Section 4.2 analyzes the extension points and requirements.¶
Figure 1 summarizes the DHCPv6 general model and its possible extensions: messages, options, message processing functions, and address generation mechanisms.¶
+-----------------+ +----------------+
| DHCPv6 client | DHCPv6 messages | DHCPv6 relay |
| +-------------+ | with options | +------------+ | External inputs
| | Message | |<---------------->| | Message | |<----------------
| | processing | | | | relaying | | e.g., RADIUS
| | functions | | | | functions | | option [RFC7037]
| +-------------+ | | +------------+ |
+-----------------+ +----------------+
^
DHCPv6 messages |
with options |
|
V
+-----------------+ +----------------------------+
| | Extended | DHCPv6 server |
| | messages | +-----------+ +----------+ |
|External entities|<------------->| | Address | | Message | |
| | e.g., Active | | generation| |processing| |
| | leasequery | | mechanisms| |functions | |
| | [RFC7653] | +-----------+ +----------+ |
+-----------------+ +----------------------------+
¶
Figure 1: DHCPv6 general model and its possible extensions.¶
On the one hand, new messages can be designed and added to the DHCPv6 protocol to enrich its functionalities. For example, [RFC5007] defines new leasequery messages to allow a requestor to retrieve information on the bindings for a client from one or more servers. [RFC5460] expands on the Leasequery protocol by defines new messages and allowing for bulk transfer of DHCPv6 binding data via TCP. [RFC7653] defines active leasequery messages to keep the requestor up to date with DHCPv6 bindings. [RFC8156] defines failover messages to provide a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition.¶
On the other hand, people are concerned about the security and privacy issues of the DHCPv6 protocol. [RFC7824] describes the privacy issues associated with the use of DHCPv6, respectively. DHCPv6 does not provide 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 exchanges between DHCPv6 entities.¶
DHCPv6 allows defining options to transmit parameters between DHCPv6 entities for common requirements, e.g., DNS configurations [RFC3646], NIS configurations [RFC3898], SNTP configurations [RFC4075], relay agent subscriber-id [RFC4580], relay agent remote-id [RFC4649], FQDN configurations [RFC4704], relay agent echo request [RFC4994], network boot [RFC5970], Relay-Supplied Options [RFC6422], virtual subnet selection [RFC6607], client link-layer address [RFC6939], and softwire source binding prefix hint [RFC8539]. 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 DHCPv6 messages to transmit some self-defined options between clients and servers. Currently, the vendor-specific information option allows clients and servers to exchange vendor-specific information. Therefore, administrative domains can define and use the sub-options of the vendor-specific information 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 to the clients' requests. But this always depends on other protocols to allow DHCPv6 relays to get the information first.¶
Although current commercial or open-source DHCPv6 server softwares provide comprehensive functionalities, they still cannot meet all customers' requirements of processing DHCPv6 requests. Therefore, they will offer interfaces that customers can use to write their specific extensions to affect the way how DHCPv6 servers handle and respond to DHCP requests. For example, a network operator may want his DHCPv6 server to communicate with external servers. Thus, he may alter his DHCPv6 server through the given extensions to achieve such a goal. However, not all DHCPv6 software considers this extension.¶
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 [RFC2464], Constant, semantically opaque [Microsoft], Temporary [RFC4941], and Stable, semantically opaque [RFC7217]) proposed for different requirements can be utilized in DHCPv6 protocol as well. Note that [RFC7943] is the DHCPv6 version of Stable, semantically opaque [RFC7217]. 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.¶
Moreover, several basic operations are defined to support the design of IPv6 addresses generation mechanisms. A new IPv6 address generation mechanism can be made up of the combination of the following basic operations. Also, new basic operations can be defined to support new functions.¶
For example, temporary addresses in [RFC4941] can be expressed as tempAddr(eui64, history) = Replace(Truncate(Hash(Concatenate(eui64, history)), 0, 63), 6, 6, 0), where eui64 means the EUI-64 identifier defined in [RFC2464] and history means a history value defined in [RFC4941].¶
The principles used to conduct multi-requirement extensions for DHCPv6 are summarized as follows:¶
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 DHCPv6 software, option definition and server modification, and message definition between DHCPv6 entities and third-party entities. 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.¶
Currently, many DHCPv6 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. For example, a client with special access rights (e.g., a firewall rule that allows access based on the source's IP address) needs to keep its address allowed in the firewall configuration. Another use case is a device with a mission-critical network service that needs access by IP address in case a DNS lookup fails. Client classification is often used to differentiate between different types of clients and treat them accordingly in certain cases. This classification allows DHCP addresses or options to be assigned based on specific device characteristics or some network identifier. Grouping devices by client class makes it more convenient to perform bulk configuration settings. A typical example is the network access security policy. For example, a client class can be configured so that devices in that class are assigned IP addresses in subnets that are restricted to the public Internet due to security policies applied to the subnet/network on the router or firewall.¶
More complicated extensions of DHCPv6 are needed to meet specific requirements. For example, considering such a requirement that DHCPv6 servers assign IPv6 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. The authentication in [RFC7037] can also be 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 DHCPv6 entities and third-party entities, e.g., active leasequery [RFC7653].¶
Security issues related with DHCPv6 are described in Section 22 of [RFC8415].¶
This document does not include an IANA request.¶
The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng Jiang, and Jinmei Tatuya for their comments and suggestions that improved the [I-D.ren-dhc-mredhcpv6]. Some ideas and thoughts of [I-D.ren-dhc-mredhcpv6] are contained in this document.¶