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) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . | 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) | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . | | +-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . 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, . [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, DOI 10.17487/RFC3041, January 2001, . [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, . [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, . [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, . [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, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . 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, . [RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li, "Duplicate Address Detection Proxy", RFC 6957, DOI 10.17487/RFC6957, June 2013, . [RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 Relay Agent", RFC 7037, DOI 10.17487/RFC7037, October 2013, . [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, . [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, October 2015, . [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Considerations for DHCPv6", RFC 7824, DOI 10.17487/RFC7824, May 2016, . [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, . [secure_dhcpv6] Jiang, S., "Secure DHCPv6", 2016. 10.2. Informative References [DOMINATION] Mad Dominators, Inc., "Ultimate Plan for Taking Over the World", 1984, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . 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, . [RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DOI 10.17487/RFC7749, February 2016, . 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]