Network Working Group Glenn Stump, IBM INTERNET DRAFT Pratik Gupta, IBM March 1997 Expires September 1997 The Server Selection Option for DHCP Status of this Memo This document is an Internet-Draft. 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 Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1.0 Abstract This option is provided by DHCP servers to DHCP clients so that clients may optionally select from among multiple offers received from DHCP servers in the network based on a network-administrated preference system. The information contained in this option is a hex value that represents the priority of the offer in which this option is contained. 2.0 Definitions Throughout this document, the words that are used to define the significance of the particular requirements are capitalized. These words are: MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. MUST NOT draft-ietf-dhc-sso-00.txt [Page 1] DRAFT DHCP Server Selection Option March 1997 This phrase means the item is an absolute prohibition of this specification. SHOULD This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. SHOULD NOT This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighted before implementing any behavior described with this label. MAY This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example, another vendor may omit the same item. This document also uses the following terms: o "DHCP client" 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. o "binding" A binding is a collection of configuration parameters, including at least an IP address, associated with or "bound to" a DHCP client. Bindings are managed by DHCP servers. draft-ietf-dhc-sso-00.txt [Page 2] DRAFT DHCP Server Selection Option March 1997 3.0 The DHCP Server Selection Option DHCP provides a powerful mechanism for automating and centralizing the administration of IP host configuration and has become a critical service in many large IP networks. Because of its importance in networks and because it can create a single point of failure for network operations (from a DHCP client's perspective), many network administrators choose to deploy multiple DHCP servers in order to enhance availability and/or performance of DHCP services. However, for sites with multiple DHCP servers, the DHCP protocol does not provide a means by which a DHCP client may select from among the DHCP server offers according to policy defined by the network administrator. The protocol [see RFC1541 or current internet draft] currently states that: "DHCP clients are free to use any strategy in selecting a DHCP server among those from which the client receives a DHCPOFFER message. Thus, currently, client "policy" , of which there is essentially no standardization, determines which offer is selected. What's worse is that, in practice, most vendor's implementation of policy here is very basic (e.g., first offer received) and is "hard-coded" (i.e., non- configurable). A mechanism that enables a server-based policy for determining how clients select among DHCP offers can provide a network administrator better control over how addresses are allocated across the multiple DHCP servers. This type of control takes on increased importance considering that IP address spaces cannot generally be shared across DHCP servers, thus requiring network administrators to divide the available addresses among many DHCP servers. For example, suppose a site requires local "primary" DHCP server and a remoted "backup" DHCP server. The administrator would want local DHCP clients to choose an offer from the primary DHCP server if available, or one from the "backup" only when the primary weren't responding. The DHCP Server Selection Option can be used to institute this kind of DHCP serving policy. The DHCP Server Selection Option specifies a simple, relative "ranking" value associated with -- and contained in -- each server's DHCPOFFER. The client can simply compare the relative "ranking" values of all the DHCPOFFERs received and choose the DHCPOFFER with the highest ranking value. 4.0 DHCP Server Selection Option Format draft-ietf-dhc-sso-00.txt [Page 3] DRAFT DHCP Server Selection Option March 1997 The code for this option is TBD, and its length is 4 bytes. Code Len Priority +-------+-------+---------+----------+ | TBD | 2 | rank | +-------+-------+---------+----------+ where: r = rank, or relative priority (unsigned number), of the server offer in which this option is contained. The allowable range is x'00' to x'FF', inclusive. 5.0 DHCP Server Behavior A DHCP Server which supports the DHCP Server Selection Option MUST include the option in (and only in?) DHCPOFFER packets to requesting clients. The value "rank" in the priority field can be statically pre-configured or dynamically calculated. Further, these values can be coordinated across DHCP servers to achieve the desired priority system behavior (see "Application Notes" below). However, the rules for this coordination and the associated methods for determining the ranking values are considered server or administrative policy. 6.0 DHCP Client Behavior A DHCP client which supports the DHCP Server Selection option SHOULD use the DHCP Server Selection option as the primary discriminator for selecting among DHCPOFFERs from multiple DHCP servers. The highest priority offer -- that containing the highest "rank" value in the DHCP Server Selection Option of the offer -- should be selected. If two DHCPOFFERs have equivalent DHCP Server Selection priority values, then the DHCP client can use other mechanisms to choose among the equivalent offers. 7.0 Application Notes The DHCP Server Selection option allows the DHCP/network administrator to control DHCP services characteristics by influencing the way addresses are allocated across a set of DHCP servers. The administrator may wish to configure all of the servers to have equal serving priority or to configure some to have a greater priority than others. Further, not only can the network administrator prescribe an address allocation scheme across DHCP servers, but the option can also be used to enable the servers to return to the prescribed state in the event that a server failure resulted in an imbalance. draft-ietf-dhc-sso-00.txt [Page 4] DRAFT DHCP Server Selection Option March 1997 The following sections outline how the DHCP Server Selection option can be used to achieve a desired service behavior: 7.1 DHCP Server Segregation DHCP servers that are assigned different rank values, "r", are viewed by DHCP clients as having varying priorities. That is, the DHCP servers are segregated according to a distinct priority system (set by the DHCP system administrator). Clients will choose an offer received from the server with the highest assigned rank value, "r". Once a client can differentiate priorities among DHCP servers, the DHCP administrator can manipulate the priorities across DHCP servers to affect the DHCP serving system behavior, such as "primary-and- backup". A simple example of the DHCP Server Selection Option used for the DHCP server segration would be a customer environment where a remoted "branch office" subnet has one local "primary" DHCP server and one (remote) "backup" at the corporate headquarter's IS center. The DHCP clients on the branch office subnet would choose an offer from one of the primary DHCP servers if available, or one from the "backup" in the event the primary wasn't operational (or wasn't responding in a timely fashion due to, for example, peak load). 7.2 DHCP Server Aggregation DHCP servers which assign the same rank value, "r", in their DHCPOFFERs are perceived by DHCP clients as equals. That is, the servers are effectively an aggregated set of equivalent servers, and offers from equivalent servers can be selected using some other criteria (e.g., best option match, first offer received, or other client-based policy). An example where server aggregation is useful is a customer environment similar to the "primary-and-backup" example used above, but where a second local "primary" DHCP server is deployed (e.g., for the purposes of better service availability and for responsiveness during peak loads). Here, the "branch office" clients would always choose an offer from one of the primary DHCP servers (without preference) if available, or else from one from the "backup" in the event neither primary were operational. 7.3 Minimization of Change in Address Mappings The working group has discussed cases where clients can either forget (e.g., due to lost data) or not have the ability to remember (e.g., due to lack of local store) a current binding. This lack of memory draft-ietf-dhc-sso-00.txt [Page 5] DRAFT DHCP Server Selection Option March 1997 can lead to undesirable results such as multiple active bindings for a client on a particular subnet as well as an associated DNS address mapping changes. The DHCP Server Selection option can be used here to effectively help the client "remember" that they have an active (or recent) binding reserved at a particular DHCP Server, thus resulting in less DNS mapping. For example, a DHCP Server may be programmed to respond with a very high value(e.g., x'FFFF') to clients for which the DHCP Server has an active (or recent) binding. 6.0 Security Considerations There are currently no security mechanisms defined for the DHCP protocol. 7.0 References [RFC1533] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions" [RFC1541] R. Droms, "Dynamic Host Configuration Protocol" 8.0 Acknowledgments The authors would like to thank the following people for their review and helpful comments in the formulation of this paper: Thomas Narten, Esther Burwell, Ralph Droms 9.0 Author Information Pratik Gupta IBM, Inc. 4205 S.Miami Blvd Research Triangle Park, NC 27709 Phone: (919)254-5654 email: pratik_gupta@vnet.ibm.com Glenn Stump IBM, Inc. 4205 S.Miami Blvd Research Triangle Park, NC 27709 Phone: (919)254-5616 email: glennstump@vnet.ibm.com draft-ietf-dhc-sso-00.txt [Page 6]