draft-ietf-dhc-problem-statement-of-mredhcpv6-02.txt   draft-ietf-dhc-problem-statement-of-mredhcpv6-03.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: July 15, 2020 Tsinghua University Expires: August 7, 2020 Tsinghua University
January 12, 2020 February 4, 2020
DHCPv6 Extension Survey and Considerations DHCPv6 Extension Survey and Considerations
draft-ietf-dhc-problem-statement-of-mredhcpv6-02 draft-ietf-dhc-problem-statement-of-mredhcpv6-03
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 the DHCPv6 protocol according
requirements. This document provides a survey of current extension to requirements. This document provides a survey of current
practices and typical DHCP server software on extensions, defines a extension practices and typical DHCP server software on extensions,
DHCPv6 general model, discusses some extension points, and presents defines a DHCPv6 general model, discusses some extension points, and
extension cases. 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 July 15, 2020. This Internet-Draft will expire on August 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
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. Extension Points . . . . . . . . . . . . . . . . . . . . . . 5 4. Extension Discussion . . . . . . . . . . . . . . . . . . . . 5
4.1. DHCPv6 General Model . . . . . . . . . . . . . . . . . . 5 4.1. DHCPv6 General Model . . . . . . . . . . . . . . . . . . 5
4.2. Extension Discussion . . . . . . . . . . . . . . . . . . 5 4.2. Extension Points . . . . . . . . . . . . . . . . . . . . 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The IP address plays a significant role in the communication of the The IP address plays a significant role in the communication of the
Internet. IP address generation is also closely related to the Internet. IP address generation is also closely related to the
manageability, security, privacy protection, and traceability of manageability, security, privacy protection, and traceability of
networks. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) networks. Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
[RFC8415] is an important network protocol that can be used to [RFC8415] is a critical network protocol that can be used to
dynamically provide IPv6 addresses and other network configuration dynamically provide IPv6 addresses and other network configuration
parameters to IPv6 nodes. Actually, DHCPv6 continues to be extended parameters to IPv6 nodes. DHCPv6 continues to be extended and
and improved through new options, protocols or message processing improved through new options, protocols, and message processing
mechanisms. mechanisms.
Although DHCPv6 provides more and more comprehensive functionalities Although DHCPv6 provides more and more comprehensive functionalities
and DHCPv6 server software also provides extension interfaces to and DHCPv6 server software also provides extension interfaces to
allow administrators to alter and customize the way how they handle allow administrators to alter and customize the way how they handle
and respond to DHCPv6 messages, there is still a lack of a general and respond to DHCPv6 messages, there is still a lack of
insight into where and how to conduct extensions in DHCPv6 comprehensive insight into where and how to conduct extensions in
effectively. The extensions to DHCPv6 can be various according to DHCPv6 effectively. The extensions to DHCPv6 can be various
multiple requirements. The goal of multi-requirement extensions for according to multiple and varied requirements. The goal of multi-
DHCPv6 is to use simple interfaces to define and support more requirement extensions for DHCPv6 is to use simple interfaces to
extensions without changing the basic design of DHCPv6. Therefore, a define and support more extensions without changing the basic design
detailed analysis is required to clarify the problems, design of DHCPv6. Therefore, a detailed analysis is required to clarify the
principles, and extract and unify the design specifications to help problems, design principles, and extract and unify the design
better solve the multi-requirement extension problems. specifications to help better solve the multi-requirement extension
problems.
In summary, multi-requirement extensions for DHCPv6 can be conducted In summary, multi-requirement extensions for DHCPv6 can be conducted
to support the administrator's self-defined functionalities. As to support the administrator's self-defined functionalities. As
DHCPv6 is an important and useful protocol related to IPv6 addresses DHCPv6 is an essential and useful protocol related to IPv6 addresses
generation, it can provide more extended and flexible functionalities generation, it can provide more extended and flexible features to
to meet administrators' requirements. According to well-designed meet administrators' requirements. According to well-designed
principles, extended interfaces can be defined to support more self- principles, extended interfaces can be defined to support more self-
defined multi-requirement extensions without sacrificing the defined multi-requirement extensions without sacrificing the
stability of DHCPv6. stability of DHCPv6.
Some people would suggest administrators modify the open-source DHCP Some people would suggest administrators modify the open-source DHCP
servers to solve their problems. However, a great amount of time servers to solve their problems. However, a considerable amount of
will be taken to understand the open source DHCP server codes, not to time will be taken to understand the open-source DHCP server codes,
say the consuming time debugging the bugs, failures or system crash not to say the consuming time debugging the bugs, failures or system
caused by modifying the complicated modules. Another problem is that crash caused by modifying the complicated modules. Another problem
as the open source software evolves, the source codes of the server is that as the open-source software evolves, the source codes of the
software may change (new functionalities or fixing bugs). Users may server software may change (new functionalities or fixing bugs).
need to re-write their codes once the new version of open-source Users may need to re-write their codes once the latest version of
server software comes out [kea_dhcp_hook_developers_guide] . Hence, open-source server software comes out
the multi-requirement extensions for DHCPv6 to solve administrators' [kea_dhcp_hook_developers_guide]. Hence, the multi-requirement
specific problems are very necessary and significant. extensions for DHCPv6 to solve administrators' specific problems are
essential and significant.
This document provides a survey of current extension practices and This document provides a survey of current extension practices and
typical DHCP server software on extensions and gives DHCPv6 extension typical DHCP server software on extensions and gives DHCPv6 extension
considerations by defining a DHCPv6 general model, discussing the considerations by defining a DHCPv6 general model, discussing the
extension problems, and 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. Newly-defined options carry specific this way. New-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
specific goals and provide better services, e.g., specific goals and provide better services, e.g.,
authentication [RFC7037]. authentication [RFC7037].
3.2. Current DHCPv6 Server Software Cases 3.2. Current DHCPv6 Server Software Cases
A lot of commercial and open source DHCP servers exist, including A lot of commercial and open source DHCP servers exist, including
Cisco Prime Network Registrar [CPNR], Microsoft DHCP Cisco Prime Network Registrar [CPNR], Microsoft DHCP
[Microsoft_DHCP], VitalQIP [VitalQIP], Nominum DHCP [Nominum_DHCP], [Microsoft_DHCP], VitalQIP [VitalQIP], Nominum DHCP [Nominum_DHCP],
ISC DHCP [ISC_DHCP], Kea DHCP [Kea_DHCP], FreeRADIUS DHCP ISC DHCP [ISC_DHCP], Kea DHCP [Kea_DHCP], FreeRADIUS DHCP
[FreeRADIUS_DHCP], WIDE DHCPv6 [WIDE_DHCPv6], and DHCP Broadband [FreeRADIUS_DHCP], WIDE DHCPv6 [WIDE_DHCPv6], and DHCP Broadband
[DHCP_Broadband]. Commercial and open source DHCPv6 software often [DHCP_Broadband]. Commercial and open-source DHCPv6 software often
considers the extensions of DHCPv6 servers because they cannot always considers the extensions of DHCPv6 servers because they cannot always
meet the requirements that the administrators want. In this section, meet the requirements that the administrators want. In this section,
we introduce two typical DHCPv6 servers: Cisco Prime Network we introduce two typical DHCPv6 servers: Cisco Prime Network
Registrar and Kea DHCP. Registrar and Kea DHCP.
3.2.1. Cisco Prime Network Registrar DHCP Server Extension APIs 3.2.1. Cisco Prime Network Registrar DHCP Server Extension APIs
Cisco Prime Network Registrar (CPNR) [CPNR] is an appliance which Cisco Prime Network Registrar (CPNR) [CPNR] is an appliance which
provides integrated Domain Name Server, DHCP, and IP Address provides integrated Domain Name Server, DHCP, and IP Address
Management services for IPv4 and IPv6. At the same time, CPNR DHCP Management services for IPv4 and IPv6. At the same time, CPNR DHCP
server provides extension APIs and allows administrators to write server provides extension APIs and allows administrators to write
extensions and functions to alter and customize how it handles and extensions and functions to alter and customize how it handles and
responds to DHCP requests. A network operator usually decides what responds to DHCP requests. A network operator usually decides what
packet process to modify, how to modify, and which extension point to packet process to modify, how to modify, and which extension point to
attach the extension. Then the network operator just writes the attach the extension. Then the network operator writes the extension
extension and adds the well-written extension to the extension point and adds the well-written extension to the extension point of the
of the DHCP server. Finally, the network operator reloads the DHCP DHCP server. Finally, the network operator reloads the DHCP server
server and debugs whether the server runs as it expects. and debugs whether the server runs as it expects.
3.2.2. Kea DHCP Hook Mechanisms 3.2.2. Kea DHCP Hook Mechanisms
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. Extension Points 4. Extension Discussion
This section elaborates multi-requirement extensions for DHCPv6. This section elaborates multi-requirement extensions for DHCPv6.
Section 4.1 describes the general model of DHCPv6, while Section 4.2 Section 4.1 describes the general model of DHCPv6, while Section 4.2
analyzes the extension points and requirements. analyzes the extension points and requirements.
4.1. DHCPv6 General Model 4.1. DHCPv6 General Model
Figure 1 summarizes the DHCPv6 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.
skipping to change at page 5, line 41 skipping to change at page 5, line 43
| | 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: DHCPv6 general model and its possible extensions. Figure 1: DHCPv6 general model and its possible extensions.
4.2. Extension Discussion 4.2. Extension Points
4.2.1. Messages 4.2.1. Messages
On the one hand, new messages can be designed and added to DHCPv6 On the one hand, new messages can be designed and added to the DHCPv6
protocol to enrich its funtionalities. For example, [RFC5007] protocol to enrich its functionalities. For example, [RFC5007]
defines new leasequery messages to allow a requestor to retrive defines new leasequery messages to allow a requestor to retrieve
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 the DHCP protocol. [RFC7819] and [RFC7824]
the privacy issues associated with the use of DHCPv4 and DHCPv6, describe the privacy issues associated with the use of DHCPv4 and
respectively. DHCPv6 does not provide the privacy protection on DHCPv6, respectively. DHCPv6 does not provide 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 exchanges between DHCPv6 entities.
entities.
4.2.2. Options 4.2.2. Options
DHCPv6 allows defining options to transmit parameters between DHCPv6 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 DHCPv6 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, the 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 the sub-options of the
specific option to serve their private purposes. The content of the vendor-specific information option to serve their private purposes.
self-defined options may come from two sources: devices and users. The content of the self-defined options may come from two sources:
If the content of self-defined options comes from users, two methods devices and users. If the content of self-defined options comes from
can be used to solve the problem. The first one is that the clients users, two methods can be used to solve the problem. The first one
provide related interfaces to receive such information, which is is that the clients provide related interfaces to receive such
currently merely supported. The second one is that DHCPv6 relays information, which is currently merely supported. The second one is
obtain such information and add it into the clients' requests. But that DHCPv6 relays obtain such information and add it to the clients'
this always depends on other protocols to allow DHCPv6 relays to get requests. But this always depends on other protocols to allow DHCPv6
the information first. relays to get the information first.
4.2.3. Message Processing Functions 4.2.3. Message Processing Functions
Although current commercial or open-source DHCP server software Although current commercial or open-source DHCP server software
provides comprehensive functionalities, they still cannot meet all provides comprehensive functionalities, they still cannot meet all
customers' requirements of processing DHCP requests. Therefore, they customers' requirements of processing DHCP requests. Therefore, they
will provide interfaces that customers can use to write their will offer interfaces that customers can use to write their specific
specific extensions to affect the way how DHCP servers handle and extensions to affect the way how DHCP servers handle and respond to
respond to DHCP requests. For example, not all networks prefer to DHCP requests. For example, not all networks prefer to use DHCPv6
use DHCPv6 servers to assign the privacy-preserving random-form servers to assign the privacy-preserving random-form addresses
addresses generated by some fixed address generation mechanism to generated by some fixed address generation mechanism to DHCPv6
DHCPv6 clients. Thus, network operators may alter their DHCPv6 clients. Thus, network operators may alter their DHCPv6 servers
servers through the given extensions to use their own preferred through the given extensions to use their preferred address
address generation mechanisms to assign addresses to DHCPv6 clients. generation mechanisms to assign addresses to DHCPv6 clients.
However, not all DHCP software considers this extension. However, not all DHCP software considers this extension.
4.2.4. Address Generation Mechanisms 4.2.4. Address Generation Mechanisms
Currently, the DHCPv6 servers assign addresses, prefixes and other Currently, the DHCPv6 servers assign addresses, prefixes and other
configuration options according to their configured policies. configuration options according to their configured policies.
Generally, different networks may prefer different address generation Generally, different networks may prefer different address generation
mechanisms. Several address generation mechanisms for SLAAC mechanisms. Several address generation mechanisms for SLAAC
[RFC4862] (e.g., IEEE 64-bit EUI-64 [RFC2464], Constant, semantically [RFC4862] (e.g., IEEE 64-bit EUI-64 [RFC2464], Constant, semantically
opaque [Microsoft], Temporary [RFC4941], and Stable, semantically opaque [Microsoft], Temporary [RFC4941], and Stable, semantically
skipping to change at page 7, line 36 skipping to change at page 7, line 38
modification, and message definition between DHCPv6 entities and modification, and message definition between DHCPv6 entities and
third-party entities. third-party entities.
Currently, many DHCPv6 servers provide administrative mechanisms, Currently, many DHCPv6 servers provide administrative mechanisms,
e.g., host reservation and client classification. Host reservation e.g., host reservation and client classification. Host reservation
is 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 More complicated extensions of DHCPv6 are needed to meet specific
are needed. For example, considering such a requirement that DHCP requirements. 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
defining and using sub-options of vendor specific information option. defining and using sub-options of vendor-specific information option.
The second one is that servers use user identifiers to generate IP The second one is that servers use user identifiers to generate IP
addresses. To achieve this goal, extension mechanisms provided by addresses. To achieve this goal, extension mechanisms provided by
the server software such as extension points in CPNR [CPNR] and hook the server software such as extension points in CPNR [CPNR] and hook
mechanisms in Kea DHCP [Kea_DHCP] can be used. mechanisms in Kea DHCP [Kea_DHCP] can be used.
Some extensions for DHCPv6 may need the support of third-party Some extensions for DHCPv6 may need the support of third-party
entities. For example, [RFC7037] introduces RADIUS entities into the entities. For example, [RFC7037] introduces RADIUS entities into the
message exchanges between DHCPv6 entities for better service message exchanges between DHCPv6 entities for better service
provision. In fact, the authentication in [RFC7037] can be also used provision. The authentication in [RFC7037] can also be used to meet
to meet the accountability requirement mentioned above because it is the accountability requirement mentioned above because it is
important to authenticate users first before assigning IP addresses important to authenticate users first before assigning IP addresses
generated from user identifiers. Usually, this kind of extension generated from user identifiers. Usually, this kind of extension
requires the definition of messages communicated between DHCP requires the definition of messages communicated between DHCP
entities and third-party entities, e.g., active leasequery [RFC7653]. entities and third-party entities, e.g., active leasequery [RFC7653].
IPv6 addresses are related to manageability, security, traceability, IPv6 addresses are related to manageability, security, traceability,
and accountability of networks. As DHCPv6 assigns IPv6 addresses to and accountability of networks. As DHCPv6 assigns IPv6 addresses to
IPv6 nodes, it is important that DHCPv6 provides interfaces to allow IPv6 nodes, it is important that DHCPv6 provides interfaces to allow
administrative domains to conduct extensions to meet their multi- administrative domains to conduct extensions to meet their multi-
requirements. requirements.
skipping to change at page 8, line 31 skipping to change at page 8, line 34
This document does not include an IANA request. This document does not include an IANA request.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng
Jiang, and Jinmei Tatuya for their comments and suggestions that Jiang, and Jinmei Tatuya for their comments and suggestions that
improved the [draft-ren-dhc-mredhcpv6]. Some ideas and thoughts of improved the [draft-ren-dhc-mredhcpv6]. Some ideas and thoughts of
[draft-ren-dhc-mredhcpv6] are contained in this document. [draft-ren-dhc-mredhcpv6] are contained in this document.
9. Normative References 9. References
9.1. Normative References
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
9.2. Informative References
[CPNR] Cisco, "Cisco Prime Network Registrar", 2018, [CPNR] Cisco, "Cisco Prime Network Registrar", 2018,
<https://www.cisco.com/c/en/us/products/cloud-systems- <https://www.cisco.com/c/en/us/products/cloud-systems-
management/prime-network-registrar/index.html>. management/prime-network-registrar/index.html>.
[DHCP_Broadband] [DHCP_Broadband]
Weird Solutions, "DHCP Broadband", 2018, Weird Solutions, "DHCP Broadband", 2018,
<https://www.weird-solutions.com/carrier-solutions/dhcp- <https://www.weird-solutions.com/carrier-solutions/dhcp-
broadband>. broadband>.
skipping to change at page 10, line 5 skipping to change at page 10, line 25
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003, DOI 10.17487/RFC3646, December 2003,
<https://www.rfc-editor.org/info/rfc3646>. <https://www.rfc-editor.org/info/rfc3646>.
[RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
Configuration Option for DHCPv6", RFC 4075, Configuration Option for DHCPv6", RFC 4075,
DOI 10.17487/RFC4075, May 2005, DOI 10.17487/RFC4075, May 2005,
<https://www.rfc-editor.org/info/rfc4075>. <https://www.rfc-editor.org/info/rfc4075>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007,
September 2007, <https://www.rfc-editor.org/info/rfc5007>. September 2007, <https://www.rfc-editor.org/info/rfc5007>.
[RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 [RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6
skipping to change at page 10, line 42 skipping to change at page 11, line 10
[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy [RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy
Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819,
April 2016, <https://www.rfc-editor.org/info/rfc7819>. April 2016, <https://www.rfc-editor.org/info/rfc7819>.
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
Considerations for DHCPv6", RFC 7824, Considerations for DHCPv6", RFC 7824,
DOI 10.17487/RFC7824, May 2016, DOI 10.17487/RFC7824, May 2016,
<https://www.rfc-editor.org/info/rfc7824>. <https://www.rfc-editor.org/info/rfc7824>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[VitalQIP] [VitalQIP]
Nokia, "Nokia VitalQIP", 2017, Nokia, "Nokia VitalQIP", 2017,
<https://networks.nokia.com/products/vitalqip-ip-address- <https://networks.nokia.com/products/vitalqip-ip-address-
management>. management>.
[WIDE_DHCPv6] [WIDE_DHCPv6]
KAME project, "WIDE DHCPv6", 2008, KAME project, "WIDE DHCPv6", 2008,
<http://ipv6int.net/software/wide_dhcpv6.html>. <http://ipv6int.net/software/wide_dhcpv6.html>.
Authors' Addresses Authors' Addresses
 End of changes. 29 change blocks. 
89 lines changed or deleted 96 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/