draft-ietf-dhc-sso-02.txt   draft-ietf-dhc-sso-03.txt 
Network Working Group Glenn Stump, IBM Network Working Group Glenn Stump, IBM
INTERNET DRAFT Pratik Gupta, IBM INTERNET DRAFT Pratik Gupta, IBM
Obsoletes: <draft-ietf-dhc-sso-01.txt> Ralph Droms, Bucknell University Obsoletes: <draft-ietf-dhc-sso-03.txt> Ralph Droms, Bucknell University
November 1998 Bill Sommerfeld, Integrated Systems
Expires May 1999 October 1999
Expires April 2000
The Server Selection Option for DHCP The Server Selection Option for DHCP
<draft-ietf-dhc-sso-02.txt> <draft-ietf-dhc-sso-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific The list of Internet-Draft Shadow Directories can be accessed at
Rim), ftp.ietf.org (US East Coast), or ftp.isi.Edu (Us West Coast). http://www.ietf.org/shadow.html.
Abstract Abstract
This option is provided by DHCP servers to DHCP clients so that This option is provided by DHCP servers to DHCP clients so that
clients may optionally select from among multiple offers received clients may optionally select from among multiple offers received
from DHCP servers in the network offer from a DHCP. The information from DHCP servers in the network offer from a DHCP. The information
contained in this option is an hex value that represents an integer contained in this option is a 16-bit unsigned integer which
value indicating the priority of the offer in which this option is represents a value indicating the priority of the offer in which this
contained. option is contained.
Several server profiles are presented in appendices showing different
ways in which the option can be used by a set of servers. Regardless
of the profile, the client behavior is the same.
1. Requirements Terminology 1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
DRAFT DHCP Server Selection Option November 1998
2. DHCP Terminology 2. DHCP Terminology
o "DHCP client" o "DHCP client"
A DHCP client or "client" is an Internet host using DHCP to obtain A DHCP client or "client" is an Internet host using DHCP to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
o "DHCP server" o "DHCP server"
A DHCP server of "server"is an Internet host that returns A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients. configuration parameters to DHCP clients.
3. The DHCP Server Selection Option 3. The DHCP Server Selection Option
DHCP [1] provides a powerful mechanism for automating and DHCP [1] provides a powerful mechanism for automating and
centralizing the administration of IP host configuration and has centralizing the administration of IP host configuration and has
become a critical service in many large IP networks. Because of its become a critical service in many large IP networks. Because of its
importance in networks and because it can create a single point of importance in networks and because it can create a single point of
failure for network operations (from a DHCP client's perspective), failure for network operations (from a DHCP client's perspective),
many network administrators choose to deploy many DHCP in order to many network administrators choose to deploy many DHCP in order to
enhance availability and/or performance of DHCP services. enhance availability and/or performance of DHCP services.
However, for networks with multiple DHCP servers, the DHCP protocol However, for networks with multiple DHCP servers, the DHCP protocol
does not provide a means by which a DHCP client may select from among 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 the DHCP server offers according to policy determined by the network
administrator. The protocol specification [1] currently states that: administrator. The protocol specification [1] currently states that:
"DHCP clients are free to use any strategy in selecting a DHCP server "DHCP clients are free to use any strategy in selecting a DHCP server
among those from which the client receives a DHCPOFFER message." among those from which the client receives a DHCPOFFER message."
Thus, currently, client "policy", of which there is essentially no Thus, currently, client "policy", of which there is no
standardization, determines which offer is selected. What's worse is standardization, determines which offer is selected. In practice,
that, in practice, most vendor's implementation of policy here is most vendor's implementation of policy here is very basic (e.g.,
very basic (e.g., first offer received) and is "hard-coded" (i.e., first offer received or first acceptable offer received) and is
non- configurable). "hard-coded" (i.e., non-configurable).
A mechanism which enables a server-based policy for determining how A mechanism which enables a server-based policy for determining how
clients select among DHCP offers would allow a network administrator clients select among DHCP offers would allow a network administrator
to control the manner in which addresses are allocated across the better control of the manner in which addresses are allocated across
multiple DHCP servers. This type of control takes on increased the multiple DHCP servers. This type of control takes on increased
importance considering that IP address spaces cannot generally be importance considering that IP address spaces cannot generally be
shared across DHCP servers, thus requiring network administrators to shared across DHCP servers, thus requiring network administrators to
divide the available addresses among many DHCP servers. divide the available addresses among multiple DHCP servers.
This document specifies an option that can be configured by network This document specifies an option that can be configured in DHCP
administrators in DHCP servers and which can influence how DHCP servers and which can influence how DHCP clients select an offer from
clients select an offer from among those servers. The option among those servers. The option described in this document is a new
described in this document is a new DHCP option [2]. DHCP option [2].
DRAFT DHCP Server Selection Option November 1998 This document also presents several server profiles showing how this
option can be used by administrators to effect various policies.
Regardless of the profile in use, the operation of the client is the
same -- the profiles listed are just different ways of assigning
priorities to dhcp servers.
3.1 Motivation 3.1 Motivation
In general, the motivation for inventing the DHCP Server Selection In general, the motivation for inventing the DHCP Server Selection
option originates from shortcomings identified in networks where option originates from shortcomings identified in networks where
multiple DHCP servers are used enhance DHCP serving performance, multiple DHCP servers are used enhance DHCP serving performance,
availability, or both. Specifically, these problems are: availability, or both. Specifically, these problems are:
1. Server Segregation 1. Server Segregation
2. Server Aggregation 2. Server Aggregation
skipping to change at page 4, line 4 skipping to change at line 154
received, a "backup" server's address pool will be depleted each received, a "backup" server's address pool will be depleted each
time its offers are served first to a client. This may happen time its offers are served first to a client. This may happen
frequently, for example, during times of peak loads on the frequently, for example, during times of peak loads on the
preferred servers. preferred servers.
2. Once an address lease from an "alternate" DHCP server is selected 2. Once an address lease from an "alternate" DHCP server is selected
(for any reason), that address will likely be re-selected on sub- (for any reason), that address will likely be re-selected on sub-
sequent client reboot/init-reboots. sequent client reboot/init-reboots.
A mechanism which enables DHCP clients to select an offer based on an A mechanism which enables DHCP clients to select an offer based on an
DRAFT DHCP Server Selection Option November 1998
administrative preference by encouraging clients to always select a administrative preference by encouraging clients to always select a
preferred DHCP server (or order of servers) over others who respond preferred DHCP server (or order of servers) over others who respond
in the network. in the network.
DISCUSSION: DISCUSSION:
Such a mechanism could also help in preventing DHCP service Such a mechanism could also help in preventing DHCP service
disruption due to the accidental introduction of rogue DHCP disruption due to the accidental introduction of rogue DHCP
servers. That is, if all clients would be configured to choose servers. That is, if all clients would be configured to choose
offers with the DHCP Server Selection when present, and all DHCP offers with the DHCP Server Selection when present, and all DHCP
Server Vendors would disable the option by default, then a DHCP Server Vendors would disable the option by default, then a DHCP
skipping to change at page 5, line 5 skipping to change at line 201
Currently, the process of changing the number of DHCP servers in a Currently, the process of changing the number of DHCP servers in a
network cannot generally be done gradually or gracefully because, network cannot generally be done gradually or gracefully because,
currently, there is no standard means of allowing servers to share IP currently, there is no standard means of allowing servers to share IP
address spaces. A mechanism which enables DHCP clients to select an address spaces. A mechanism which enables DHCP clients to select an
offer based on an administrative preference could help in this offer based on an administrative preference could help in this
process by identifying particular DHCP servers to (or from) which process by identifying particular DHCP servers to (or from) which
clients should "migrate" (rather than continuing to use an existing clients should "migrate" (rather than continuing to use an existing
server). server).
DRAFT DHCP Server Selection Option November 1998
3.1.4 DNS Address Mapping Stability 3.1.4 DNS Address Mapping Stability
Regardless of whether multiple DHCP servers are aggregated, Regardless of whether multiple DHCP servers are aggregated,
segregated, or a combination or both, a "mobile" DHCP client which... segregated, or a combination or both, a "mobile" DHCP client which...
1. moves frequently across many networks or subnetworks, and/or. 1. moves frequently across many networks or subnetworks, and/or.
2. does not keep track of which leases are active beyond their 2. does not keep track of which leases are active beyond their
current lease. current lease.
single subnet over a series of connections and reconnections. This single subnet over a series of connections and reconnections. This
is due to the fact that, the client would not necessarily choose a 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 lease based on an active or previous lease association since it is
skipping to change at page 6, line 5 skipping to change at line 249
capabilities are administered) in order to achieve the desired capabilities are administered) in order to achieve the desired
behaviors. behaviors.
To that end, the policies for acceptable uses of the priority field To that end, the policies for acceptable uses of the priority field
will be directed through the specification of DHCP Server Selection will be directed through the specification of DHCP Server Selection
option "profiles", which will be maintained - at least for now -- as option "profiles", which will be maintained - at least for now -- as
appendices to this document. Each profile will list how the priority appendices to this document. Each profile will list how the priority
field value is derived, what DHCP serving behaviors are possible, and field value is derived, what DHCP serving behaviors are possible, and
how these behaviors are achieved. how these behaviors are achieved.
DRAFT DHCP Server Selection Option November 1998
4. DHCP Client Behavior 4. DHCP Client Behavior
A client supporting the DHCP Server Selection option MUST use the A client supporting the DHCP Server Selection option MUST use the
DHCP Server Selection option as the primary discriminator for DHCP Server Selection option as the primary discriminator for
selecting among multiple offers from servers. The highest priority selecting among multiple offers from servers. The highest priority
value gets first preference. If two DHCP Server Selection priority value gets first preference. If two DHCP Server Selection priority
values are equivalent, then the DHCP client can use other mechanisms values are equivalent, then the DHCP client can use other mechanisms
as described in RFC 2131 to choose among the offers. as described in RFC 2131 to choose among the offers.
DISCUSSION: DISCUSSION: Should the client be required to use the DHCP Server
Should the client be required to use the DHCP Server Selection Selection offer if present or only as a tie-breaker if the offers are
offer if present or only as a tie-breaker if the offers are equivalent (in terms of options offered)? In general, how should this
equivalent (in terms of options offered)? In general, how should option relate to other decision factors (implicit or explicit).
this option relate to other decision factors (implicit or
explicit).
5. DHCP Server Behavior 5. DHCP Server Behavior
When a DHCP server supports the DHCP Server Selection option, the When a DHCP server supports the DHCP Server Selection option, the
server MUST select a value for the field according to the policy set server MUST select a value for the field according to the policy set
forth by a selected DHCP Server Selection Option "profile". The set forth by a selected DHCP Server Selection Option "profile". The set
of standardized DHCP Server Selection profiles will be maintained by of standardized DHCP Server Selection profiles will be maintained by
the IETF DHC Working Group. The current list of profiles under the IETF DHC Working Group. The current list of profiles under
consideration is maintained in the appendices of this document. consideration is maintained in the appendices of this document.
skipping to change at page 7, line 4 skipping to change at line 295
7. References 7. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor [2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
DRAFT DHCP Server Selection Option November 1998
Levels," RFC 2119, March 1997. Levels," RFC 2119, March 1997.
8. Author Information 8. Author Information
Pratik Gupta Pratik Gupta
IBM, Inc. IBM, Inc.
4205 S.Miami Blvd 4205 S.Miami Blvd
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
Phone: (919)254-5616 Phone: (919)254-5616
email: pratik_gupta@vnet.ibm.com email: pratik_gupta@vnet.ibm.com
skipping to change at page 7, line 32 skipping to change at line 320
Phone: (919)254-5616 Phone: (919)254-5616
email: glennstump@vnet.ibm.com email: glennstump@vnet.ibm.com
Ralph Droms Ralph Droms
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
email: droms@bucknell.edu email: droms@bucknell.edu
Bill Sommerfeld
Integrated Systems, Inc.
1 Tara Boulevard suite 403
Nashua NH 03062
Phone: (603) 897 2060
email: sommerfeld@alum.mit.edu
Appendix A: Profile 0 [Rank (only)] Appendix A: Profile 0 [Rank (only)]
The DHCP Server Selection option specifies a mechanism for an The DHCP Server Selection option specifies a mechanism for an
administrator to determine the policy governing how a client chooses administrator to determine the policy governing how a client chooses
among multiple DHCP offers. In this profile, Profile 0, the among multiple DHCP offers. In this profile, Profile 0, the
selection criteria used to govern DHCPOFFER selection policy is a selection criteria used to govern DHCPOFFER selection policy is a
simple, relative "ranking" value. That is, a client will select the simple, relative "ranking" value. That is, a client will select the
offer from the server with the highest designated priority. offer from the server with the highest designated priority.
A.1 DHCP Server Selection Option Format A.1 DHCP Server Selection Option Format
The code for this option is TBD, and its length is 4 bytes. The code for this option is TBD, and its length is 4 bytes.
Code Len Priority Code Len Priority
+-------+-------+---------+----------+ +-------+-------+---------+----------+
| TBD | 2 | r | reserved | | TBD | 2 | r | reserved |
+-------+-------+---------+----------+ +-------+-------+---------+----------+
where: where:
r = rank, or relative priority, of server (higher order 8 bits) r = rank, or relative priority, of server (higher order 8
bits)
reserved = reserved for future use; must be x'00' reserved = reserved for future use; must be x'00'
The priority field is actually a concatenation of the "rank", The priority field is actually a concatenation of the "rank",
"address" availability, and "flags" field. The "flags" field, "address" availability, and "flags" field. The "flags" field,
DRAFT DHCP Server Selection Option November 1998
represented in the lower order byte, can be used to instruct the represented in the lower order byte, can be used to instruct the
client to give preference to offers from servers which have a client to give preference to offers from servers which have a
currently active or recently expired lease association. The priority currently active or recently expired lease association. The priority
field, represented in the high order byte, can be used to instruct 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 the client to accept a lease from a server according to some other
criteria (see "DHCP Server Behavior" below). criteria (see "DHCP Server Behavior" below).
A.2 DHCP Server Behavior A.2 DHCP Server Behavior
When a server supports the "rank" field, the value can be statically When a server supports the "rank" field, the value can be statically
skipping to change at page 9, line 5 skipping to change at line 400
received from the server with the highest assigned rank value, "r". received from the server with the highest assigned rank value, "r".
Once a client can differentiate priorities among DHCP servers, the Once a client can differentiate priorities among DHCP servers, the
DHCP administrator can manipulate the priorities across DHCP servers DHCP administrator can manipulate the priorities across DHCP servers
to affect the DHCP serving system behavior, such as: to affect the DHCP serving system behavior, such as:
- primary-and-backup - primary-and-backup
- graceful addition or deletion of DHCP servers - graceful addition or deletion of DHCP servers
A.3.2 Server Aggregation A.3.2 Server Aggregation
DRAFT DHCP Server Selection Option November 1998
DHCP servers which are assigned the same rank value, "r", are viewed 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 by DHCP clients as equal. That is, the servers are an aggregated set
of equivalent servers, and offers from equivalent servers can be of equivalent servers, and offers from equivalent servers can be
selected using some other criteria (e.g., first offer received). selected using some other criteria (e.g., first offer received).
Appendix B: Profile 1 [Rank with Address Binding] Appendix B: Profile 1 [Rank with Address Binding]
The DHCP Server Selection option specifies a mechanism for an The DHCP Server Selection option specifies a mechanism for an
administrator to determine the policy governing how a client chooses administrator to determine the policy governing how a client chooses
among multiple DHCP offers. In this profile, Profile 1, the among multiple DHCP offers. In this profile, Profile 1, the
skipping to change at page 9, line 37 skipping to change at line 430
B.1 DHCP Server Selection Option Format B.1 DHCP Server Selection Option Format
The code for this option is TBD, and its length is 4 bytes. The code for this option is TBD, and its length is 4 bytes.
Code Len Priority Code Len Priority
+-------+-------+---------+----------+ +-------+-------+---------+----------+
| TBD | 2 | r |flags|0000| | TBD | 2 | r |flags|0000|
+-------+-------+---------+----------+ +-------+-------+---------+----------+
where: where:
r = rank, or relative priority, of server (higher order 8 bits) r = rank, or relative priority, of server (higher order
8 bits)
flags = b `xAxP'' where: flags = b `xAxP'' where:
x = reserved, must be x'0' x = reserved, must be x'0'
A = offer contains currently active lease for client A = offer contains currently active lease for client
P = offer contain previously active lease available to client P = offer contain previously active lease available
to client
0000 = bits reserved for future use; must be x'0' 0000 = bits reserved for future use; must be x'0'
Here, the priority field is actually a concatenation of the "rank", Here, the priority field is actually a concatenation of the "rank",
and the "address binding" fields. The use of the rank field is and the "address binding" fields. The use of the rank field is
described in Profile 0. The address binding field indicates whether described in Profile 0. The address binding field indicates whether
this DHCPOFFER represents a currently active (A-flag) or previous (P- this DHCPOFFER represents a currently active (A-flag) or previous (P-
flag) address lease binding. flag) address lease binding.
B.2 DHCP Server Behavior B.2 DHCP Server Behavior
In addition to the setting the "rank" value as described in Profile In addition to the setting the "rank" value as described in Profile
0, the address binding field MUST be set according to whether the 0, the address binding field MUST be set according to whether the
OFFER contains an currently active address binding for the client (A-
DRAFT DHCP Server Selection Option November 1998 flag set, P-flag cleared), a previous binding (P-flag cleared, A-flag
set), or no previous association (A- and P-flags cleared).
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 The "rank" and "flags" values used consistently (i.e. by all DHCP
servers serving a subnet) enables a client to select a DHCPOFFER servers serving a subnet) enables a client to select a DHCPOFFER
representing the highest rank and, when one or more offers are of representing the highest rank and, when one or more offers are of
equal rank, an active or (else) previous address binding. equal rank, an active or (else) previous address binding.
B.3 Application Notes B.3 Application Notes
The primary reason for using the "address binding" field is to The primary reason for using the "address binding" field is to
minimize the number of DNS updates which are required due to changes minimize the number of DNS updates which are required due to changes
skipping to change at page 10, line 47 skipping to change at line 489
C.1 DHCP Server Selection Option Format C.1 DHCP Server Selection Option Format
The code for this option is TBD, and its length is 4 bytes. The code for this option is TBD, and its length is 4 bytes.
Code Len Priority Code Len Priority
+-------+-------+---------+----------+ +-------+-------+---------+----------+
| TBD | 2 | r | v |0000| | TBD | 2 | r | v |0000|
+-------+-------+---------+----------+ +-------+-------+---------+----------+
where: where:
r = rank, or relative priority, of server (higher order 8 bits) r = rank, or relative priority, of server
v = percentage of available leases remaining in pool , calculated (higher order 8 bits)
as: v = (#remaining addresses / #total addresses)*100 / 6 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' 0000 = bits reserved for future use; must be x'0'
Here, the priority field is actually a concatenation of the "rank" Here, the priority field is actually a concatenation of the "rank"
field and the "address availability" field. The use of the rank field and the "address availability" field. The use of the rank
field is described in Profile 0. The address availability field field is described in Profile 0. The address availability field
DRAFT DHCP Server Selection Option November 1998
expresses the number of addresses currently available in a server expresses the number of addresses currently available in a server
relative to the number originally defined in the pool (expressed as a relative to the number originally defined in the pool (expressed as a
percentage and as calculated above). percentage and as calculated above).
C.2 DHCP Server Behavior C.2 DHCP Server Behavior
In addition to the setting the "rank" value as described in Profile In addition to the setting the "rank" value as described in Profile
0, the address availability field MUST be set according to the 0, the address availability field MUST be set according to the
relative number of addresses remaining "v", as expressed as an relative number of addresses remaining "v", as expressed as an
integer representing a percentage and calculated as follows: integer representing a percentage and calculated as follows:
skipping to change at page 12, line 5 skipping to change at line 548
A, thus depleting its pool at a much faster rate than B. Now suppose 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 server B encounters a failure or is taken out of operation for
maintenance. Server A, with perhaps very few addresses remaining for maintenance. Server A, with perhaps very few addresses remaining for
allocation, is left to service the entire subnet. allocation, is left to service the entire subnet.
DHCP Server Selection based on address availability can be used to DHCP Server Selection based on address availability can be used to
maintain a balance of addresses across aggregated servers and thus maintain a balance of addresses across aggregated servers and thus
optimize availability of services in the event of a server becomes optimize availability of services in the event of a server becomes
inoperative (e.g., for maintenance or due to failure). inoperative (e.g., for maintenance or due to failure).
DRAFT DHCP Server Selection Option November 1998
Appendix D: Profile 3 [Rank, with Address Balancing, Binding] Appendix D: Profile 3 [Rank, with Address Balancing, Binding]
The DHCP Server Selection Profiles 0, 1, and 2 introduce mechanisms The DHCP Server Selection Profiles 0, 1, and 2 introduce mechanisms
to allow DHCP clients to differentiate between DHCPOFFERs from to allow DHCP clients to differentiate between DHCPOFFERs from
servers based on a "rank", "previous address binding", and "address servers based on a "rank", "previous address binding", and "address
availability". In Profile 3, these mechanisms are all combined into availability". In Profile 3, these mechanisms are all combined into
a single priority system with the given preference of: a single priority system with the given preference of:
1. rank 1. rank
2. address availability 2. address availability
3. previous address binding 3. previous address binding
D.1 DHCP Server Selection Option Format D.1 DHCP Server Selection Option Format
The code for this option is TBD, and its length is 4 bytes. The code for this option is TBD, and its length is 4 bytes.
Code Len Priority Code Len Priority
+-------+-------+---------+---------+ +-------+-------+---------+---------+
| TBD | 2 | r | v |flags| | TBD | 2 | r | v |flags|
+-------+-------+---------+---------+ +-------+-------+---------+---------+
where: where:
r = rank, or relative priority, of server (higher order 4 bits) r = rank, or relative priority, of server
v = percentage of available leases remaining in pool (lower order 4 bits) (higher order 4 bits)
calculated as: v = (#remaining addresses / #total addresses) / 6 v = percentage of available leases remaining in pool
(lower order 4 bits)
calculated as:
v = (#remaining addresses / #total addresses) / 6
flags = b`xAxP' where: flags = b`xAxP' where:
x = reserved, must be x'0' x = reserved, must be x'0'
A = offer contains currently active lease for client A = offer contains currently active lease for client
P = offer contain previously active lease available to client P = offer contains previously active
lease available to client
The priority field is actually a concatenation of the "rank", The priority field is actually a concatenation of the "rank",
"address availability, and "flags" field. The "flags" field, "address availability, and "flags" field. The "flags" field,
represented in the lower order byte, can be used to instruct the represented in the lower order byte, can be used to instruct the
client to give preference to offers from servers which have a client to give preference to offers from servers which have a
currently active or recently expired lease association. The priority currently active or recently expired lease association. The priority
field, represented in the high order byte, can be used to instruct 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 the client to accept a lease from a server according to some other
criteria (see "DHCP Server Behavior" below). criteria (see "DHCP Server Behavior" below).
skipping to change at page 13, line 5 skipping to change at line 600
0,1,2,3 (2 bits)? 0,1,2,3 (2 bits)?
D.2 DHCP Server Behavior D.2 DHCP Server Behavior
A DHCP server offering support for the DHCP Server Selection option A DHCP server offering support for the DHCP Server Selection option
MUST support and set all three fields as described in Profiles 0, 1, MUST support and set all three fields as described in Profiles 0, 1,
and 2. and 2.
D.3 Application Notes D.3 Application Notes
DRAFT DHCP Server Selection Option November 1998
Using the given combination and preference of DHCP Server Selection Using the given combination and preference of DHCP Server Selection
mechanisms, a client will choose the DHCPOFFER with the highest mechanisms, a client will choose the DHCPOFFER with the highest
designated rank. In the event the highest rank servers are designated rank. In the event the highest rank servers are
aggregated, the aggregated server with best address availability aggregated, the aggregated server with best address availability
status will be selected. Given equal rank and address availability status will be selected. Given equal rank and address availability
status, preference for an active or (else) previous address binding status, preference for an active or (else) previous address binding
may determine the selection. may determine the selection.
Appendix E: Profile 4 [Rank with Binding, Address Balancing] Appendix E: Profile 4 [Rank with Binding, Address Balancing]
skipping to change at page 13, line 31 skipping to change at line 624
(assuming identical server rank "r" values]. (assuming identical server rank "r" values].
E.1 DHCP Server Selection Option Format E.1 DHCP Server Selection Option Format
The code for this option is TBD, and its length is 4 bytes. The code for this option is TBD, and its length is 4 bytes.
Code Len Priority Code Len Priority
+-------+-------+---------+----------+ +-------+-------+---------+----------+
| TBD | 2 | r |flags| v | | TBD | 2 | r |flags| v |
+-------+-------+---------+----------+ +-------+-------+---------+----------+
where: where:
r = rank, or relative priority, of server (higher order 4 bits) r = rank, or relative priority, of server
v = percentage of available leases remaining in pool (lower order 4 bits) (higher order 4 bits)
calculated as: v = (#remaining addresses / #total addresses) / 6 v = percentage of available leases remaining in pool
(lower order 4 bits)
calculated as:
v = (#remaining addresses / #total addresses) / 6
flags = b`xAxP' where: flags = b`xAxP' where:
x = reserved, must be x'0' x = reserved, must be x'0'
A = offer contains currently active lease for client A = offer contains currently active lease for client
P = offer contain previously active lease available to client P = offer contain previously active lease available
to client
E.2 Application Notes E.2 Application Notes
Using the given combination and preference of DHCP Server Selection Using the given combination and preference of DHCP Server Selection
mechanisms, a client will choose a DHCPOFFER with the highest mechanisms, a client will choose a DHCPOFFER with the highest
designated rank. In the event the highest rank servers are designated rank. In the event the highest rank servers are
aggregated, the aggregated server with an active or (else) previous aggregated, the aggregated server with an active or (else) previous
address binding will be selected. Given equal rank and binding address binding will be selected. Given equal rank and binding
values, preference for the server best address availability status values, preference for the server best address availability status
may determine the selection. may determine the selection.
DRAFT DHCP Server Selection Option November 1998
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998,1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/