1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
|
Network Working Group Glenn Stump, IBM
INTERNET DRAFT Pratik Gupta, IBM
March 1997
Expires September 1997
The Server Selection Option for DHCP
<draft-ietf-dhc-sso-00.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 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 92, and its length is 4 bytes.
Code Len Priority
+-------+-------+---------+----------+
| 92 | 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]
|
