draft-ietf-dhc-problem-statement-of-mredhcpv6-01.txt   draft-ietf-dhc-problem-statement-of-mredhcpv6-02.txt 
Dynamic Host Configuration (DHC) G. Ren Dynamic Host Configuration (DHC) G. Ren
Internet-Draft L. He Internet-Draft L. He
Intended status: Informational Y. Liu Intended status: Informational Y. Liu
Expires: April 13, 2020 Tsinghua University Expires: July 15, 2020 Tsinghua University
October 11, 2019 January 12, 2020
Problem Statement of Multi-requirement Extensions for Dynamic Host DHCPv6 Extension Survey and Considerations
Configuration Protocol for IPv6 (DHCPv6) draft-ietf-dhc-problem-statement-of-mredhcpv6-02
draft-ietf-dhc-problem-statement-of-mredhcpv6-01
Abstract Abstract
The manageability, security, privacy protection, and traceability of The manageability, security, privacy protection, and traceability of
networks can be supported by extending DHCPv6 protocol according to networks can be supported by extending DHCPv6 protocol according to
requirements. This document analyzes current extension practices and requirements. This document provides a survey of current extension
typical DHCP server software on extensions, defines a DHCP general practices and typical DHCP server software on extensions, defines a
model, discusses some extension points, and present extension cases. DHCPv6 general model, discusses some extension points, and presents
extension cases.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 13, 2020. This Internet-Draft will expire on July 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Current Extension Practices . . . . . . . . . . . . . . . . . 3 3. Current Extension Practices . . . . . . . . . . . . . . . . . 3
3.1. Standardized and Non-standardized DHCPv6 Extension Cases 3 3.1. Standardized and Non-standardized DHCPv6 Extension Cases 3
3.2. Current DHCPv6 Server Software Cases . . . . . . . . . . 4 3.2. Current DHCPv6 Server Software Cases . . . . . . . . . . 4
3.2.1. Cisco Prime Network Registrar DHCP Server Extension 3.2.1. Cisco Prime Network Registrar DHCP Server Extension
APIs . . . . . . . . . . . . . . . . . . . . . . . . 4 APIs . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.2. Kea DHCP Hook Mechanisms . . . . . . . . . . . . . . 4 3.2.2. Kea DHCP Hook Mechanisms . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Extension Points . . . . . . . . . . . . . . . . . . . . . . 5
4.1. DHCP General Model . . . . . . . . . . . . . . . . . . . 5 4.1. DHCPv6 General Model . . . . . . . . . . . . . . . . . . 5
4.2. Extension Discussion . . . . . . . . . . . . . . . . . . 5 4.2. Extension Discussion . . . . . . . . . . . . . . . . . . 5
4.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.3. Message Processing Functions . . . . . . . . . . . . 6 4.2.3. Message Processing Functions . . . . . . . . . . . . 6
4.2.4. Address Generation Mechanisms . . . . . . . . . . . . 7 4.2.4. Address Generation Mechanisms . . . . . . . . . . . . 7
5. Extension Cases . . . . . . . . . . . . . . . . . . . . . . . 7 5. Extension Cases . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 3, line 29 skipping to change at page 3, line 29
will be taken to understand the open source DHCP server codes, not to will be taken to understand the open source DHCP server codes, not to
say the consuming time debugging the bugs, failures or system crash say the consuming time debugging the bugs, failures or system crash
caused by modifying the complicated modules. Another problem is that caused by modifying the complicated modules. Another problem is that
as the open source software evolves, the source codes of the server as the open source software evolves, the source codes of the server
software may change (new functionalities or fixing bugs). Users may software may change (new functionalities or fixing bugs). Users may
need to re-write their codes once the new version of open-source need to re-write their codes once the new version of open-source
server software comes out [kea_dhcp_hook_developers_guide] . Hence, server software comes out [kea_dhcp_hook_developers_guide] . Hence,
the multi-requirement extensions for DHCPv6 to solve administrators' the multi-requirement extensions for DHCPv6 to solve administrators'
specific problems are very necessary and significant. specific problems are very necessary and significant.
This document describes current extension practices and typical DHCP This document provides a survey of current extension practices and
server software on extensions and provides a problem statement by typical DHCP server software on extensions and gives DHCPv6 extension
defining a DHCP general model, discussing the extension problems, and considerations by defining a DHCPv6 general model, discussing the
presenting extension cases. extension problems, and presenting extension cases.
2. Terminology 2. Terminology
Familiarity with DHCPv6 and its terminology, as defined in [RFC8415], Familiarity with DHCPv6 and its terminology, as defined in [RFC8415],
is assumed. is assumed.
3. Current Extension Practices 3. Current Extension Practices
3.1. Standardized and Non-standardized DHCPv6 Extension Cases 3.1. Standardized and Non-standardized DHCPv6 Extension Cases
Many documents attempt to extend DHCPv6. They can be classified into Many documents attempt to extend DHCPv6. They can be classified into
three categories. three categories.
Extended options Most extensions for DHCPv6 are implemented in Extended options Most extensions for DHCPv6 are implemented in
this way. New-defined options carry specific this way. Newly-defined options carry specific
parameters in DHCPv6 messages, which helps DHCPv6 parameters in DHCPv6 messages, which helps DHCPv6
clients or servers know the detailed situation clients or servers know the detailed situation
with each other. with each other.
Extended messages Some documents define new protocols that aim to Extended messages Some documents define new protocols that aim to
achieve specific goals, e.g., active leasequery achieve specific goals, e.g., active leasequery
[RFC7653], GAGMS [GAGMS]. [RFC7653], GAGMS [GAGMS].
Extended entities Some documents introduce third-party entities Extended entities Some documents introduce third-party entities
into the communications of DHCPv6 to achieve into the communications of DHCPv6 to achieve
skipping to change at page 5, line 5 skipping to change at page 5, line 5
Kea DHCP provides hook mechanisms, a well-designed interface for Kea DHCP provides hook mechanisms, a well-designed interface for
third-party code, to solve the problem that the DHCP server does not 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 quite do what a network operator require. A network operator can use
several well-defined framework functions to load and initialize a several well-defined framework functions to load and initialize a
library and write specific callout functions to attach to the hook library and write specific callout functions to attach to the hook
points. After building and configuring the hooks library, the server points. After building and configuring the hooks library, the server
runs as the network operator requires. Additionally, Kea DHCP allows runs as the network operator requires. Additionally, Kea DHCP allows
the network operator to use logging in the hooks library. the network operator to use logging in the hooks library.
4. Problem Statement 4. Extension Points
This section elaborates the problem statement of multi-requirement This section elaborates multi-requirement extensions for DHCPv6.
extensions for DHCPv6. Section 4.1 describes the general model of Section 4.1 describes the general model of DHCPv6, while Section 4.2
DHCP, while Section 4.2 analyzes the extension points and analyzes the extension points and requirements.
requirements, suggesting possible future work.
4.1. DHCP General Model 4.1. DHCPv6 General Model
Figure 1 summarizes the DHCP general model and its possible Figure 1 summarizes the DHCPv6 general model and its possible
extensions: messages, options, message processing functions, and extensions: messages, options, message processing functions, and
address generation mechanisms. address generation mechanisms.
+-----------------+ +----------------+ +-----------------+ +----------------+
| DHCPv6 client | DHCP messages | DHCPv6 relay | | DHCPv6 client | DHCP messages | DHCPv6 relay |
| +-------------+ | with options | +------------+ | External inputs | +-------------+ | with options | +------------+ | External inputs
| | Message | |<----------------->| | Message | |<---------------- | | Message | |<----------------->| | Message | |<----------------
| | processing | | | | relaying | | e.g., RADIUS | | processing | | | | relaying | | e.g., RADIUS
| | functions | | | | functions | | option [RFC7037] | | functions | | | | functions | | option [RFC7037]
| +-------------+ | | +------------+ | | +-------------+ | | +------------+ |
skipping to change at page 5, line 40 skipping to change at page 5, line 39
V V
+-----------------+ +----------------------------+ +-----------------+ +----------------------------+
| | Extended | DHCPv6 server | | | Extended | DHCPv6 server |
| | messages | +-----------+ +----------+ | | | messages | +-----------+ +----------+ |
|External entities|<------------->| | Address | | Message | | |External entities|<------------->| | Address | | Message | |
| | e.g., Active | | generation| |processing| | | | e.g., Active | | generation| |processing| |
| | leasequery | | mechanisms| |functions | | | | leasequery | | mechanisms| |functions | |
| | [RFC7653] | +-----------+ +----------+ | | | [RFC7653] | +-----------+ +----------+ |
+-----------------+ +----------------------------+ +-----------------+ +----------------------------+
Figure 1: DHCP general model and its possible extensions. Figure 1: DHCPv6 general model and its possible extensions.
4.2. Extension Discussion 4.2. Extension Discussion
4.2.1. Messages 4.2.1. Messages
On the one hand, new DHCP messages can be designed and added to On the one hand, new messages can be designed and added to DHCPv6
DHCPv6 protocol to enrich its funtionalities. For example, [RFC5007] protocol to enrich its funtionalities. For example, [RFC5007]
defines new leasequery messages to allow a requestor to retrive defines new leasequery messages to allow a requestor to retrive
information on the bindings for a client from one or more servers. information on the bindings for a client from one or more servers.
[RFC7653] defines active leasequery messages to keep the requestor up [RFC7653] defines active leasequery messages to keep the requestor up
to date with DHCPv6 bindings. to date with DHCPv6 bindings.
On the other hand, people are concerned about the security and On the other hand, people are concerned about the security and
privacy issues of DHCP protocol. [RFC7819] and [RFC7824] describe privacy issues of DHCP protocol. [RFC7819] and [RFC7824] describe
the privacy issues associated with the use of DHCPv4 and DHCPv6, the privacy issues associated with the use of DHCPv4 and DHCPv6,
respectively. DHCPv6 does not provide the privacy protection on respectively. DHCPv6 does not provide the privacy protection on
messages and options. Other nodes can see the options transmitted in messages and options. Other nodes can see the options transmitted in
DHCPv6 messages between DHCPv6 clients and servers. Extended DHCPv6 messages between DHCPv6 clients and servers. Extended
messages can be designed to secure the exchanges between DHCPv6 messages can be designed to secure the exchanges between DHCPv6
skipping to change at page 6, line 19 skipping to change at page 6, line 16
privacy issues of DHCP protocol. [RFC7819] and [RFC7824] describe privacy issues of DHCP protocol. [RFC7819] and [RFC7824] describe
the privacy issues associated with the use of DHCPv4 and DHCPv6, the privacy issues associated with the use of DHCPv4 and DHCPv6,
respectively. DHCPv6 does not provide the privacy protection on respectively. DHCPv6 does not provide the privacy protection on
messages and options. Other nodes can see the options transmitted in messages and options. Other nodes can see the options transmitted in
DHCPv6 messages between DHCPv6 clients and servers. Extended DHCPv6 messages between DHCPv6 clients and servers. Extended
messages can be designed to secure the exchanges between DHCPv6 messages can be designed to secure the exchanges between DHCPv6
entities. entities.
4.2.2. Options 4.2.2. Options
DHCPv6 allows defining options to transmit parameters between DHCP DHCPv6 allows defining options to transmit parameters between DHCPv6
entities for common requirements, e.g., DNS [RFC3646] and SNTP entities for common requirements, e.g., DNS [RFC3646] and SNTP
[RFC4075]. Also, these parameters may come from external entities. [RFC4075]. Also, these parameters may come from external entities.
For example, [RFC7037] defines RADIUS option to exchange For example, [RFC7037] defines RADIUS option to exchange
authorization and identification information between the DHCPv6 relay authorization and identification information between the DHCPv6 relay
agent and DHCPv6 server. agent and DHCPv6 server.
In other cases, network operators may require DHCP messages to In other cases, network operators may require DHCPv6 messages to
transmit some self-defined options between clients and servers. transmit some self-defined options between clients and servers.
Currently, vendor-specific information option allows clients and Currently, vendor-specific information option allows clients and
servers to exchange vendor-specific information. Therefore, servers to exchange vendor-specific information. Therefore,
administrative domains can define and use sub-options of vendor- administrative domains can define and use sub-options of vendor-
specific option to serve their private purposes. The content of the specific option to serve their private purposes. The content of the
self-defined options may come from two sources: devices and users. self-defined options may come from two sources: devices and users.
If the content of self-defined options comes from users, two methods 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 can be used to solve the problem. The first one is that the clients
provide related interfaces to receive such information, which is provide related interfaces to receive such information, which is
currently merely supported. The second one is that DHCPv6 relays currently merely supported. The second one is that DHCPv6 relays
skipping to change at page 7, line 28 skipping to change at page 7, line 26
diversity. Therefore, corresponding interfaces could be open and diversity. Therefore, corresponding interfaces could be open and
defined to allow other address generation mechanisms to be defined to allow other address generation mechanisms to be
configured. configured.
5. Extension Cases 5. Extension Cases
Administrative domains may enforce local policies according to their Administrative domains may enforce local policies according to their
requirements, e.g., authentication, accountability. Several kinds of requirements, e.g., authentication, accountability. Several kinds of
multi-requirement extensions are presented in this section, including multi-requirement extensions are presented in this section, including
configurations in current DHCP software, option definition and server configurations in current DHCP software, option definition and server
modification, and message definition between DHCP entities and third- modification, and message definition between DHCPv6 entities and
party entities. third-party entities.
Currently, many DHCP servers provide administrative mechanisms, e.g., Currently, many DHCPv6 servers provide administrative mechanisms,
host reservation and client classification. Host reservation is e.g., host reservation and client classification. Host reservation
often used to assign certain parameters (e.g., IP addresses) to is often used to assign certain parameters (e.g., IP addresses) to
specific devices. Client classification is often used to specific devices. Client classification is often used to
differentiate between different types of clients and treat them differentiate between different types of clients and treat them
accordingly in certain cases. accordingly in certain cases.
To meet specific requirements, more complicated extensions of DHCPv6 To meet specific requirements, more complicated extensions of DHCPv6
are needed. For example, considering such a requirement that DHCP are needed. For example, considering such a requirement that DHCP
servers assign IP addresses generated by user identifiers to the servers assign IP addresses generated by user identifiers to the
clients in a network to hold users accountable, two extensions should clients in a network to hold users accountable, two extensions should
be fulfilled to meet this requirement. The first one is that clients be fulfilled to meet this requirement. The first one is that clients
send their user identifiers to servers. This can be achieved by send their user identifiers to servers. This can be achieved by
 End of changes. 19 change blocks. 
35 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/