idnits 2.17.1 draft-ietf-dhc-sso-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 674 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 208 has weird spacing: '...ries of conne...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2000) is 8777 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Glenn Stump, IBM 2 INTERNET DRAFT Pratik Gupta, IBM 3 Obsoletes: Ralph Droms, Bucknell University 4 Bill Sommerfeld, Integrated Systems 5 October 1999 6 Expires April 2000 8 The Server Selection Option for DHCP 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This option is provided by DHCP servers to DHCP clients so that 35 clients may optionally select from among multiple offers received 36 from DHCP servers in the network offer from a DHCP. The information 37 contained in this option is a 16-bit unsigned integer which 38 represents a value indicating the priority of the offer in which this 39 option is contained. 41 Several server profiles are presented in appendices showing different 42 ways in which the option can be used by a set of servers. Regardless 43 of the profile, the client behavior is the same. 45 1. Requirements Terminology 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [3]. 51 2. DHCP Terminology 53 o "DHCP client" 55 A DHCP client or "client" is an Internet host using DHCP to obtain 56 configuration parameters such as a network address. 58 o "DHCP server" 60 A DHCP server or "server" is an Internet host that returns 61 configuration parameters to DHCP clients. 63 3. The DHCP Server Selection Option 65 DHCP [1] provides a powerful mechanism for automating and 66 centralizing the administration of IP host configuration and has 67 become a critical service in many large IP networks. Because of its 68 importance in networks and because it can create a single point of 69 failure for network operations (from a DHCP client's perspective), 70 many network administrators choose to deploy many DHCP in order to 71 enhance availability and/or performance of DHCP services. 73 However, for networks with multiple DHCP servers, the DHCP protocol 74 does not provide a means by which a DHCP client may select from among 75 the DHCP server offers according to policy determined by the network 76 administrator. The protocol specification [1] currently states that: 78 "DHCP clients are free to use any strategy in selecting a DHCP server 79 among those from which the client receives a DHCPOFFER message." 81 Thus, currently, client "policy", of which there is no 82 standardization, determines which offer is selected. In practice, 83 most vendor's implementation of policy here is very basic (e.g., 84 first offer received or first acceptable offer received) and is 85 "hard-coded" (i.e., non-configurable). 87 A mechanism which enables a server-based policy for determining how 88 clients select among DHCP offers would allow a network administrator 89 better control of the manner in which addresses are allocated across 90 the multiple DHCP servers. This type of control takes on increased 91 importance considering that IP address spaces cannot generally be 92 shared across DHCP servers, thus requiring network administrators to 93 divide the available addresses among multiple DHCP servers. 95 This document specifies an option that can be configured in DHCP 96 servers and which can influence how DHCP clients select an offer from 97 among those servers. The option described in this document is a new 98 DHCP option [2]. 100 This document also presents several server profiles showing how this 101 option can be used by administrators to effect various policies. 102 Regardless of the profile in use, the operation of the client is the 103 same -- the profiles listed are just different ways of assigning 104 priorities to dhcp servers. 106 3.1 Motivation 108 In general, the motivation for inventing the DHCP Server Selection 109 option originates from shortcomings identified in networks where 110 multiple DHCP servers are used enhance DHCP serving performance, 111 availability, or both. Specifically, these problems are: 113 1. Server Segregation 114 2. Server Aggregation 115 3. Server Introduction and Deprecation 116 4. DNS IP Address Mapping Stability 118 There may well be others which are important - or will be important 119 given new capabilities in the future - and not listed above. The 120 DHCP Server Selection mechanism defined herein must be flexible 121 enough to accommodate future requirements. 123 3.1.1 Server Segregation: Differentiating Servers Based on Varying 124 Priorities 126 Multiple DHCP servers can also be segregated to differentiate the 127 importance or roles of some DHCP server or servers vs. others. The 128 simplest and most common example here is where one DHCP server is 129 intended as a "primary" or "preferred" server for a subnet while some 130 other server is intended as a "secondary" or "backup" server capacity 131 in the case the primary fails. Typically, the preferred server(s) 132 will have the most number of available addresses and the backups have 133 some lesser number, which are only intended for use when the 134 preferred server(s) fail or their addresses are depleted. Again, all 135 servers are assumed to provide an equivalent set of options to a 136 requesting client. 138 Segregated DHCP server deployments present two fundamental problems 139 for today's DHCP implementations: 141 1. There is no standard means for a client to differentiate which 142 of many equivalent offers to accept. Assuming that most client 143 implementations will accept the first of many equivalent offers 144 received, a "backup" server's address pool will be depleted each 145 time its offers are served first to a client. This may happen 146 frequently, for example, during times of peak loads on the 147 preferred servers. 149 2. Once an address lease from an "alternate" DHCP server is selected 150 (for any reason), that address will likely be re-selected on sub- 151 sequent client reboot/init-reboots. 153 A mechanism which enables DHCP clients to select an offer based on an 154 administrative preference by encouraging clients to always select a 155 preferred DHCP server (or order of servers) over others who respond 156 in the network. 158 DISCUSSION: 159 Such a mechanism could also help in preventing DHCP service 160 disruption due to the accidental introduction of rogue DHCP 161 servers. That is, if all clients would be configured to choose 162 offers with the DHCP Server Selection when present, and all DHCP 163 Server Vendors would disable the option by default, then a DHCP 164 offer from a rogue DHCP server accidentally started by a novice 165 would essentially be ignored. Is this worth mentioning as a 166 motivation? 168 3.1.2 Server Aggregation: Grouping Servers of Equal Priority 170 Multiple DHCP servers, typically two, which have essentially 171 equivalent configuration characteristics - typically in terms of the 172 options served and the number of addresses available -- be aggregated 173 to enhance the responsiveness and availability of DHCP services to a 174 particular subnet. 176 However, in the event that one of the DHCP servers responds more 177 quickly than others the number of addresses available at one server 178 (e.g., a "fast" server) may be disproportionately low. Thus, failure 179 of another server in the aggregated set (e.g., the other, "slower" 180 server) will cause a disproportionately high risk in availability of 181 DHCP services (e.g., when a slow server, with more available 182 addresses, fails or is removed from operation temporarily). 184 A mechanism which enables DHCP clients to select an offer based on 185 server- administrated preference could allow clients to choose leases 186 from among servers in a way which could maintain a prescribed balance 187 of address availability across servers (by maintaining a balance in 188 the relative address depletion rates). 190 3.1.3 DHCP Server Introduction or Deprecation 192 Currently, the process of changing the number of DHCP servers in a 193 network cannot generally be done gradually or gracefully because, 194 currently, there is no standard means of allowing servers to share IP 195 address spaces. A mechanism which enables DHCP clients to select an 196 offer based on an administrative preference could help in this 197 process by identifying particular DHCP servers to (or from) which 198 clients should "migrate" (rather than continuing to use an existing 199 server). 201 3.1.4 DNS Address Mapping Stability 203 Regardless of whether multiple DHCP servers are aggregated, 204 segregated, or a combination or both, a "mobile" DHCP client which... 205 1. moves frequently across many networks or subnetworks, and/or. 206 2. does not keep track of which leases are active beyond their 207 current lease. 208 single subnet over a series of connections and reconnections. This 209 is due to the fact that, the client would not necessarily choose a 210 lease based on an active or previous lease association since it is 211 not instructed to do so and/or is no aware that one exists. 213 In network environments where either dynamic DNS updates are not 214 employed or where there is a desire to minimize the number of updates 215 to DNS mappings, a mechanism to identify a lease representing a 216 previous address association can be used to, in effect, reduce the 217 number of changes in a DNS host-name-to-address mapping (i.e., A-RR). 219 3.2 DHCP Server Selection Option Format 221 The code for this option is TBD, and its length is 4 bytes. 222 Code Len Priority 223 +-------+-------+---------+---------+ 224 | TBD | 2 | p | 225 +-------+-------+---------+---------+ 227 where: "p" is an unsigned 16 bit integer representing the 228 priority value chosen for the 229 server (x'0000'- x'FFFF', inclusive). 231 DISCUSSION: 232 Is 16 bits the right number of bits, as opposed to 8 or 32? 234 It is envisioned that this field can be used in many ways to 235 accomplish various system behavior across servers. However, the 236 values within this field must be administered consistently across all 237 DHCP servers in "the system" (i.e., those serving a particular 238 subnet) and across DHCP server vendors (so that the same basic 239 capabilities are administered) in order to achieve the desired 240 behaviors. 242 To that end, the policies for acceptable uses of the priority field 243 will be directed through the specification of DHCP Server Selection 244 option "profiles", which will be maintained - at least for now -- as 245 appendices to this document. Each profile will list how the priority 246 field value is derived, what DHCP serving behaviors are possible, and 247 how these behaviors are achieved. 249 4. DHCP Client Behavior 251 A client supporting the DHCP Server Selection option MUST use the 252 DHCP Server Selection option as the primary discriminator for 253 selecting among multiple offers from servers. The highest priority 254 value gets first preference. If two DHCP Server Selection priority 255 values are equivalent, then the DHCP client can use other mechanisms 256 as described in RFC 2131 to choose among the offers. 258 DISCUSSION: Should the client be required to use the DHCP Server 259 Selection offer if present or only as a tie-breaker if the offers are 260 equivalent (in terms of options offered)? In general, how should this 261 option relate to other decision factors (implicit or explicit). 263 5. DHCP Server Behavior 265 When a DHCP server supports the DHCP Server Selection option, the 266 server MUST select a value for the field according to the policy set 267 forth by a selected DHCP Server Selection Option "profile". The set 268 of standardized DHCP Server Selection profiles will be maintained by 269 the IETF DHC Working Group. The current list of profiles under 270 consideration is maintained in the appendices of this document. 272 It is intended that all of the DHCP servers serving a particular 273 subnet or set of hosts MUST support the same profile in order to 274 achieve the associated/desired DHCP service behavior for that subnet 275 or set of hosts. 277 6. Security Considerations 279 DHCP currently provides no authentication or security mechanisms. 280 Potential exposures to attack are discussed is section 7 of the 281 protocol specification [1]. 283 The server selection option might be used to redirect DHCP clients to 284 accept configuration parameters from a "bad guy" DHCP server. 286 7. References 288 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 289 March 1997. 291 [2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor 292 Extensions", RFC 2132, March 1997. 294 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 295 Levels," RFC 2119, March 1997. 297 8. Author Information 299 Pratik Gupta 300 IBM, Inc. 301 4205 S.Miami Blvd 302 Research Triangle Park, NC 27709 303 Phone: (919)254-5616 304 email: pratik_gupta@vnet.ibm.com 306 Glenn Stump 307 IBM, Inc. 308 4205 S.Miami Blvd 309 Research Triangle Park, NC 27709 310 Phone: (919)254-5616 311 email: glennstump@vnet.ibm.com 313 Ralph Droms 314 323 Dana Engineering 315 Bucknell University 316 Lewisburg, PA 17837 317 Phone: (717) 524-1145 318 email: droms@bucknell.edu 320 Bill Sommerfeld 321 Integrated Systems, Inc. 322 1 Tara Boulevard suite 403 323 Nashua NH 03062 324 Phone: (603) 897 2060 325 email: sommerfeld@alum.mit.edu 327 Appendix A: Profile 0 [Rank (only)] 329 The DHCP Server Selection option specifies a mechanism for an 330 administrator to determine the policy governing how a client chooses 331 among multiple DHCP offers. In this profile, Profile 0, the 332 selection criteria used to govern DHCPOFFER selection policy is a 333 simple, relative "ranking" value. That is, a client will select the 334 offer from the server with the highest designated priority. 336 A.1 DHCP Server Selection Option Format 338 The code for this option is TBD, and its length is 4 bytes. 339 Code Len Priority 340 +-------+-------+---------+----------+ 341 | TBD | 2 | r | reserved | 342 +-------+-------+---------+----------+ 344 where: 345 r = rank, or relative priority, of server (higher order 8 346 bits) 347 reserved = reserved for future use; must be x'00' 349 The priority field is actually a concatenation of the "rank", 350 "address" availability, and "flags" field. The "flags" field, 351 represented in the lower order byte, can be used to instruct the 352 client to give preference to offers from servers which have a 353 currently active or recently expired lease association. The priority 354 field, represented in the high order byte, can be used to instruct 355 the client to accept a lease from a server according to some other 356 criteria (see "DHCP Server Behavior" below). 358 A.2 DHCP Server Behavior 360 When a server supports the "rank" field, the value can be statically 361 pre-configured or dynamically calculated and set to any integer 362 between x'00' and x'FF', inclusive. The values can be coordinated 363 across DHCP servers to achieve the desired priority system behavior. 365 A.3 Application Notes 367 The DHCP Server Selection option allows the DHCP/network 368 administrator to control DHCP services characteristics by influencing 369 the way addresses are allocated across a set of DHCP servers. The 370 administrator may wish to configure all of the servers to have equal 371 serving priority or to configure some to have a greater priority than 372 others. Further, not only can the network administrator prescribe an 373 address allocation scheme across DHCP servers, but the option can 374 also be used to enable the servers to return to the prescribed state 375 in the event that a server failure resulted in an imbalance. 377 The following outlines how the DHCP Server Selection option can be 378 used in each of these situations to achieve the desired service 379 behavior. Note that these scenarios presume that there are no DHCP 380 server-to-server coordination mechanisms which could be used to 381 synchronize the server's databases and effectively share address 382 spaces. 384 A.3.1 Server Segregation 386 DHCP servers which are assigned different rank values, "r", are 387 viewed by DHCP clients as having varying priorities. That is, the 388 DHCP servers are segregated according to a distinct priority system 389 (set by the DHCP system administrator). Clients will choose an offer 390 received from the server with the highest assigned rank value, "r". 392 Once a client can differentiate priorities among DHCP servers, the 393 DHCP administrator can manipulate the priorities across DHCP servers 394 to affect the DHCP serving system behavior, such as: 395 - primary-and-backup 396 - graceful addition or deletion of DHCP servers 398 A.3.2 Server Aggregation 400 DHCP servers which are assigned the same rank value, "r", are viewed 401 by DHCP clients as equal. That is, the servers are an aggregated set 402 of equivalent servers, and offers from equivalent servers can be 403 selected using some other criteria (e.g., first offer received). 405 Appendix B: Profile 1 [Rank with Address Binding] 407 The DHCP Server Selection option specifies a mechanism for an 408 administrator to determine the policy governing how a client chooses 409 among multiple DHCP offers. In this profile, Profile 1, the 410 selection criteria used to govern server selection policy is a 411 simple, relative "ranking" system plus a mechanism which can be used 412 to further differentiate equally-ranked servers based on a preference 413 for offers representing a previous address binding. That is, a 414 client will select an offer from a particular server because that 415 server has the highest designated priority, and, in the event that 416 one or more servers have equal priority (i.e, are aggregated), the 417 client will select the offer from the server having, in order of 418 preference, an active address binding or a previous binding which is 419 still available to the client. 421 B.1 DHCP Server Selection Option Format 423 The code for this option is TBD, and its length is 4 bytes. 424 Code Len Priority 425 +-------+-------+---------+----------+ 426 | TBD | 2 | r |flags|0000| 427 +-------+-------+---------+----------+ 429 where: 430 r = rank, or relative priority, of server (higher order 431 8 bits) 432 flags = b `xAxP'' where: 433 x = reserved, must be x'0' 434 A = offer contains currently active lease for client 435 P = offer contain previously active lease available 436 to client 437 0000 = bits reserved for future use; must be x'0' 439 Here, the priority field is actually a concatenation of the "rank", 440 and the "address binding" fields. The use of the rank field is 441 described in Profile 0. The address binding field indicates whether 442 this DHCPOFFER represents a currently active (A-flag) or previous (P- 443 flag) address lease binding. 445 B.2 DHCP Server Behavior 447 In addition to the setting the "rank" value as described in Profile 448 0, the address binding field MUST be set according to whether the 449 OFFER contains an currently active address binding for the client (A- 450 flag set, P-flag cleared), a previous binding (P-flag cleared, A-flag 451 set), or no previous association (A- and P-flags cleared). 453 The "rank" and "flags" values used consistently (i.e. by all DHCP 454 servers serving a subnet) enables a client to select a DHCPOFFER 455 representing the highest rank and, when one or more offers are of 456 equal rank, an active or (else) previous address binding. 458 B.3 Application Notes 460 The primary reason for using the "address binding" field is to 461 minimize the number of DNS updates which are required due to changes 462 in IP address. 464 Appendix C: Profile 2 [Rank with Address Balancing] 466 The DHCP Server Selection option specifies a mechanism for an 467 administrator to determine the policy governing how a client chooses 468 among multiple DHCP offers. In this profile, Profile 2, the 469 selection criteria used to govern server selection policy is a 470 simple, relative "ranking" system plus a mechanism which can be used 471 to further differentiate equally-ranked servers based on the 472 availability of address leases at the servers . That is, a client 473 will select an offer from a particular server because that server has 474 the highest designated priority, and, in the event that one or more 475 servers have equal priority (i.e., are aggregated), the client will 476 select the offer from the server with the most available addresses 477 (relative to the total number of addresses available for allocation 478 by the server). 480 C.1 DHCP Server Selection Option Format 482 The code for this option is TBD, and its length is 4 bytes. 483 Code Len Priority 484 +-------+-------+---------+----------+ 485 | TBD | 2 | r | v |0000| 486 +-------+-------+---------+----------+ 488 where: 489 r = rank, or relative priority, of server 490 (higher order 8 bits) 491 v = percentage of available leases remaining in pool, 492 calculated as: 493 v = (#remaining addresses / #total addresses)*100 / 6 494 0000 = bits reserved for future use; must be x'0' 496 Here, the priority field is actually a concatenation of the "rank" 497 field and the "address availability" field. The use of the rank 498 field is described in Profile 0. The address availability field 499 expresses the number of addresses currently available in a server 500 relative to the number originally defined in the pool (expressed as a 501 percentage and as calculated above). 503 C.2 DHCP Server Behavior 505 In addition to the setting the "rank" value as described in Profile 506 0, the address availability field MUST be set according to the 507 relative number of addresses remaining "v", as expressed as an 508 integer representing a percentage and calculated as follows: 509 v = INT[(#remaining addresses / #total addresses)*100/ 6] 510 The "rank" and "v" values used consistently (i.e. by all DHCP servers 511 serving a subnet) enables a client to select a lease from the highest 512 ranked server with the best availability of addresses. 514 C.3 Application Notes 516 The important point to note here is that the client will select the 517 highest rank server with "the best address availability", where "best 518 server" means the one with the largest percentage of addresses 519 available remaining from its original pool. In other words, the 520 "system" of DHCP servers using this Profile 2 will tend to maintain 521 the original, prescribed "balance" of addresses allocated across the 522 (equivalent) servers. 524 Maintaining this prescribed balance of address availability is 525 important in cases one of the DHCP servers in an aggregated set 526 responds more quickly than others and therefore depletes its 527 addresses pools at a disproportionately higher rate than others in 528 the set.. Thus, failure of one of the other servers in the set will 529 cause a disproportionately high risk in availability of DHCP 530 services. 532 To illustrate, suppose there is a set of two equivalent DHCP servers, 533 A and B, which service a particular subnet. Each server is assigned 534 half of the available address space to allocate to clients. Now 535 suppose server A responds to clients' DHCPDISCOVERs significantly 536 faster than server B. Without some other means for expressing 537 preference, the clients will likely repeatedly choose DHCPOFFERs from 538 A, thus depleting its pool at a much faster rate than B. Now suppose 539 server B encounters a failure or is taken out of operation for 540 maintenance. Server A, with perhaps very few addresses remaining for 541 allocation, is left to service the entire subnet. 543 DHCP Server Selection based on address availability can be used to 544 maintain a balance of addresses across aggregated servers and thus 545 optimize availability of services in the event of a server becomes 546 inoperative (e.g., for maintenance or due to failure). 548 Appendix D: Profile 3 [Rank, with Address Balancing, Binding] 550 The DHCP Server Selection Profiles 0, 1, and 2 introduce mechanisms 551 to allow DHCP clients to differentiate between DHCPOFFERs from 552 servers based on a "rank", "previous address binding", and "address 553 availability". In Profile 3, these mechanisms are all combined into 554 a single priority system with the given preference of: 555 1. rank 556 2. address availability 557 3. previous address binding 559 D.1 DHCP Server Selection Option Format 560 The code for this option is TBD, and its length is 4 bytes. 561 Code Len Priority 562 +-------+-------+---------+---------+ 563 | TBD | 2 | r | v |flags| 564 +-------+-------+---------+---------+ 566 where: 567 r = rank, or relative priority, of server 568 (higher order 4 bits) 569 v = percentage of available leases remaining in pool 570 (lower order 4 bits) 571 calculated as: 572 v = (#remaining addresses / #total addresses) / 6 573 flags = b`xAxP' where: 574 x = reserved, must be x'0' 575 A = offer contains currently active lease for client 576 P = offer contains previously active 577 lease available to client 579 The priority field is actually a concatenation of the "rank", 580 "address availability, and "flags" field. The "flags" field, 581 represented in the lower order byte, can be used to instruct the 582 client to give preference to offers from servers which have a 583 currently active or recently expired lease association. The priority 584 field, represented in the high order byte, can be used to instruct 585 the client to accept a lease from a server according to some other 586 criteria (see "DHCP Server Behavior" below). 588 DISCUSSION: 589 Can we cram all fields into 8 bits if we limit rank values to 590 0,1,2,3 (2 bits)? 592 D.2 DHCP Server Behavior 594 A DHCP server offering support for the DHCP Server Selection option 595 MUST support and set all three fields as described in Profiles 0, 1, 596 and 2. 598 D.3 Application Notes 600 Using the given combination and preference of DHCP Server Selection 601 mechanisms, a client will choose the DHCPOFFER with the highest 602 designated rank. In the event the highest rank servers are 603 aggregated, the aggregated server with best address availability 604 status will be selected. Given equal rank and address availability 605 status, preference for an active or (else) previous address binding 606 may determine the selection. 608 Appendix E: Profile 4 [Rank with Binding, Address Balancing] 610 Profile 4 is identical to Profile 3, with the exception that the 611 bindings flags field, "flags" is swapped with the "address 612 availability" field, "v", thus yielding client preference to an 613 active or previous binding over a server's address depletion status 614 (assuming identical server rank "r" values]. 616 E.1 DHCP Server Selection Option Format 618 The code for this option is TBD, and its length is 4 bytes. 619 Code Len Priority 620 +-------+-------+---------+----------+ 621 | TBD | 2 | r |flags| v | 622 +-------+-------+---------+----------+ 623 where: 624 r = rank, or relative priority, of server 625 (higher order 4 bits) 626 v = percentage of available leases remaining in pool 627 (lower order 4 bits) 628 calculated as: 629 v = (#remaining addresses / #total addresses) / 6 630 flags = b`xAxP' where: 631 x = reserved, must be x'0' 632 A = offer contains currently active lease for client 633 P = offer contain previously active lease available 634 to client 636 E.2 Application Notes 638 Using the given combination and preference of DHCP Server Selection 639 mechanisms, a client will choose a DHCPOFFER with the highest 640 designated rank. In the event the highest rank servers are 641 aggregated, the aggregated server with an active or (else) previous 642 address binding will be selected. Given equal rank and binding 643 values, preference for the server best address availability status 644 may determine the selection. 646 Full Copyright Statement 648 Copyright (C) The Internet Society (1998,1999). All Rights Reserved. 650 This document and translations of it may be copied and furnished to 651 others, and derivative works that comment on or otherwise explain it 652 or assist in its implementation may be prepared, copied, published 653 and distributed, in whole or in part, without restriction of any 654 kind, provided that the above copyright notice and this paragraph are 655 included on all such copies and derivative works. However, this 656 document itself may not be modified in any way, such as by removing 657 the copyright notice or references to the Internet Society or other 658 Internet organizations, except as needed for the purpose of 659 developing Internet standards in which case the procedures for 660 copyrights defined in the Internet Standards process must be 661 followed, or as required to translate it into languages other than 662 English. 664 The limited permissions granted above are perpetual and will not be 665 revoked by the Internet Society or its successors or assigns. 667 This document and the information contained herein is provided on an 668 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 669 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 670 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 671 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 672 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.