Internet Engineering Task Force Jerome Privat, BT INTERNET-DRAFT Date: August 1999 Expires: February 2000 Double Phase DHCP Configuration Status of This Memo The document is an Internet-Draft and is in full conformance with all of the provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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 Intenet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This proposal allows host configuration to be split between two different DHCP servers, potentially under different administration. This may be useful to satisfy specific regulatory, operational or business model requirements. This draft proposes two different approaches. In one approach, a DHCP server redirects clients to a second DHCP server. In the other, a DHCP server acts as a proxy to a second server. 1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 2. DHCP Terminology o "DHCP client" A DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address. o "DHCP server" A DHCP server of "server"is an Internet host that returns configuration parameters to DHCP clients. 3. Splitting the information between two DHCP servers Our model is as follows. - Configuration information is split between two different DHCP servers, potentially under different administrative control. - One DHCP server (server_1) manages IP addresses. It MAY also manage other part of the configuration. - Another DHCP server (server_2) manages the rest of the configuration. - Partition of the configuration information (other than IP address) between the two DHCP servers is a matter of policy and agreement between administrators of the two servers. It is out of the scope of this document. 4. Redirect approach We define a new DHCP option called the Next Server Option. This option is used by a DHCP server to indicate to a DHCP client the IP address of a second DHCP server from where it can retrieve the remaining of its configuration. 4.1 Difference with the 'siaddr' field The 'siaddr' field is used by a DHCP server to tell the client the IP address of the server to use in the next step of the client bootstrap process [2]. The proposed option differs from the 'siaddr' field in that the Next Server is used by the DHCP client not to retrieve a boot file but the rest of its DHCP configuration. 4.2 Next Server Option This option is a DHCP option [2, 3]. The Next Server Option is returned in DHCPOFFER and DHCPACK by a DHCP server. A DHCP client SHOULD send a DHCPINFORM to the address indicated in the Next Server Option field to retrieve the rest of its configuration. The code for this option is TBD, and its length is 4. It contains the IP address of the next DHCP server to be used by a DHCP client in its configuration process. Code Len Address +-----+-----+-----+-----+-----+-----+ | TBD | 4 | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+ A typical double-phase configuration using the redirect approach is: - A DHCP client broadcasts a DHCPDISCOVER. It receives a DHCPOFFER from server_1 containing (at least) a proposed IP address. - Based on its local policy, the server_1 returns a Next Server Option or not. This decision as well as the address returned in the Next Server option MAY be based on some of the options in the client request such as the 'client identifier' option or the 'User Class' option [4]. - the DHCP client and server_1 finish their DHCP exchange in the standard way. - if the Next Server option was present, then the DHCP client SHOULD send a DHCPINFORM to the IP address indicated in the option. Note that the two phases are independent of each other. In this way, a failure of the second phase does not affect the first one. 5. Proxy approach In this approach, the client only communicates with server_1. Server_1 then retrieves some information from server_2 before answering the client. A typical double-phase configuration using the proxy approach is: - A DHCP client broadcasts a DHCPDISCOVER. - When server_1 receives it, it decides whether to send a DHCPOFFER based on its local configuration information only or to retrieve additional information from server_2. This decision as well as the choice of server_2 MAY be based on some of the options in the client request such as the 'client identifier' option or the 'User Class' option [4]. - If server_1 decides to retrieve additional information from server_2, then it sends a DHCPINFORM to server_2. [Question: is it possible to have a server send a DHCPINFORM? Or can only clients do it?]. - When server_1 receives the information from server_2, it sends a DHCPOFFER back to the client. This DHCPOFFER message contains both local information (at least the IP address) and information received from server_2. If server_1 does not receive an answer from server_2, it sends only its local information (at least an IP address) in the DHCPOFFER to the client. - Server_1 and the client finish the DHCP exchange in the normal way. 6. Open Issues - What is the better approach: redirect or proxy? The proxy approach has the advantage of not requiring any change in clients, and the proxy server takes responsibility for fully completing the configuration process Feedback from the list is welcome. - Should we enable more than 2 phases? - Should the sharing of information between the two DHCP servers be managed through exchanges between the corresponding databases instead of through the DHCP protocol? 7. Security considerations The IP address of server_2 may depend on some options sent by the client such as the 'client identifier' option or the 'User Class' option [4]. A client giving false information in one of these options could have access to some configuration information to which it is not entitled. Authentication [5] and policy at the DHCP server could be used to prevent that happening. 8. Acknowledgements Thanks to Nick Farrow, George Tsirtsis and Alan O'Neill for their review and comments. 9. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997. [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [3] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [4] G. Stump, R. Droms, "The User Class Option for DHCP", draft-ietf-dhc-userclass-03.txt, work in progress. [5] R. Droms, W. Arbaugh, "Authentication for DHCP Messages", draft-ietf-dhc-authentication-11.txt, work in progress 10. Author information Jerome Privat BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, IP5 3RE UK Phone: +44 1473 648910 Email: jerome.privat@bt.com 11. Expiration This document will expire on February 2000.