< draft-ietf-dhc-problem-statement-of-mredhcpv6-07.txt   draft-ietf-dhc-problem-statement-of-mredhcpv6-08.txt >
Dynamic Host Configuration (DHC) G. Ren Dynamic Host Configuration (DHC) G.R. Ren
Internet-Draft L. He Internet-Draft L.H. He
Intended status: Informational Y. Liu Intended status: Informational Y.L. Liu
Expires: November 19, 2021 Tsinghua University Expires: 23 May 2022 Tsinghua University
May 18, 2021 19 November 2021
DHCPv6 Extension Practices and Considerations DHCPv6 Extension Practices and Considerations
draft-ietf-dhc-problem-statement-of-mredhcpv6-07 draft-ietf-dhc-problem-statement-of-mredhcpv6-08
Abstract Abstract
IP addresses assume an increasing number of attributes as IP addresses assume an increasing number of attributes as
communication identifiers to meet different requirements. Privacy communication identifiers to meet different requirements. Privacy
protection, accountability, security, and manageability of networks protection, accountability, security, and manageability of networks
can be supported by extending the DHCPv6 protocol as required. This can be supported by extending the DHCPv6 protocol as required. This
document provides current extension practices and typical DHCPv6 document provides current extension practices and typical DHCPv6
server software in terms of extensions, defines a general model of server software in terms of extensions, defines a general model of
DHCPv6, discusses some extension points, and presents extension DHCPv6, discusses some extension points, and presents extension
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 November 19, 2021. This Internet-Draft will expire on 23 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Current Extension Practices . . . . . . . . . . . . . . . . . 4 3. Current Extension Practices . . . . . . . . . . . . . . . . . 4
3.1. Standardized and Non-standardized DHCPv6 Extension Cases 4 3.1. Standardized and Non-standardized DHCPv6 Extension
Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Current DHCPv6 Server Software Cases . . . . . . . . . . 4 3.2. Current DHCPv6 Server Software Cases . . . . . . . . . . 4
4. Extension Discussion . . . . . . . . . . . . . . . . . . . . 5 4. Extension Discussion . . . . . . . . . . . . . . . . . . . . 5
4.1. DHCPv6 General Model . . . . . . . . . . . . . . . . . . 5 4.1. DHCPv6 General Model . . . . . . . . . . . . . . . . . . 5
4.2. Extension Points . . . . . . . . . . . . . . . . . . . . 5 4.2. Extension Points . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.3. Message Processing Functions . . . . . . . . . . . . 6 4.2.3. Message Processing Functions . . . . . . . . . . . . 7
4.2.4. Address Generation Mechanisms . . . . . . . . . . . . 7 4.2.4. Address Generation Mechanisms . . . . . . . . . . . . 7
4.3. Extension Principles . . . . . . . . . . . . . . . . . . 8 4.3. Extension Principles . . . . . . . . . . . . . . . . . . 8
5. Extension Cases . . . . . . . . . . . . . . . . . . . . . . . 8 5. Extension Cases . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. Software Configurations . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.2. Option Definition and Server Modification . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Message Definition . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
IP addresses play an essential role in communication over the IP addresses play an essential role in communication over the
Internet. Their generation and assignment are also closely linked to Internet. Their generation and assignment are also closely linked to
the privacy protection, accountability, security, and manageability the privacy protection, accountability, security, and manageability
of the network [draft-gont-v6ops-ipv6-addressing-considerations]. of the network [I-D.gont-v6ops-ipv6-addressing-considerations]. The
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC8415] Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC8415] is an
is an important network protocol that can be used to dynamically important network protocol that can be used to dynamically provide
provide IPv6 addresses and other network configuration parameters to IPv6 addresses and other network configuration parameters to IPv6
IPv6 nodes. DHCPv6 can be continuously extended and improved through nodes. DHCPv6 can be continuously extended and improved through new
new options DHCPv6 can be continually extended and improved with new
options, protocols, and message processing mechanisms. options, protocols, and message processing mechanisms.
IP addresses assume an increasing number of properties as IP addresses assume an increasing number of properties as
communication identifiers to meet different requirements. For communication identifiers to meet different requirements. For
example, APNA [APNA] and PAVI [PAVI] use addresses to enhance source example, APNA [APNA] and PAVI [PAVI] use addresses to enhance source
responsibility and privacy protection. These requirements often need responsibility and privacy protection. These requirements often need
to be reflected by IP address assignment protocols such as DHCPv6. to be reflected by IP address assignment protocols such as DHCPv6.
Therefore, extensions to DHCPv6 are made to meet a wide variety of Therefore, extensions to DHCPv6 are made to meet a wide variety of
requirements, which is referred to as multi-requirement extensions to requirements, which is referred to as multi-requirement extensions to
DHCPv6. However, it is not easy to extend DHCPv6 to meet a variety DHCPv6. However, it is not easy to extend DHCPv6 to meet a variety
of requirements. Although DHCPv6 offers increasingly comprehensive of requirements. Although DHCPv6 offers increasingly comprehensive
functionality and DHCPv6 server software provides extension functionality and DHCPv6 server software provides extension
interfaces that allow administrators to change and customize the way interfaces that allow administrators to change and customize the way
they process and respond to DHCPv6 messages, there is still a lack of they process and respond to DHCPv6 messages, there is still a lack of
comprehensive understanding of where and how to extend in DHCPv6 comprehensive understanding of where and how to extend in DHCPv6
effectively. Therefore, a detailed analysis is needed to clarify the effectively. Therefore, a detailed analysis is needed to clarify the
issues and design principles and extract and unify design issues and design principles and extract and unify design
specifications to help better address the multi-demand scaling specifications to help better address the multi-demand scaling
problem. problem.
In summary, multi-requirement extensions for DHCPv6 can be made to In summary, with the large-scale deployment and application of IPv6,
support administrator-defined features or to meet application new scenarios such as Data Center Network, Internet of Things,
requirements. Since DHCPv6 is an important and useful protocol Industrial Internet, and Integrated satellite-terrestrial networks
related to IPv6 address generation, it can provide more extensions put forward new requirements for IP address allocation, e.g., the
and flexible features to meet administrator or application scale of address allocation, the efficiency of address update and
requirements. Based on careful design principles, interfaces can be 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 defined to support more customized multi-requirement extensions
without sacrificing the stability of DHCPv6. without sacrificing the stability of DHCPv6.
Some people would suggest that administrators modify the open-source Some people would suggest that administrators modify the open-source
DHCPv6 server to solve their problems. However, it takes DHCPv6 server to solve their problems. However, it takes
considerable time to understand the code of an open-source DHCPv6 considerable time to understand the code of an open-source DHCPv6
server, not to mention the time-consuming task of debugging errors, server, not to mention the time-consuming task of debugging errors,
failures, or system crashes caused by modifying complex modules. failures, or system crashes caused by modifying complex modules.
Another problem is that as open-source software evolves, the source Another problem is that as open-source software evolves, the source
code of the server software may change (new features or bug fixes). code of the server software may change (new features or bug fixes).
skipping to change at page 3, line 48 skipping to change at page 4, line 15
This document provides a survey of current extension practices and This document provides a survey of current extension practices and
typical DHCPv6 server softwares on extensions and gives DHCPv6 typical DHCPv6 server softwares on extensions and gives DHCPv6
extension considerations by defining a DHCPv6 general model, extension considerations by defining a DHCPv6 general model,
discussing the extension problems, and presenting extension cases. discussing the 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.
Multi-requirement extensions: According to the administrator or Multi-requirement extensions: The multi-requirement extensions for
application requirements, DHCPv6 extensions can cover several DHCPv6 is to meet new scenarios and requirements by extending
aspects, e.g., privacy protection, accountability, and security. DHCPv6 with new messages, options, message processing features, or
These extensions can be accomplished by defining new messages, address generation mechanisms.
options, message processing functions, or address generation
mechanisms for DHCPv6.
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. New-defined options carry specific
skipping to change at page 5, line 39 skipping to change at page 5, line 50
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: DHCPv6 general model and its possible extensions. Figure 1: DHCPv6 general model and its possible extensions.
4.2. Extension Points 4.2. Extension Points
4.2.1. Messages 4.2.1. Messages
On the one hand, new messages can be designed and added to the DHCPv6 On the one hand, new messages can be designed and added to the DHCPv6
protocol to enrich its functionalities. For example, [RFC5007] protocol to enrich its functionalities. For example, [RFC5007]
defines new leasequery messages to allow a requestor to retrieve 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.
[RFC5460] expands on the Leasequery protocol by defines new messages [RFC5460] expands on the Leasequery protocol by defines new messages
skipping to change at page 7, line 35 skipping to change at page 7, line 47
Moreover, several basic operations are defined to support the design Moreover, several basic operations are defined to support the design
of IPv6 addresses generation mechanisms. A new IPv6 address of IPv6 addresses generation mechanisms. A new IPv6 address
generation mechanism can be made up of the combination of the generation mechanism can be made up of the combination of the
following basic operations. Also, new basic operations can be following basic operations. Also, new basic operations can be
defined to support new functions. defined to support new functions.
Invert(x, n) invert bit n of input x. Invert(x, n) invert bit n of input x.
Insert(x, n, s) insert s after bit n of input x. Insert(x, n, s) insert s after bit n of input x.
Concatenate(x, y, ...) concatenate input [x, y, ...] sequentially. Concatenate(x, y, ...) concatenate input [x, y, ...] sequentially.
Replace(x, n, m, s) change from bit n to bit m of input x into s. Replace(x, n, m, s) change from bit n to bit m of input x into s.
Note that the length of s must be equal to Note that the length of s must be equal to
m-n+1. When n=m, change only one bit of input m-n+1. When n=m, change only one bit of input
x. x.
Truncate(x, n, m) truncate from bit n to bit m of input x as the Truncate(x, n, m) truncate from bit n to bit m of input x as the
output output
Encrypt(x, k) use some specific encryption algorithm to Encrypt(x, k) use some specific encryption algorithm to
encrypt input x with key k. Encryption encrypt input x with key k. Encryption
algorithms can be IDEA, AES, RSA, etc. algorithms can be IDEA, AES, RSA, etc.
skipping to change at page 8, line 27 skipping to change at page 8, line 41
2) Use simpler interfaces to define and support more extensions. 2) Use simpler interfaces to define and support more extensions.
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 DHCPv6 software, option definition and configurations in current DHCPv6 software, option definition and
server modification, and message definition between DHCPv6 entities server modification, and message definition between DHCPv6 entities
and third-party 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.
5.1. Software Configurations
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. For example, a client with special access rights
differentiate between different types of clients and treat them (e.g., a firewall rule that allows access based on the source's IP
accordingly in certain cases. 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.
5.2. Option Definition and Server Modification
More complicated extensions of DHCPv6 are needed to meet specific More complicated extensions of DHCPv6 are needed to meet specific
requirements. For example, considering such a requirement that requirements. For example, considering such a requirement that
DHCPv6 servers assign IPv6 addresses generated by user identifiers to DHCPv6 servers assign IPv6 addresses generated by user identifiers to
the clients in a network to hold users accountable, two extensions the clients in a network to hold users accountable, two extensions
should be fulfilled to meet this requirement. The first one is that should be fulfilled to meet this requirement. The first one is that
clients send their user identifiers to servers. This can be achieved clients send their user identifiers to servers. This can be achieved
by defining and using sub-options of vendor-specific information by defining and using sub-options of vendor-specific information
option. The second one is that servers use user identifiers to option. The second one is that servers use user identifiers to
generate IP addresses. To achieve this goal, extension mechanisms generate IP addresses. To achieve this goal, extension mechanisms
provided by the server software such as extension points in CPNR provided by the server software such as extension points in CPNR
[CPNR] and hook mechanisms in Kea DHCP [Kea_DHCP] can be used. [CPNR] and hook mechanisms in Kea DHCP [Kea_DHCP] can be used.
5.3. Message Definition
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. The authentication in [RFC7037] can also be used to meet provision. The authentication in [RFC7037] can also be used 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 DHCPv6 requires the definition of messages communicated between DHCPv6
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,
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 6. Security Considerations
Security issues related with DHCPv6 are described in Section 22 of Security issues related with DHCPv6 are described in Section 22 of
[RFC8415]. [RFC8415].
7. IANA Considerations 7. IANA Considerations
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 [I-D.ren-dhc-mredhcpv6]. Some ideas and thoughts of
[draft-ren-dhc-mredhcpv6] are contained in this document. [I-D.ren-dhc-mredhcpv6] are contained in this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
9.2. Informative References 9.2. Informative References
[APNA] Lee, T., Pappas, C., Barrera, D., Szalachowski, P., and A. [APNA] Lee, T.L., Pappas, C.P., Barrera, D.B., Szalachowski,
Perrig, "Source Accountability with Domain-brokered P.S., and A.P. Perrig, "Source Accountability with Domain-
Privacy", December 2016. brokered Privacy", December 2016.
[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>.
[draft-gont-v6ops-ipv6-addressing-considerations]
Gont, F. and G. Gont, "IPv6 Addressing Considerations",
February 2021.
[draft-ren-dhc-mredhcpv6]
Ren, G., He, L., and Y. Liu, "Multi-requirement Extensions
for Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", March 2017.
[FreeRADIUS_DHCP] [FreeRADIUS_DHCP]
FreeRADIUS, "FreeRADIUS DHCP", 2017, FreeRADIUS, "FreeRADIUS DHCP", 2017,
<https://wiki.freeradius.org/features/DHCP>. <https://wiki.freeradius.org/features/DHCP>.
[GAGMS] Liu, Y., He, L., and G. Ren, "GAGMS: A Requirement-Driven [GAGMS] Liu, Y.L., He, L.H., and G.R. Ren, "GAGMS: A Requirement-
General Address Generation and Management System", Driven General Address Generation and Management System",
November 2017. November 2017.
[ISC_DHCP] [I-D.gont-v6ops-ipv6-addressing-considerations]
Internet System Consortium, "ISC DHCP", 2018, Gont, F.G. and G.G. Gont, "IPv6 Addressing
Considerations", February 2021.
[I-D.jia-intarea-scenarios-problems-addressing]
Jia, Y., Trossen, D., Iannone, L., Shenoy, N., Mendes, P.,
and P. Liu, "Challenging Scenarios and Problems in
Internet Addressing", Work in Progress, Internet-Draft,
draft-jia-intarea-scenarios-problems-addressing-02, 23
October 2021, <https://www.ietf.org/archive/id/draft-jia-
intarea-scenarios-problems-addressing-02.txt>.
[I-D.lhan-problems-requirements-satellite-net]
Han, L. and R. Li, "Problems and Requirements of Satellite
Constellation for Internet", Work in Progress, Internet-
Draft, draft-lhan-problems-requirements-satellite-net-01,
19 October 2021, <https://www.ietf.org/archive/id/draft-
lhan-problems-requirements-satellite-net-01.txt>.
[I-D.ren-dhc-mredhcpv6]
Ren, G.R., He, L.H., and Y.L. Liu, "Multi-requirement
Extensions for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", March 2017.
[ISC_DHCP] Internet System Consortium, "ISC DHCP", 2018,
<http://www.isc.org/downloads/dhcp/>. <http://www.isc.org/downloads/dhcp/>.
[Kea_DHCP] [Kea_DHCP] Internet System Consortium, "Kea DHCP", 2018,
Internet System Consortium, "Kea DHCP", 2018,
<https://www.isc.org/kea/>. <https://www.isc.org/kea/>.
[kea_dhcp_hook_developers_guide] [kea_dhcp_hook_developers_guide]
Internet Systems Consortium, "Hook Developer's Guide", Internet Systems Consortium, "Hook Developer's Guide",
2018, <https://jenkins.isc.org/job/Kea_doc/doxygen/df/d46/ 2018, <https://jenkins.isc.org/job/Kea_doc/doxygen/df/d46/
hooksdgDevelopersGuide.html>. hooksdgDevelopersGuide.html>.
[Microsoft] [Microsoft]
Microsoft, "IPv6 interface identifiers", 2013, <https://ww Microsoft, "IPv6 interface identifiers", 2013, <https://ww
w.microsoft.com/resources/documentation/windows/xp/all/ w.microsoft.com/resources/documentation/windows/xp/all/
skipping to change at page 11, line 11 skipping to change at page 12, line 16
Microsoft, "Microsoft DHCP", 2008, Microsoft, "Microsoft DHCP", 2008,
<https://technet.microsoft.com/en-us/library/ <https://technet.microsoft.com/en-us/library/
cc896553(v=ws.10).aspx>. cc896553(v=ws.10).aspx>.
[Nominum_DHCP] [Nominum_DHCP]
Nominum, "Nominum DHCP", 2012, Nominum, "Nominum DHCP", 2012,
<https://www.nominum.com/press_item/nominum-releases-new- <https://www.nominum.com/press_item/nominum-releases-new-
version-of-carrier-grade-dhcp-software-for-telecom- version-of-carrier-grade-dhcp-software-for-telecom-
providers/>. providers/>.
[PAVI] He, L., Ren, G., Liu, Y., and J. Yang, "PAVI: [PAVI] He, L.H., Ren, G.R., Liu, Y.L., and J.Y. Yang, "PAVI:
Bootstrapping Accountability and Privacy to IPv6 Bootstrapping Accountability and Privacy to IPv6
Internet", April 2021. Internet", April 2021.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>. <https://www.rfc-editor.org/info/rfc2464>.
[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,
skipping to change at page 13, line 25 skipping to change at page 14, line 35
[RFC8156] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Protocol", [RFC8156] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Protocol",
RFC 8156, DOI 10.17487/RFC8156, June 2017, RFC 8156, DOI 10.17487/RFC8156, June 2017,
<https://www.rfc-editor.org/info/rfc8156>. <https://www.rfc-editor.org/info/rfc8156>.
[RFC8539] Farrer, I., Sun, Q., Cui, Y., and L. Sun, "Softwire [RFC8539] Farrer, I., Sun, Q., Cui, Y., and L. Sun, "Softwire
Provisioning Using DHCPv4 over DHCPv6", RFC 8539, Provisioning Using DHCPv4 over DHCPv6", RFC 8539,
DOI 10.17487/RFC8539, March 2019, DOI 10.17487/RFC8539, March 2019,
<https://www.rfc-editor.org/info/rfc8539>. <https://www.rfc-editor.org/info/rfc8539>.
[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
Gang Ren Gang Ren
Tsinghua University Tsinghua University
Beijing 100084 Beijing
P.R.China
Phone: +86-010 6260 3227 Phone: +86-010 6260 3227
Email: rengang@cernet.edu.cn Email: rengang@cernet.edu.cn
Lin He Lin He
Tsinghua University Tsinghua University
Beijing 100084 Beijing
P.R.China
Email: he-lin@tsinghua.edu.cn
Email: he-l14@mails.tsinghua.edu.cn
Ying Liu Ying Liu
Tsinghua University Tsinghua University
Beijing 100084 Beijing
P.R.China
Email: liuying@cernet.edu.cn Email: liuying@cernet.edu.cn
 End of changes. 32 change blocks. 
88 lines changed or deleted 124 lines changed or added

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