Internet DRAFT - draft-bourdais-dhcp-cluster
draft-bourdais-dhcp-cluster
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]
