Network Working Group F. Bourdais Internet-Draft France Telecom R&D Expires: April 20, 2006 October 17, 2005 DHCP cluster draft-bourdais-dhcp-cluster-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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." 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. This Internet-Draft will expire on April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a design of DHCP server that relies upon the use of an external storage entity. Such solution provides an alternative solution to the DHCP failover protocol for the deployment of multiple DHCP servers. Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", Bourdais Expires April 20, 2006 [Page 1] Internet-Draft DHCP cluster October 2005 "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview of the DHCP Cluster . . . . . . . . . . . . . . . . . 5 5. Considerations on DHCP cluster designs . . . . . . . . . . . . 6 5.1 DHCP load balancing . . . . . . . . . . . . . . . . . . . 6 5.2 Hardware load-balancing . . . . . . . . . . . . . . . . . 8 5.3 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Client-cluster interaction . . . . . . . . . . . . . . . . . . 10 6.1 Cluster with DHC load balancing . . . . . . . . . . . . . 10 6.2 Cluster with load-balancing appliance . . . . . . . . . . 11 6.3 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Bourdais Expires April 20, 2006 [Page 2] Internet-Draft DHCP cluster October 2005 1. Introduction The document is possibly applicable to both DHCP for IPv4 and IPv6 networks. The main comparison is held with DHCPv4 since there are numerous known implementations and operational applications, and also because RFC3315 [3] is less specific about the information storage environment than RFC2131 [2] is. DHCP is widely used in networks of multiple sizes and eases the pain of terminal configuration. Within operator network environments, the main DHCP deployments are cable-modem, mobile and wireless networks. In xDSL networks, operators traditionally prefer PPP to DHCP because of its capability to provide user authentication and accounting. However, the introduction of new IP services, such as video and video-conferencing, and the capabilities of the related terminals, push DHCP as a key protocol to configure terminals in a plug and play fashion. In this context, the operators have to define an operational framework in which the DHCP server takes a critical role. Compared to traditional corporate networks, the level of requirements is higher in terms of availability, scalability and security capabilities. Other requirements are also of primary importance, such as the capability of the DHCP server to interface smoothly with external entities which would require DHCP service-related information. From the operator's viewpoint, IPv4 addresses are precious resources, and the DHCP server is therefore expected to assist him for controlling and monitoring their allocation. This document describes a DHCP server that complies with the design goals described in section 1.6 of RFC2131, based upon the use of an external centralized storage entity. Its design is a potential alternative to DHCP Failover protocol for the deployment of multiple DHCP servers. 2. Terminology This document uses the same terminology as of RFC2131, with the following additional terms : o DHCP repository : An host working as a centralized storage entity for one or several DHCP nodes. It contains the binding information related to DHCP clients. Bourdais Expires April 20, 2006 [Page 3] Internet-Draft DHCP cluster October 2005 o DHCP node : A host processing DHCP messages which is connected to an externalized repository. o DHCP cluster : A platform gathering one or several DHCP nodes connected to a centralized DHCP repository. 3. Requirements The aim is to meet the following list of requirements : o Compliancy with RFC2131. o Flexibility regarding the address allocation mechanisms : static and dynamic allocation mechanisms, possible interrogation of a third party entity during the DHCP message processing. o Reliability : reduce downtime while ensuring high service availability even when provisioning, troubleshooting and maintenance operations occur. o OSS integration : the DHCP server should easily interface with external entities, in order to fulfill operational tasks such as automated provisioning, monitoring and reporting of the usage of IP addresses. The information stored by the DHCP server should be available for external entities within the OSS. o Scalability : the DHCP server should provide an efficient and scalable service, in front of multiple entities embedding DHCP agent relays. o Serving multiple purposes : the same DHCP server should allow the allocation of IP addresses for a wide range of applications, e.g. TV over xDSL, IP telephony or video-conferencing. It involves a necessary support for the provisioning of different kinds of terminals, either mono or multi-service capable, and a support for interpretation of DHCP message content, e.g. MAC address, GIADDR, options 60/77/82 and others. o Inter-working within a DHCP environment : the DHCP server should deal with the implementation and behavior of DHCP relay agents. For example, the lack of an encoding formalism in RFC3046 [4] for the circuit-id sub-option, which is a fundamental information for an operator, results in various encoding schemes by the network entities that are entitled to add information in the DHCP option #82. o Security : without DHCP authentication as described in RFC3118 [5], a DHCP server remains subject to many attacks, such as DoS, lease attacks to exhaust free leases, spoofing of any DHCP message sent by terminals, etc. However, the DHCP server should provide some mechanism to report and detect potential attacks or malfunctions, and to filter DHCP messages based on part of the content, e.g. GIADDR or MAC address prefix. Bourdais Expires April 20, 2006 [Page 4] Internet-Draft DHCP cluster October 2005 4. Overview of the DHCP Cluster The cluster design follows RFC2131 as the main reference. It takes a specific direction on the information storage aspect compared to many existing DHCP server implementations. Section 4 of RFC2131 assumes that the DHCP server offers a local storage capability. The storage environment is also mentioned in sections 2.1 and 3. RFC3315 does not discuss the way the storage of DHCP-related information should be implemented. The term 'database' is not even mentioned. The choice of performing DHCP message processing and storage on the same entity is an interpretation of RFC2131. This choice has many advantages, including to avoid creating data persistence issues and to optimize the speed of the DHCP service. However, there is a main drawback when several DHCP servers are deployed and used on the same network. The RFC2131 mentions these situations, but does not specify how DHCP servers would cooperate to ensure the consistency of information between multiple DHCP services. The DHCP cluster is a DHCP server implementation that relies upon an externalized storage database which is shared locally among several DHCP nodes. These nodes process DHCP messages and have limited configuration information. They do not deal with lease consistency, which is a task achieved through the externalized database. The resulting platform may be described as a group of one or several DHCP message processing nodes, and a centralized repository to which the nodes are connected. This DHCP repository stores both configuration and lease information related to the DHCP service. Physically, each DHCP node is embedded in a host, while the database may consist in several hosts, e.g. with replication or database grid. ----------- ----------- ----------- | DHCP node | | DHCP node | | DHCP node | -----+----- -----+----- -----+----- | | | +-------------------+-------------------+ | ----+----- |Repository| ---------- Figure 1 - Description of a DHCP cluster Bourdais Expires April 20, 2006 [Page 5] Internet-Draft DHCP cluster October 2005 There is no need for an inter-node communication protocol such as the DHCP failover protocol [7] with this design. The DHC load balancing algorithm [6] may be used as solution to share the processing task on the DHCP nodes. The inter-working of DHCP nodes with an externalized entity naturally slows down the service by comparison with a server embedding its database. However, there are many operational examples of such DHCP servers interfaced with external databases or LDAP repositories showing that a tradeoff between service performance and functional requirements may be acceptable for an operator. 5. Considerations on DHCP cluster designs Given the roles of DHCP nodes and database entities, there are several possible designs. The following ones offer different options in terms of entities' deployment and software/hardware load sharing. These designs may have potential impacts on the functional behavior of the DHCP nodes which are part of the cluster. For all designs, the repository represents a point of failure. Its redundancy may be enforced either through grid or replication mechanisms. 5.1 DHCP load balancing This design consists in using DHC load balancing algorithm, as defined in RFC3074, on the DHCP nodes connected to the centralized repository. All nodes are interconnected to the rest of the relay agents, and must maintain load balancing parameters that are required for efficient DHCP service cooperation. From the viewpoint of the DHCP clients and relay agents, the DHCP nodes of the cluster are concurrent. The relay agents must point towards all the DHCP nodes that are part of the cluster. Thus, all incoming DHCP messages are unicast to all DHCP nodes. Bourdais Expires April 20, 2006 [Page 6] Internet-Draft DHCP cluster October 2005 | | | | | | -----+----- -----+----- -----+----- | DHCP node | | DHCP node | | DHCP node | | HBA-1 | | HBA-2 | | HBA-3 | -----+----- -----+----- -----+----- | | | +-------------------+-------------------+ | ----+----- |Repository| ---------- Figure 2 - DHCP cluster with DHCP Load balancing Operations, e.g. add or remove a new node, requires to modify the configuration on the relay agents with an updated list of active DHCP nodes accordingly. Also, the load balancing Hashing Bucket Assignments (HBA) of each node must be updated when an operation or a failure occurs to maintain a complementary behavior, and optionnaly use the Delayed Service behavior described in RFC3074. Upon receipt of an unicast request forwarded by a relay agent, each DHCP node follows the following behavior : 1. Check the integrity of the DHCP message 2. Apply the load balancing algorithm to find out the node that has will be responsible for processing this request 3. Process the DHCP message The DHCP message processing step may include the enforcement of access control and policy rules based on the content of each DHCP message. A rule is defined as a regular expression which contains one or several elements among the information available in a DHCP message. Upon verification of this rule, the DHCP message is dropped or not. As an example, a rule may be defined based upon the MAC address prefix to filter the terminal from a given vendor. Then, the DHCP nodes interrogates the repository in order to find an adequate configuration for the terminal. This question may be simple or complex, e.g. involving one or several parameters among all the information available in a DHCP message. During a connection attempt between a node and the repository, there are three cases: Bourdais Expires April 20, 2006 [Page 7] Internet-Draft DHCP cluster October 2005 o No connection : if the DHCP node cannot reach the main repository within a given timeframe, it must address the same interrogation to a backup repository, if any. o Failure : the repository does not find any configuration matching the interrogation. It must reply to the DHCP node so that the latter with either drop the request or send a NACK message. o Success : The repository finds a matching configuration including a valid lease. It must mark the selected lease and reply to the DHCP node with the information related to the binding. Upon receipt of the response of the repository, the DHCP node constructs the DHCP message and sends it to the requesting device that will be assigned an IP address. 5.2 Hardware load-balancing The introduction of a specific hardware appliance to ensure load balancing, e.g. Layer-four switch, is an alternative to the use of the DHCP load balancing algorithm to distribute the load among the DHCP nodes. Since this choice is technology specific, it is considered here only because of its functional impact on the cluster behavior. In such design, the DHCP nodes and repository are interconnected to the rest of the network through one or several hardware load balancing appliances. The DHCP platform may be hidden from the terminals and relay agents, by making them point to these appliances. The advantage is that any operation on a node, e.g. insertion/removal of a DHCP node, is transparent for the clients and relay agents. The appliance should be configured to forward only packets using DHCP destination and source ports. Since the node may be completely stateless, it may process DHCP messages at any step of a DHCP transaction. In order to orientate the DHCP clients and relay agents towards the appropriate appliance, the field 'server identifier' provisioned by the DHCP nodes constructing the DHCP messages MUST contain the IP address of the appliance's WAN interface. Bourdais Expires April 20, 2006 [Page 8] Internet-Draft DHCP cluster October 2005 | -----------------------+----------------------- | Load balancing appliance(s) | ---+-------------------+-------------------+--- | | | | | | -----+----- -----+----- -----+----- | DHCP node | | DHCP node | | DHCP node | -----+----- -----+----- -----+----- | | | +-------------------+-------------------+ | ----+----- |Repository| ---------- Figure 3 - DHCP cluster with load balancing appliance The advantage of such a design is that each DHCP entity is specialized in performing a specific task : o The DHCP nodes are dedicated to DHCP message processing and process all the received DHCP messages o The DHCP repository is the centralized source for provisioning IP addresses and managing lease information 5.3 Anycast The Anycast design of the DHCP cluster is an approach where DHCP nodes may be located in different areas while maintaining a relationship with a common DHCP repository. The connection between DHCP nodes and the repository may not be persistent. The DHC load balancing algorithm is not applicable. All DHCP nodes are configured with an anycast address. The access network router forwards the DHCP messages towards the nearest DHCP node from an IP routing standpoint. Bourdais Expires April 20, 2006 [Page 9] Internet-Draft DHCP cluster October 2005 | | | | | | -----+----- -----+----- -----+----- | DHCP node | | DHCP node | | DHCP node | -----+----- -----+----- -----+----- | | | +-------------------+-------------------+ | ----+----- |Repository| ---------- Figure 4 - DHCP cluster with anycast 6. Client-cluster interaction This section describes the protocol exchanges between clients and cluster for the three designs, considering the DHCP message chronology (DISCOVER, OFFER, REQUEST, ACK). Section 3 of RFC2131 is the reference for the description of the exchanges. 6.1 Cluster with DHC load balancing 1. The client broadcasts a DHCP DISCOVER message on its local physical subnet. The DHCP DISCOVER message MAY include options that suggest values for the network address and lease duration. A DHCP relay agent may pass the message on to all DHCP nodes, assuming the clients and nodes are not on the same physical subnet. It may insert additional information through the relay agent information option following RFC3046. 2. Each node should use the load balancing algorithm to find out if it must process this request. When processing the request, the node must analyze the DHCP message by comparing its content to configured rules. If this comparison match a rule, the node interrogates the repository to find a binding that corresponds to the DHCP DISCOVER along with parameters among those present in the DHCP message. 3. The repository receives the question and checks if there is a binding corresponding to the request. If not, the request should be discarded. Otherwise, the repository marks the corresponding IP address as "reserved" and sends the information towards the DHCP node that initiated the question. This mark may involve several parameters including the reserved IP address, the MAC address, the client-identifier and other information available in the DHCP request. If several nodes send the same question, the Bourdais Expires April 20, 2006 [Page 10] Internet-Draft DHCP cluster October 2005 repository should answer to all the nodes with the exact same response. 4. Based on the repository response, a node responds with a DHCP OFFER message that includes the IP address in the 'yiaddr' field, its own address in the 'server identifier' option, and other configuration parameters in DHCP options. When allocating a new IP address, nodes should check that the offered network address is not already in use, e.g. with an ICMP Echo Request. Such feature MAY be disabled. 6.2 Cluster with load-balancing appliance 1. The client broadcasts a DHCP DISCOVER message on its local physical subnet. The DHCP DISCOVER message MAY include options that suggest values for the network address and lease duration. A DHCP relay agent may pass the message on to the cluster by targeting the IP address of the load-balancing appliance in case it is not on the same physical subnet. It may insert additional information through the relay agent information option following RFC3046. 2. The appliance receives packets identified as DHCP messages through port identification or a complete packet analysis. Any packet that are not with DHCP ports should be filtered by the appliance. According to a configured distribution algorithm, the appliance forwards the message to one of the DHCP nodes of the cluster. 3. The selected DHCP node receives the request and must analyze the DHCP message by comparing its content to configured rules. If this comparison match a rule, the node interrogates the repository to find a binding that corresponds to the DHCP DISCOVER along with the parameters sent by the client and other potential parameters inserted by a relay agent. 4. The repository checks if there is a binding corresponding to the request. If not, the request should be discarded. Otherwise, the repository marks the corresponding IP address as "reserved" and sends the information to the DHCP node which initiated the question. This mark may involve several parameters including the reserved IP address, the MAC address, the client-identifier and other information available in the DHCP request. If the terminal resends the request and that the same question is sent by another node, the repository must answer with the same response. 5. Based on the repository response, the node responds with a DHCP OFFER message that includes the IP address in the 'yiaddr' field, the IP address of the load-balancing appliance in the 'server identifier' option, and other configuration parameters in DHCP options. The response does not need to transit through the appliance. When allocating a new IP address, nodes should check that the offered network address is not already in use, e.g. with Bourdais Expires April 20, 2006 [Page 11] Internet-Draft DHCP cluster October 2005 an ICMP Echo Request. Such feature MAY be disabled. 6.3 Anycast 1. The client broadcasts a DHCP DISCOVER message on its local physical subnet. The DHCP DISCOVER message MAY include options that suggest values for the network address and lease duration. A DHCP relay agent may pass the message on to the cluster by targeting the Anycast IP address of the DHCP cluster, in case a DHCP node is not on the same physical subnet. It may insert additional information through the relay agent information option following RFC3046. 2. According to anycast routing, one DHCP node receives the request, and must analyze the DHCP message by comparing its content to configured rules. If this comparison match a rule, the node interrogates the repository to find a binding that corresponds to the DHCP DISCOVER message along with parameters sent by the client and other potential parameters inserted by a relay agent. 3. The repository receives the question and check if there is a binding corresponding to the request. If not, the request should be discarded. Otherwise, the repository marks the corresponding IP address as reserved and sends the information to the DHCP node that initiated the question. This mark may involve several parameters including the reserved IP address, the MAC address, the client-identifier and other information available in the DHCP request. If the terminal resends the request and that the same question is sent by another node, the repository should answer with the same response. 4. Based on the repository's response, the node responds with a DHCPOFFER message that includes the IP address in the 'yiaddr' field, the anycast IP address of the DHCP cluster in the 'server identifier' option, and other configuration parameters in DHCP options. When allocating a new IP address, nodes should check that the offered network address is not already in use, e.g. with an ICMP Echo Request. Such feature MAY be disabled. 7. Security Considerations This document does not raise any further issue as far as the security related to the use of DHCP is concerned. The use of rules based on DHCP information as access control and/or policies to enforce IP address allocation corresponds to a classic feature. RFC3118 is the reference to achieve authentication of DHCP messages, and could be implemented with the DHCP cluster in the same way it could be implemented with any implementation following RFC2131 Bourdais Expires April 20, 2006 [Page 12] Internet-Draft DHCP cluster October 2005 guideline. 8. IANA considerations None. 9. Acknowledgments Many thanks to Frederic Le Garrec, Christian Jacquenet and Hidega Tiku for their inputs. 10. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [3] Droms, R., "Dynamic Host Configuration Protocol for IPv6", RFC 3315, July 2003. [4] Patrick, M., "DHCP relay agent Information Option", RFC 3046, January 2001. [5] Droms, R., "Authentication for DHCP Messages", RFC 3118, June 2001. [6] Volz, B., "DHC Load Balancing Algorithm", RFC 3074, February 2001. [7] Droms, R., "DHCP Failover Protocol", draft version 10 failover, February 2002. Author's Address Francois Bourdais France Telecom R&D 905 rue albert einstein Sophia Antipolis 06921 France Email: francois.bourdais@francetelecom.com Bourdais Expires April 20, 2006 [Page 13] Internet-Draft DHCP cluster October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bourdais Expires April 20, 2006 [Page 14]