Internet Engineering Task Force G. Ren
Internet-Draft L. He
Intended status: Standards Track Y. Liu
Expires: September 14, 2017 Tsinghua University
March 13, 2017
Multi-requirement Extensions for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)
draft-ren-dhc-mredhcpv6-00
Abstract
This memo provides multi-requirement extensions for DHCPv6, which
allow hosts to generate or fetch addresses according to the user or
network requirements, and DHCP servers to centrally manage all types
of addresses including SLAAC-configured addresses, DHCPv6-configured
addresses, and manual-configured addresses. Moreover, a general
extension for address generation is designed to allow multiple types
of requirements to be introduced into the DHCPv6 exchanges.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017.
Copyright Notice
Copyright (c) 2017 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
(http://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
Ren, et al. Expires September 14, 2017 [Page 1]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Address Configuration Methods . . . . . . . . . . . . . . 4
3.2. Address Generation Mechanisms . . . . . . . . . . . . . . 4
3.3. Determinants of IPv6 Address Allocations . . . . . . . . 5
3.3.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.2. DHCPv6 Servers . . . . . . . . . . . . . . . . . . . 5
3.3.3. Hosts . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Address-Related Network Entities . . . . . . . . . . . . 5
3.5. Current Problems . . . . . . . . . . . . . . . . . . . . 6
3.5.1. Mixed Operation Problem . . . . . . . . . . . . . . . 6
3.5.2. Synchronization Problem . . . . . . . . . . . . . . . 6
3.5.3. Efficiency Problem . . . . . . . . . . . . . . . . . 7
3.5.4. General Model Problem . . . . . . . . . . . . . . . . 7
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 7
5. General Structures . . . . . . . . . . . . . . . . . . . . . 8
5.1. General Address Generation Type . . . . . . . . . . . . . 8
5.2. Uniform Address Storage Structure . . . . . . . . . . . . 8
6. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Sub-solution for DHCPv6 . . . . . . . . . . . . . . . . . 9
6.1.1. Extension of DHCPv6 Options . . . . . . . . . . . . . 9
6.1.1.1. Address Generation Mechanism Type Option . . . . 9
6.1.1.2. Address Generation Requiring Parameters Option . 11
6.1.2. Extension of DHCPv6 Exchange Process . . . . . . . . 12
6.1.2.1. Overview . . . . . . . . . . . . . . . . . . . . 12
6.1.2.2. Detailed Exchanges . . . . . . . . . . . . . . . 13
6.1.3. Extension of External Service Result Fetching Process 14
6.1.3.1. External Service Request Message . . . . . . . . 16
6.1.3.2. External Service Reply Message . . . . . . . . . 16
6.2. Sub-solution for SLAAC . . . . . . . . . . . . . . . . . 16
6.2.1. Extension of RA Options . . . . . . . . . . . . . . . 16
6.2.1.1. Modified Prefix Information Option Format . . . . 16
6.2.2. Extension of Hosts . . . . . . . . . . . . . . . . . 17
6.2.3. Central Management of SLAAC-configured Address . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Ren, et al. Expires September 14, 2017 [Page 2]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
There are two address auto-configuration methods in IPv6: Stateless
Address Autoconfiguration (SLAAC) [RFC4862], and the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. Several address
generation mechanisms have been proposed, including IEEE EUI-64
[RFC2464], CGAs [RFC3972], Temporary [RFC4941], and Stable, privacy
[RFC7217]. The many types of IPv6 address generation and
configuration methods available have brought about flexibility and
diversity.
However, the current IPv6 address assignment and management are still
confronted with certain problems, including a mixed operation problem
of multiple IPv6 address generation mechanisms, a synchronization
problem with a change in IPv6 addresses, an efficiency problem of
processing large-scale concurrent IPv6 address requests, and a
general model problem in introducing external services into the
address assignment process.
Faced with various network requirements, various entities that prefer
to remain up to date on all types of addresses, and various
extensions for external services, it is important to balance the
flexibility of address generation and configuration, user privacy,
and network manageability. To solve the four problems above, the
multi-requirement extensions for DHCPv6 are proposed, which can be
achieved by extending DHCPv6 under the premise of changing the
current protocols as little as possible.
This memo provides multi-requirement extensions for DHCPv6, which
allow hosts to generate addresses through SLAAC or fetch addresses
assigned from DHCPv6 servers according to the user or network
requirements. At the same time, the extensions allow DHCP servers to
centrally manage all kinds of addresses including SLAAC-configured
addresses, DHCPv6-configured addresses, and manual-configured
addresses. Moreover, a general extension for address generation is
designed to allow multiple types of requirements to be introduced
into the DHCPv6 exchanges.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
memo are to be interpreted as described in [RFC2119].
Ren, et al. Expires September 14, 2017 [Page 3]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
Familiarity with DHCPv6 and its terminology, as defined in [RFC3315],
is assumed.
Other terminology:
Requirements A functional need that a particular
design or process of the address
generation and assignment must be able
to perform.
External Services Services that are introduced into the
DHCP exchanges according to specific
requirements, such as traceback,
transition, and mobility.
External Service Client An entity requesting a specific
external service.
External service Server An entity providing a specific external
service to external service clients.
3. Problem Statement
3.1. Address Configuration Methods
SLAAC and DHCPv6 are two auto-configuration mechanisms in IPv6
[RFC2460]. SLAAC can configure hosts with one or more addresses
composed of a network prefix advertised by a local router, and an
Interface Identifier (IID) that typically embeds a hardware address
(e.g., an IEEE LAN MAC address) [RFC4291]. DHCPv6 can provide a
device with addresses assigned by a DHCPv6 server and other
configuration information carried in the options.
3.2. Address Generation Mechanisms
Several IID generation mechanisms have been proposed for
standardization, all of which have their own specific requirements.
IEEE 64-bit Extended EUI-64 [RFC2464] generates IIDs based on IEEE
802 48-bit Media Access Control (MAC) addresses quickly and
economically. Cryptographically Generated Addresses (CGAs) [RFC3972]
are another method for generating an IID, which binds a hash of the
host's public key to an IPv6 address in the SEcure Neighbor Discovery
(SEND) protocol [RFC3971]. The owners of CGAs can sign messages
using the corresponding private keys to protect their messages.
Temporary addresses defined in [RFC3041] (later made obsolete by
[RFC4941]) are randomly generated for outgoing connections to protect
the host's privacy, and are changed daily. However, temporary
addresses make it difficult to conduct network management (e.g.,
Ren, et al. Expires September 14, 2017 [Page 4]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
increase the complexity of event logging and access controls).
Therefore, [RFC7217] specifies an algorithm that generates a unique
random stable, semantically opaque IID per IPv6 link for each network
without sacrificing the security and privacy of users. The DHCPv6
variant of this method is specified in [RFC7943].
3.3. Determinants of IPv6 Address Allocations
3.3.1. Routers
The ICMPv6-based [RFC4443] Router Advertisement (RA) message
specified in Neighbor Discovery (ND) [RFC4861] contains M and A flags
that allow a host to generate or fetch different types of addresses
(SLAAC addresses and DHCPv6 addresses) when they are set. At the
same time, several routers may exist in the same network, all with
different flags and prefix settings.
3.3.2. DHCPv6 Servers
When the M flag is set, it indicates that addresses are available
through DHCPv6 service. In fact, there may be several DHCPv6 servers
in a network that can assign addresses to DHCPv6 clients. Each
DHCPv6 server can assign addresses of different types, non-temporary
and temporary, and different policies, including iterative,
identifier-based, hash, and random [RFC7824].
3.3.3. Hosts
A host can configure its addresses in the following ways:
Manual Administrators can configure static addresses for the host.
SLAAC When A flags in the prefix information options (PIOs) of an
RA message are set, a host can utilize the prefixes in the
PIOs of RA messages to generate addresses automatically.
Many different address generation mechanisms can be
utilized, including IEEE EUI-64 [RFC2464], CGA[RFC3972],
Temporary [RFC4941], and Stable, privacy[RFC7217].
3.4. Address-Related Network Entities
After address assignments, many other network service entities record
and maintain data entries related to the addresses.
Switches Switches will create entries for the
addresses in the forwarding table.
Ren, et al. Expires September 14, 2017 [Page 5]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
DHCPv6 servers DHCPv6 servers will record and maintain the
address leases for the clients.
Auditing server An auditing server will record the detailed
traffic usage of the addresses.
Gateway A gateway will use the authenticated address
list to control the host's access to the
Internet.
Other External servers Other external service servers may need to
maintain the address-related information.
3.5. Current Problems
The current IPv6 address assignment and management are still
confronted with certain problems, including mixed operation problem,
synchronization problem, efficiency problem, and general model
problem.
3.5.1. Mixed Operation Problem
The first problem is a mixed operation problem of multiple IPv6
address generation mechanisms. Currently, even one host interface
can have several addresses generated from different address
generation mechanisms. Moreover, hosts in the same network can use
different address generation mechanisms for SLAAC to obtain addresses
and/or fetch addresses assigned from DHCPv6 servers. Requirements
exist for networks to uniformly configure their address generation
mechanism. For SLAAC addresses, difficulties arise when conducting
address management and some other network services (e.g.,
authentication), because most operating systems leverage temporary
addresses, which vary over time (e.g., after one day). At the same
time, persistent connections will be cut off when the addresses vary.
To summarize, the addresses of the hosts can be generated according
to not only the user requirements but also to the network
requirements.
3.5.2. Synchronization Problem
The second problem is a synchronization problem with a change in IPv6
addresses. Many types of network function entities related to
addresses exist, as mentioned in Section 3.4. Once a host updates
its addresses, or if the address that the host is currently using is
re-assigned to another user for a particular reason (e.g., without
renewing the lease), the corresponding function entities should also
update their corresponding stored entries. [RFC7653] solves a part
of this problem by allowing other network entities to keep up with
Ren, et al. Expires September 14, 2017 [Page 6]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
the DHCPv6 leases. However, the part of the problem caused by SLAAC
and manual configurations remains unresolved.
3.5.3. Efficiency Problem
The third problem is an efficiency problem when processing large-
scale concurrent IPv6 address requests. When large-scale concurrent
IPv6 address requests exist, the routers will use more resources to
forward the multicast messages when the hosts conduct duplicate
address detection (DAD) [RFC4862]. However, when central management
is used for all types of addresses, this address management entity
can detect duplicate addresses for the hosts. It is simple to choose
between the concurrent processing mechanism of server clustering
techniques and the current DAD processing mode, which puts
significant pressure on the routers when large-scale concurrent
address requests exist.
3.5.4. General Model Problem
The fourth problem is a general model problem in introducing external
services into the address assignment process. On the one hand, IP
addresses are not only locators they are also identifiers. As
identifiers, IP addresses can be mapped to other requirement spaces
to support multiple functions, such as traceback, transition, and
mobility. On the other hand, some interoperations between DHCP
entities with external service entities are designed to provide
precise and fine-grained services. For example, IETF defines the
interoperations between DHCPv6 relays and radius servers [RFC7037] to
provide authorization and identification information between the
DHCPv6 relay agent and DHCPv6 server. In short, there are no general
uniform protocol extensions or models for introducing external
services into the address assignment process.
4. Design Goals
To solve the above problems, the solution should achieve the
following goals:
Goal 1 Addresses in a network should be generated according to the
user or network requirements. In fact, DHCPv6 servers
already assign addresses according to these requirements.
DHCPv6 servers can assign temporary or non-temporary
addresses to DHCPv6 clients. DHCPv6 also provides several
address allocation policies according to the administrative
requirements and settings, including iterative, identifier-
based, hash and random [RFC7824].
Ren, et al. Expires September 14, 2017 [Page 7]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
Goal 2 All types of addresses in a network should be within the
central management, including SLAAC-configured addresses,
DHCPv6-configured addresses, and manual-configured
addresses. Because a DHCPv6 server manages a pool of IPv6
addresses and information regarding client configuration
parameters, it will be a good option for the DHCPv6 server
to manage other types of addresses when necessary.
Goal 3 General uniform protocol extensions and models for
introducing external services into the process of address
assignment should be built.
5. General Structures
5.1. General Address Generation Type
According to Section 3.2, the general address generation types are
summarized below.
+-----------+-------------------+-----------------+
| Type | Method | Related RFC |
+-----------+-------------------+-----------------+
| 1 | IEEE EUI-64 | RFC 2464 |
| | | |
| 2 | CGAs | RFC3972 |
| | | |
| 3 | Temporary | RFC4941 |
| | | |
| 4 | Stable, privacy | RFC7217/RFC7943 |
+-----------+-------------------+-----------------+
Table 1: General address generation types
5.2. Uniform Address Storage Structure
Because DHCPv6 servers will store all kinds of address assignments,
it is necessary to design a uniform address assignment storage
structure. Several key elements have been selected to construct the
core of the address assignment storage structure.
address IPv6 address.
duid DHCP unique identifier, see Section 9 of
[RFC3315].
iaid Identity association, see Section 10 of
[RFC3315].
Ren, et al. Expires September 14, 2017 [Page 8]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
valid_lifetime Length of the lease.
expire Expiration time of the lease.
pref_lifetime Preferred lifetime.
hwaddr Hardware/MAC address.
+-------+----+----+--------------+------+-------------+------+
|address|duid|iaid|valid_lifetime|expire|pref_lifetime|hwaddr|
+-------+----+----+--------------+------+-------------+------+
For SLAAC address assignments and manual address configurations, some
information may be absent, including duid and iaid. Other
information can also be included in the uniform address storage
structure, such as the subnet identification, hostname, and lease
type.
6. Solutions
For Goal 1, mechanisms that allow SLAAC-configured addresses and
manual-configured addresses to be sent to the DHCPv6 server can be
provided. For Goal 2, extensions for both SLAAC and DHCPv6 should be
provided. More specifically, extensions of PIO are provided for
SLAAC, and new options have been designed for DHCPv6. For Goal 3, a
general address generation extension for DHCPv6 is presented herein.
6.1. Sub-solution for DHCPv6
6.1.1. Extension of DHCPv6 Options
6.1.1.1. Address Generation Mechanism Type Option
A server sends this option to inform the client of the address
generation mechanism used in the administrative domain. The format
of the Address Generation Mechanism Type (AGMT) option is as follows:
Ren, et al. Expires September 14, 2017 [Page 9]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AGMT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | reserved | param-len 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. |
. parameter 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. (variable length) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. <multiple parameters> .
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. | param-len n .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| parameter n |
. (variable length) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format description:
option-code OPTION_AGMT(TBA1).
option-len 2 + Length of following multiple parameters in
octets.
type IID generation mechanism type that the server
selects. A value of zero is assigned as the default
value.
0 Any IID generation mechanism type.
1 IEEE EUI-64.
2 CGAs.
3 Temporary addresses.
4 Stable, semantically opaque IIDs.
reserved Reserved field for future extensions. The server
MUST set this value to zero, and the client MUST
ignore its content.
Ren, et al. Expires September 14, 2017 [Page 10]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
param-len 1...n This is a 16-bit integer that specifies the length of
the following parameters in octets (not including the
parameter-length field).
parameter 1...n These UTF-8 strings are parameters needed for servers
to inform the clients according to the selected
address generation mechanisms. The strings are not
NUL-terminated.
6.1.1.2. Address Generation Requiring Parameters Option
The client sends this option to inform the server of the parameters
of the corresponding address generation mechanism. The format of the
Address Generation Requiring Parameters (AGRP) option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AGRP | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | param-len 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. parameter 1 (variable length) |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. | |
+-+-+-+-+-+-+-+-+ .
. .
. <multiple parameters> .
. .
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | param-len n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. parameter n (variable length) |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+
Format description:
option-code OPTION_AGRP(TBA2).
option-len 1 + Length of following multiple parameters in octets.
type IID generation mechanism type selected by the server.
param-len 1...n This is a 16-bit integer that specifies the length
of the following parameter in octets (not including the
parameter-length field).
Ren, et al. Expires September 14, 2017 [Page 11]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
parameter 1...n These UTF-8 strings are parameters needed for the
clients to inform the servers of according to the
selected address generation mechanism. The strings are
not NUL-terminated.
6.1.2. Extension of DHCPv6 Exchange Process
6.1.2.1. Overview
The part of the intent of this memo is to dynamically configure the
address generation mechanism. The following figure illustrates the
new DHCPv6 exchange process. Briefly, a client requests the address
generation mechanism from servers. The servers tell the client which
type of address generation mechanism to use. Some parameters can
also be sent to the servers to generate new addresses when the
clients start to request addresses.
+-------------+ +------------+ +-------------+ +---------------+
| | | | | | | |
|DHCPv6 Client| |DHCPv6 Relay| |DHCPv6 Server| |External Server|
| | | (ESC) | | | | |
+-------------+ +------------+ +-------------+ +---------------+
|Information-request| | |
|------------------>| | |
| ORO (AGMT) | | |
| | Relay-Forward | |
| |----------------->| |
| | | |
| | Relay-Reply | |
| |<-----------------| |
| Reply | | |
|<------------------| | |
| AGMT option | | |
| ORO (AGRP) | | |
| | | |
| Solicit | | |
|------------------>| | |
| AGRP option | | |
| | | |
| | External Service Request |
| |------------------+----------------->|
| | | |
| | External Service Reply |
| |<-----------------+------------------|
| | Accept/Reject |
| | | |
| | Relay-Forward | |
| |----------------->| |
Ren, et al. Expires September 14, 2017 [Page 12]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
| | | |
| | Relay-Reply | |
| |<-----------------| |
| | | |
| Advertise | | |
|<------------------| | |
| | | |
| Request | | |
|------------------>| | |
| | | |
| | Relay-Forward | |
| |----------------->| |
| | | |
| | Relay-Reply | |
| |<-----------------| |
| | | |
| Reply | | |
|<------------------| | |
| | | |
Figure 1: Extension of DHCPv6 Exchange Process
6.1.2.2. Detailed Exchanges
The detailed exchanges of the extensions specified in this memo are
as follows:
1 A client requests the AGMT option in the Option Request Option
(ORO), which is carried in an Information-request message.
2 The relay agent forwards the Information-request message to the
servers.
3 The servers tell the client which type of address generation
mechanism to use through the AGMT option within the Reply
message. If a server requires the client to provide parameters
to generate the addresses, it requests the AGRP option in the
ORO.
4 The relay agent forwards the Reply message to the client.
5 If the address generation mechanism selected by the server does
not require the client to send other parameters, the client sends
a normal Solicit message. Otherwise, the client sends a Solicit
message with an AGRP option.
Ren, et al. Expires September 14, 2017 [Page 13]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
6 When the relay agent receives a Solicit message, it checks whether
the selected method requires communication with external servers.
If not, it forwards the message to the server. Otherwise, it
communicates with the external server to finish the related task
(e.g., authentication or authority) as an external service client
(ESC) (see Section 6.1.3). Next, it forwards the Solicit message
to the server if the communication process succeeds. Otherwise,
it drops the message.
7 If there is an AGRP option in the Solicit message, the server uses
the parameters in the AGRP option to generate an address and
sends an Advertise message with the address to the client.
Otherwise, the server handles the message based on [RFC3315].
8 The remaining steps are the same as with the original DHCPv6
process.
6.1.3. Extension of External Service Result Fetching Process
The figure below shows the communication process between a DHCPv6
relay, or server, and an ESC, which only includes two messages: an
External Service Request message and an External Service Reply
message. Notice that the ESC can be located on the same device with
the DHCPv6 relay agent or DHCPv6 server.
+-------------------+ +-----------------------+
|DHCPv6 Relay/Server| |External Service Client|
+-------+-----------+ +-----------------------+
| |
| External Service Request |
|---------------------------------->|
| |
| |
| |
| External Service Reply |
|<----------------------------------|
| |
| |
Figure 2: Extension of External Service Result Fetching Process
The format of the External Service Message is as follows:
Ren, et al. Expires September 14, 2017 [Page 14]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter 1 .
. (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. <multiple parameters> .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter n .
. (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: External Service Message Format
Format description:
msg-type The message type, including
EXTERNAL_SERVICE_REQUEST(TBA3) and
EXTERNAL_SERVICE_REPLY(TBA4).
transaction-id The transaction id copied from a Solicit message to
identify this message exchange.
type External service type.
reserved Reserved field for future extensions. The server MUST
set this value to zero, and the client/server MUST
ignore its content.
param-len 1...n This is a 16-bit integer that specifies the length
of the following parameter in octets (not including the
parameter-length field).
parameter 1...n These UTF-8 strings are parameters required for
external services. The strings are not NUL-terminated.
Ren, et al. Expires September 14, 2017 [Page 15]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
6.1.3.1. External Service Request Message
This message is used by the DHCPv6 relay or server to request an
external service at the external server. The DHCPv6 relay or server
sends this message to the ESC, which extracts the parameters in the
message to start an external service communication process. For
example, when the DHCPv6 process uses a radius server to authenticate
or authorize a client [RFC7037], the message can be used to send the
relevant parameters to the radius client.
When the DHCP relay or server creates such a message, it sets the
msg-type to EXTERNAL_SERVICE_REQUEST and the type to a specific
external service type, copies the transaction-id from the message
triggering the external service, and provides the specific parameters
required by the external service to the external service client.
6.1.3.2. External Service Reply Message
This message is used by the ESC to reply to the DHCPv6 relay or
server with the acceptance or rejection result of the external
service.
When the external service client creates the message, it sets the
msg-type to EXTERNAL_SERVICE_REPLY, copies the transaction-id and
type from the External Service Request message, and provides the
specific result parameters to the DHCPv6 relay or server.
6.2. Sub-solution for SLAAC
6.2.1. Extension of RA Options
6.2.1.1. Modified Prefix Information Option Format
To support multiple requirements in the address generation for SLAAC,
Neighbor Discovery [RFC4861] can be extended to allow a router to
advertise the default address generation mechanism for each prefix
through the addition of one octet in the format of a PIO for use in
the Router Advertisement messages. The format of the PIO is as
follows:
Ren, et al. Expires September 14, 2017 [Page 16]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mechanism Type| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the following changes over that originally
specified for Neighbor Discovery [RFC4861]:
Scheme Type 1-octet address generation mechanism type flag. When
the A flag is set, it indicates that the PIO recommends
the hosts to use the address generation mechanism
specified in the Mechanism Type and the prefix
specified in Prefix to generate the addresses.
0 Any IID generation mechanism type.
1 IEEE EUI-64.
2 CGAs.
3 Temporary.
4 Stable, privacy.
Reserved2 Reduced from a 4-octet field to a 3-octet field to
account for the addition of the above octet.
6.2.2. Extension of Hosts
The hosts should implement the standardized address generation
mechanisms mentioned in Section 5.1.
Ren, et al. Expires September 14, 2017 [Page 17]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
When a host receives RA messages containing a modified PIO, it
handles the message based on [RFC4861]. It uses the recommended
mechanism type in the PIO to generate the addresses. Note that
multiple PIOs may recommend different address generation mechanisms.
6.2.3. Central Management of SLAAC-configured Address
After finishing the address generation, a host should inform the
DHCPv6 server of its SLAAC-configured addresses or manual-configured
addresses to help the DHCPv6 server manage all types of addresses in
the network. There are several schemes to consider:
Scheme 1: Create two new messages similar to Request and Reply
messages of DHCPv6 to inform the DHCPv6 server of the SLAAC-
configured or manual-configured addresses.
Scheme 2: Use and modify a current mechanism to inform the DHCPv6
server of the addresses. For example, because every SLAAC-
configured address performs a DAD, a Neighbor Solicit message can
be modified to support this function.
7. Security Considerations
The known security vulnerabilities of the DHCPv6 protocol may apply
to its options. Security issues related with DHCPv6 are described in
Section 23 of [RFC3315].
Network administrators should be aware that certain external service
messages are encrypted, and that DHCPv6 messages are always
unencrypted. It is possible for some external service attributes to
contain sensitive or confidential information. Network
administrators are strongly advised to prevent such information from
being included in DHCPv6 messages.
[secure_dhcpv6] provides a new method for protecting end-to-end
communication using public key cryptography.
8. IANA Considerations
This memo defines two new DHCPv6 [RFC3315] messages types. The IANA
is requested to assign values for the two messages types in the
registry maintained in http://www.iana.org/assignments/
dhcpv6-parameters: The two new messages type are:
The EXTERNAL_SERVICE_REQUEST(TBA3), described in Section Figure 3.
The EXTERNAL_SERVICE_REPLY(TBA4), described in Section Figure 3.
Ren, et al. Expires September 14, 2017 [Page 18]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
This memo defines two new DHCPv6 [RFC3315] options. The IANA is
requested to assign values for the two options from the DHCPv6
Options Codes table of the DHCPv6 Parameters registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters. The two options
are:
The Address Generation Mechanism Type option (TBA1), described in
Section Section 6.1.1.1.
The Address Generation Requiring Parameters option(TBA2),
described in Section Section 6.1.1.2.
IID generation mechanism for multi-requirement extension for DHCPv6.
The values in this table are 8-bit unsigned integers. The following
initial values are assigned for IID generation mechanism for multi-
requirement extension for DHCPv6 in this memo:
Method | Value | RFCs
--------------------+---------+-----------
IEEE EUI-64 | 0x01 | this memo
CGAs | 0x02 | this memo
Temporary | 0x03 | this memo
Stable, privacy | 0x04 | this memo
9. Acknowledgements
Valuable comments from Bernie Volz are appreciated.
10. References
10.1. Normative References
[dhcp_cga]
Jiang, S., "Configuring Cryptographically Generated
Addresses (CGA) using DHCPv6", 2009.
[dhcp_slaac_problem]
Liu, B., "DHCPv6/SLAAC Interaction Problems on Address and
DNS Configuration", 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
Ren, et al. Expires September 14, 2017 [Page 19]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<http://www.rfc-editor.org/info/rfc2464>.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
DOI 10.17487/RFC3041, January 2001,
<http://www.rfc-editor.org/info/rfc3041>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<http://www.rfc-editor.org/info/rfc4429>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
Ren, et al. Expires September 14, 2017 [Page 20]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li,
"Duplicate Address Detection Proxy", RFC 6957,
DOI 10.17487/RFC6957, June 2013,
<http://www.rfc-editor.org/info/rfc6957>.
[RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6
Relay Agent", RFC 7037, DOI 10.17487/RFC7037, October
2013, <http://www.rfc-editor.org/info/rfc7037>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
[RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
October 2015, <http://www.rfc-editor.org/info/rfc7653>.
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
Considerations for DHCPv6", RFC 7824,
DOI 10.17487/RFC7824, May 2016,
<http://www.rfc-editor.org/info/rfc7824>.
[RFC7943] Gont, F. and W. Liu, "A Method for Generating Semantically
Opaque Interface Identifiers (IIDs) with the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 7943,
DOI 10.17487/RFC7943, September 2016,
<http://www.rfc-editor.org/info/rfc7943>.
[secure_dhcpv6]
Jiang, S., "Secure DHCPv6", 2016.
10.2. Informative References
[DOMINATION]
Mad Dominators, Inc., "Ultimate Plan for Taking Over the
World", 1984, <http://www.example.com/dominator.html>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.
Ren, et al. Expires September 14, 2017 [Page 21]
Internet-Draft multi-requirement extensions for DHCPv6 March 2017
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary",
RFC 7749, DOI 10.17487/RFC7749, February 2016,
<http://www.rfc-editor.org/info/rfc7749>.
Appendix A. Additional Stuff
This becomes an Appendix.
Authors' Addresses
Gang Ren
Tsinghua University
Beijing
CN
Phone: +86-010 6260 3227
Email: rengang@cernet.edu.cn
Lin He
Tsinghua University
Beijing
CN
Email: he-l14@mails.tsinghua.edu.cn
Ying Liu
Tsinghua University
Beijing
CN
Email: liuying@cernet.edu.cn
Ren, et al. Expires September 14, 2017 [Page 22]