Network Working Group Glenn Stump, IBM
INTERNET DRAFT Pratik Gupta, IBM
Obsoletes: <draft-ietf-dhc-sso-01.txt> Ralph Droms, Bucknell University
November 1998
Expires May 1999
The Server Selection Option for DHCP
<draft-ietf-dhc-sso-02.txt>
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 view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.Edu (Us West Coast).
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 offer from a DHCP. The information
contained in this option is an hex value that represents an integer
value indicating the priority of the offer in which this option is
contained.
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 [3].
Stump, Gupta, Droms [Page 1]
DRAFT DHCP Server Selection Option November 1998
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. The DHCP Server Selection Option
DHCP [1] 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 many DHCP in order to
enhance availability and/or performance of DHCP services.
However, for networks 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 determined by the network
administrator. The protocol specification [1] 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 which enables a server-based policy for determining how
clients select among DHCP offers would allow a network administrator
to control the manner in which 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.
This document specifies an option that can be configured by network
administrators in DHCP servers and which can influence how DHCP
clients select an offer from among those servers. The option
described in this document is a new DHCP option [2].
Stump, Gupta, Droms [Page 2]
DRAFT DHCP Server Selection Option November 1998
3.1 Motivation
In general, the motivation for inventing the DHCP Server Selection
option originates from shortcomings identified in networks where
multiple DHCP servers are used enhance DHCP serving performance,
availability, or both. Specifically, these problems are:
1. Server Segregation
2. Server Aggregation
3. Server Introduction and Deprecation
4. DNS IP Address Mapping Stability
There may well be others which are important - or will be important
given new capabilities in the future - and not listed above. The
DHCP Server Selection mechanism defined herein must be flexible
enough to accommodate future requirements.
3.1.1 Server Segregation: Differentiating Servers Based on Varying
Priorities
Multiple DHCP servers can also be segregated to differentiate the
importance or roles of some DHCP server or servers vs. others. The
simplest and most common example here is where one DHCP server is
intended as a "primary" or "preferred" server for a subnet while some
other server is intended as a "secondary" or "backup" server capacity
in the case the primary fails. Typically, the preferred server(s)
will have the most number of available addresses and the backups have
some lesser number, which are only intended for use when the
preferred server(s) fail or their addresses are depleted. Again, all
servers are assumed to provide an equivalent set of options to a
requesting client.
Segregated DHCP server deployments present two fundamental problems
for today's DHCP implementations:
1. There is no standard means for a client to differentiate which
of many equivalent offers to accept. Assuming that most client
implementations will accept the first of many equivalent offers
received, a "backup" server's address pool will be depleted each
time its offers are served first to a client. This may happen
frequently, for example, during times of peak loads on the
preferred servers.
2. Once an address lease from an "alternate" DHCP server is selected
(for any reason), that address will likely be re-selected on sub-
sequent client reboot/init-reboots.
A mechanism which enables DHCP clients to select an offer based on an
Stump, Gupta, Droms [Page 3]
DRAFT DHCP Server Selection Option November 1998
administrative preference by encouraging clients to always select a
preferred DHCP server (or order of servers) over others who respond
in the network.
DISCUSSION:
Such a mechanism could also help in preventing DHCP service
disruption due to the accidental introduction of rogue DHCP
servers. That is, if all clients would be configured to choose
offers with the DHCP Server Selection when present, and all DHCP
Server Vendors would disable the option by default, then a DHCP
offer from a rogue DHCP server accidentally started by a novice
would essentially be ignored. Is this worth mentioning as a
motivation?
3.1.2 Server Aggregation: Grouping Servers of Equal Priority
Multiple DHCP servers, typically two, which have essentially
equivalent configuration characteristics - typically in terms of the
options served and the number of addresses available -- be aggregated
to enhance the responsiveness and availability of DHCP services to a
particular subnet.
However, in the event that one of the DHCP servers responds more
quickly than others the number of addresses available at one server
(e.g., a "fast" server) may be disproportionately low. Thus, failure
of another server in the aggregated set (e.g., the other, "slower"
server) will cause a disproportionately high risk in availability of
DHCP services (e.g., when a slow server, with more available
addresses, fails or is removed from operation temporarily).
A mechanism which enables DHCP clients to select an offer based on
server- administrated preference could allow clients to choose leases
from among servers in a way which could maintain a prescribed balance
of address availability across servers (by maintaining a balance in
the relative address depletion rates).
3.1.3 DHCP Server Introduction or Deprecation
Currently, the process of changing the number of DHCP servers in a
network cannot generally be done gradually or gracefully because,
currently, there is no standard means of allowing servers to share IP
address spaces. A mechanism which enables DHCP clients to select an
offer based on an administrative preference could help in this
process by identifying particular DHCP servers to (or from) which
clients should "migrate" (rather than continuing to use an existing
server).
Stump, Gupta, Droms [Page 4]
DRAFT DHCP Server Selection Option November 1998
3.1.4 DNS Address Mapping Stability
Regardless of whether multiple DHCP servers are aggregated,
segregated, or a combination or both, a "mobile" DHCP client which...
1. moves frequently across many networks or subnetworks, and/or.
2. does not keep track of which leases are active beyond their
current lease.
single subnet over a series of connections and reconnections. This
is due to the fact that, the client would not necessarily choose a
lease based on an active or previous lease association since it is
not instructed to do so and/or is no aware that one exists.
In network environments where either dynamic DNS updates are not
employed or where there is a desire to minimize the number of updates
to DNS mappings, a mechanism to identify a lease representing a
previous address association can be used to, in effect, reduce the
number of changes in a DNS host-name-to-address mapping (i.e., A-RR).
3.2 DHCP Server Selection Option Format
The code for this option is TBD, and its length is 4 bytes.
Code Len Priority
+-------+-------+---------+---------+
| TBD | 2 | p |
+-------+-------+---------+---------+
where: "p" is an unsigned 16 bit integer representing the
priority value chosen for the
server (x'0000'- x'FFFF', inclusive).
DISCUSSION:
Is 16 bits the right number of bits, as opposed to 8 or 32?
It is envisioned that this field can be used in many ways to
accomplish various system behavior across servers. However, the
values within this field must be administered consistently across all
DHCP servers in "the system" (i.e., those serving a particular
subnet) and across DHCP server vendors (so that the same basic
capabilities are administered) in order to achieve the desired
behaviors.
To that end, the policies for acceptable uses of the priority field
will be directed through the specification of DHCP Server Selection
option "profiles", which will be maintained - at least for now -- as
appendices to this document. Each profile will list how the priority
field value is derived, what DHCP serving behaviors are possible, and
how these behaviors are achieved.
Stump, Gupta, Droms [Page 5]
DRAFT DHCP Server Selection Option November 1998
4. DHCP Client Behavior
A client supporting the DHCP Server Selection option MUST use the
DHCP Server Selection option as the primary discriminator for
selecting among multiple offers from servers. The highest priority
value gets first preference. If two DHCP Server Selection priority
values are equivalent, then the DHCP client can use other mechanisms
as described in RFC 2131 to choose among the offers.
DISCUSSION:
Should the client be required to use the DHCP Server Selection
offer if present or only as a tie-breaker if the offers are
equivalent (in terms of options offered)? In general, how should
this option relate to other decision factors (implicit or
explicit).
5. DHCP Server Behavior
When a DHCP server supports the DHCP Server Selection option, the
server MUST select a value for the field according to the policy set
forth by a selected DHCP Server Selection Option "profile". The set
of standardized DHCP Server Selection profiles will be maintained by
the IETF DHC Working Group. The current list of profiles under
consideration is maintained in the appendices of this document.
It is intended that all of the DHCP servers serving a particular
subnet or set of hosts MUST support the same profile in order to
achieve the associated/desired DHCP service behavior for that subnet
or set of hosts.
6. Security Considerations
DHCP currently provides no authentication or security mechanisms.
Potential exposures to attack are discussed is section 7 of the
protocol specification [1].
The server selection option might be used to redirect DHCP clients to
accept configuration parameters from a "bad guy" DHCP server.
7. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Stump, Gupta, Droms [Page 6]
DRAFT DHCP Server Selection Option November 1998
Levels," RFC 2119, March 1997.
8. Author Information
Pratik Gupta
IBM, Inc.
4205 S.Miami Blvd
Research Triangle Park, NC 27709
Phone: (919)254-5616
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
Ralph Droms
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
email: droms@bucknell.edu
Appendix A: Profile 0 [Rank (only)]
The DHCP Server Selection option specifies a mechanism for an
administrator to determine the policy governing how a client chooses
among multiple DHCP offers. In this profile, Profile 0, the
selection criteria used to govern DHCPOFFER selection policy is a
simple, relative "ranking" value. That is, a client will select the
offer from the server with the highest designated priority.
A.1 DHCP Server Selection Option Format
The code for this option is TBD, and its length is 4 bytes.
Code Len Priority
+-------+-------+---------+----------+
| TBD | 2 | r | reserved |
+-------+-------+---------+----------+
where:
r = rank, or relative priority, of server (higher order 8 bits)
reserved = reserved for future use; must be x'00'
The priority field is actually a concatenation of the "rank",
"address" availability, and "flags" field. The "flags" field,
Stump, Gupta, Droms [Page 7]
DRAFT DHCP Server Selection Option November 1998
represented in the lower order byte, can be used to instruct the
client to give preference to offers from servers which have a
currently active or recently expired lease association. The priority
field, represented in the high order byte, can be used to instruct
the client to accept a lease from a server according to some other
criteria (see "DHCP Server Behavior" below).
A.2 DHCP Server Behavior
When a server supports the "rank" field, the value can be statically
pre-configured or dynamically calculated and set to any integer
between x'00' and x'FF', inclusive. The values can be coordinated
across DHCP servers to achieve the desired priority system behavior.
A.3 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.
The following outlines how the DHCP Server Selection option can be
used in each of these situations to achieve the desired service
behavior. Note that these scenarios presume that there are no DHCP
server-to-server coordination mechanisms which could be used to
synchronize the server's databases and effectively share address
spaces.
A.3.1 Server Segregation
DHCP servers which 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
- graceful addition or deletion of DHCP servers
A.3.2 Server Aggregation
Stump, Gupta, Droms [Page 8]
DRAFT DHCP Server Selection Option November 1998
DHCP servers which are assigned the same rank value, "r", are viewed
by DHCP clients as equal. That is, the servers are an aggregated set
of equivalent servers, and offers from equivalent servers can be
selected using some other criteria (e.g., first offer received).
Appendix B: Profile 1 [Rank with Address Binding]
The DHCP Server Selection option specifies a mechanism for an
administrator to determine the policy governing how a client chooses
among multiple DHCP offers. In this profile, Profile 1, the
selection criteria used to govern server selection policy is a
simple, relative "ranking" system plus a mechanism which can be used
to further differentiate equally-ranked servers based on a preference
for offers representing a previous address binding. That is, a
client will select an offer from a particular server because that
server has the highest designated priority, and, in the event that
one or more servers have equal priority (i.e, are aggregated), the
client will select the offer from the server having, in order of
preference, an active address binding or a previous binding which is
still available to the client.
B.1 DHCP Server Selection Option Format
The code for this option is TBD, and its length is 4 bytes.
Code Len Priority
+-------+-------+---------+----------+
| TBD | 2 | r |flags|0000|
+-------+-------+---------+----------+
where:
r = rank, or relative priority, of server (higher order 8 bits)
flags = b `xAxP'' where:
x = reserved, must be x'0'
A = offer contains currently active lease for client
P = offer contain previously active lease available to client
0000 = bits reserved for future use; must be x'0'
Here, the priority field is actually a concatenation of the "rank",
and the "address binding" fields. The use of the rank field is
described in Profile 0. The address binding field indicates whether
this DHCPOFFER represents a currently active (A-flag) or previous (P-
flag) address lease binding.
B.2 DHCP Server Behavior
In addition to the setting the "rank" value as described in Profile
0, the address binding field MUST be set according to whether the
Stump, Gupta, Droms [Page 9]
DRAFT DHCP Server Selection Option November 1998
OFFER contains an currently active address binding for the client
(A-flag set, P-flag cleared), a previous binding (P-flag cleared, A-
flag set), or no previous association (A- and P-flags cleared).
The "rank" and "flags" values used consistently (i.e. by all DHCP
servers serving a subnet) enables a client to select a DHCPOFFER
representing the highest rank and, when one or more offers are of
equal rank, an active or (else) previous address binding.
B.3 Application Notes
The primary reason for using the "address binding" field is to
minimize the number of DNS updates which are required due to changes
in IP address.
Appendix C: Profile 2 [Rank with Address Balancing]
The DHCP Server Selection option specifies a mechanism for an
administrator to determine the policy governing how a client chooses
among multiple DHCP offers. In this profile, Profile 2, the
selection criteria used to govern server selection policy is a
simple, relative "ranking" system plus a mechanism which can be used
to further differentiate equally-ranked servers based on the
availability of address leases at the servers . That is, a client
will select an offer from a particular server because that server has
the highest designated priority, and, in the event that one or more
servers have equal priority (i.e., are aggregated), the client will
select the offer from the server with the most available addresses
(relative to the total number of addresses available for allocation
by the server).
C.1 DHCP Server Selection Option Format
The code for this option is TBD, and its length is 4 bytes.
Code Len Priority
+-------+-------+---------+----------+
| TBD | 2 | r | v |0000|
+-------+-------+---------+----------+
where:
r = rank, or relative priority, of server (higher order 8 bits)
v = percentage of available leases remaining in pool , calculated
as: v = (#remaining addresses / #total addresses)*100 / 6
0000 = bits reserved for future use; must be x'0'
Here, the priority field is actually a concatenation of the "rank"
field and the "address availability" field. The use of the rank
field is described in Profile 0. The address availability field
Stump, Gupta, Droms [Page 10]
DRAFT DHCP Server Selection Option November 1998
expresses the number of addresses currently available in a server
relative to the number originally defined in the pool (expressed as a
percentage and as calculated above).
C.2 DHCP Server Behavior
In addition to the setting the "rank" value as described in Profile
0, the address availability field MUST be set according to the
relative number of addresses remaining "v", as expressed as an
integer representing a percentage and calculated as follows:
v = INT[(#remaining addresses / #total addresses)*100/ 6]
The "rank" and "v" values used consistently (i.e. by all DHCP servers
serving a subnet) enables a client to select a lease from the highest
ranked server with the best availability of addresses.
C.3 Application Notes
The important point to note here is that the client will select the
highest rank server with "the best address availability", where "best
server" means the one with the largest percentage of addresses
available remaining from its original pool. In other words, the
"system" of DHCP servers using this Profile 2 will tend to maintain
the original, prescribed "balance" of addresses allocated across the
(equivalent) servers.
Maintaining this prescribed balance of address availability is
important in cases one of the DHCP servers in an aggregated set
responds more quickly than others and therefore depletes its
addresses pools at a disproportionately higher rate than others in
the set.. Thus, failure of one of the other servers in the set will
cause a disproportionately high risk in availability of DHCP
services.
To illustrate, suppose there is a set of two equivalent DHCP servers,
A and B, which service a particular subnet. Each server is assigned
half of the available address space to allocate to clients. Now
suppose server A responds to clients' DHCPDISCOVERs significantly
faster than server B. Without some other means for expressing
preference, the clients will likely repeatedly choose DHCPOFFERs from
A, thus depleting its pool at a much faster rate than B. Now suppose
server B encounters a failure or is taken out of operation for
maintenance. Server A, with perhaps very few addresses remaining for
allocation, is left to service the entire subnet.
DHCP Server Selection based on address availability can be used to
maintain a balance of addresses across aggregated servers and thus
optimize availability of services in the event of a server becomes
inoperative (e.g., for maintenance or due to failure).
Stump, Gupta, Droms [Page 11]
DRAFT DHCP Server Selection Option November 1998
Appendix D: Profile 3 [Rank, with Address Balancing, Binding]
The DHCP Server Selection Profiles 0, 1, and 2 introduce mechanisms
to allow DHCP clients to differentiate between DHCPOFFERs from
servers based on a "rank", "previous address binding", and "address
availability". In Profile 3, these mechanisms are all combined into
a single priority system with the given preference of:
1. rank
2. address availability
3. previous address binding
D.1 DHCP Server Selection Option Format
The code for this option is TBD, and its length is 4 bytes.
Code Len Priority
+-------+-------+---------+---------+
| TBD | 2 | r | v |flags|
+-------+-------+---------+---------+
where:
r = rank, or relative priority, of server (higher order 4 bits)
v = percentage of available leases remaining in pool (lower order 4 bits)
calculated as: v = (#remaining addresses / #total addresses) / 6
flags = b`xAxP' where:
x = reserved, must be x'0'
A = offer contains currently active lease for client
P = offer contain previously active lease available to client
The priority field is actually a concatenation of the "rank",
"address availability, and "flags" field. The "flags" field,
represented in the lower order byte, can be used to instruct the
client to give preference to offers from servers which have a
currently active or recently expired lease association. The priority
field, represented in the high order byte, can be used to instruct
the client to accept a lease from a server according to some other
criteria (see "DHCP Server Behavior" below).
DISCUSSION:
Can we cram all fields into 8 bits if we limit rank values to
0,1,2,3 (2 bits)?
D.2 DHCP Server Behavior
A DHCP server offering support for the DHCP Server Selection option
MUST support and set all three fields as described in Profiles 0, 1,
and 2.
D.3 Application Notes
Stump, Gupta, Droms [Page 12]
DRAFT DHCP Server Selection Option November 1998
Using the given combination and preference of DHCP Server Selection
mechanisms, a client will choose the DHCPOFFER with the highest
designated rank. In the event the highest rank servers are
aggregated, the aggregated server with best address availability
status will be selected. Given equal rank and address availability
status, preference for an active or (else) previous address binding
may determine the selection.
Appendix E: Profile 4 [Rank with Binding, Address Balancing]
Profile 4 is identical to Profile 3, with the exception that the
bindings flags field, "flags" is swapped with the "address
availability" field, "v", thus yielding client preference to an
active or previous binding over a server's address depletion status
(assuming identical server rank "r" values].
E.1 DHCP Server Selection Option Format
The code for this option is TBD, and its length is 4 bytes.
Code Len Priority
+-------+-------+---------+----------+
| TBD | 2 | r |flags| v |
+-------+-------+---------+----------+
where:
r = rank, or relative priority, of server (higher order 4 bits)
v = percentage of available leases remaining in pool (lower order 4 bits)
calculated as: v = (#remaining addresses / #total addresses) / 6
flags = b`xAxP' where:
x = reserved, must be x'0'
A = offer contains currently active lease for client
P = offer contain previously active lease available to client
E.2 Application Notes
Using the given combination and preference of DHCP Server Selection
mechanisms, a client will choose a DHCPOFFER with the highest
designated rank. In the event the highest rank servers are
aggregated, the aggregated server with an active or (else) previous
address binding will be selected. Given equal rank and binding
values, preference for the server best address availability status
may determine the selection.
Stump, Gupta, Droms [Page 13]
DRAFT DHCP Server Selection Option November 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Stump, Gupta, Droms [Page 14]