idnits 2.17.1 draft-ietf-dhc-option-review-and-namespace-02.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 52 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (March 2000) is 8809 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) == Unused Reference: '3' is defined on line 681, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1048 (ref. '3') (Obsoleted by RFC 1084, RFC 1395, RFC 1497, RFC 1533) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2373 (ref. '6') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Michael Carney 3 Dynamic Host Configuration Working Group Sun Microsystems, Inc 4 Category: Standards Track March 2000 5 INTERNET-DRAFT Expires: September 2000 7 New Option Review Guidelines and Additional Option Namespace 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "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 Comments regarding this draft should be sent to dhcp-v4@bucknell.edu 34 Abstract 36 This document outlines deficiencies that have become evident since 37 RFC 2131 and RFC 2132 were published regarding the allocation of 38 new option codes, the review of drafts covering these new option 39 codes, and the availability of option codes for new parameters. The 40 document then presents proposals for correcting these deficiencies. 42 1. Introduction 44 The rapid and wide-spread adoption of DHCPv4 has lead to an 45 increasing number of new DHCP option and message type drafts under 46 DHC WG review. Experience with the current IANA option code 47 allocation process and the DHC WG draft review process has 48 identified a number of deficiencies, namely: 50 * We're rapidly going through the remaining option codes, and face 51 the possibility of exhausting the remaining codes before the 52 wide-spread adoption of IPv6 is achieved. 54 * There are no guidelines to help the DHC WG and the DHCP 55 community at large gauge the impact of the addition of new 56 message types and options. Some message types and options that 57 have been proposed require changes to the DHCP protocol itself 58 and/or current implementations. Because the adoption of such 59 message types or options has a greater impact on the DHCP 60 community, these message types and options require more 61 scrutiny by the DHC WG and IESG. 63 * Because some options or message types could change the DHCP 64 protocol itself, we need a method of explicitly communicating 65 the change of DHCP versions among implementations. Today, we 66 have no such method. 68 * There is no provision to preserve compatibility with earlier 69 versions of the protocol. 71 Interoperability testing at Connectathon (1997, 1998, and 1999) 72 has shown a reduction in the level of interoperability between 73 implementations. These interoperability problems were found to 74 be due to confusion among implementors about how certain features 75 of the protocol should be implemented. Improvement (tightening) 76 of the general RFC 2131 and RFC 2132 drafts as well as the 77 tightening of new option specifications (using the guidelines 78 defined in this document) will help increase the level of 79 interoperability. 81 1.1 Conventions Used in the Document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [5]. 87 1.2 Terminology 89 RFC 2132-form options The RFC 2132 [2] option block form is 90 currently in use by DHCPv4, and is 91 documented in RFC 2131 [1]. This option 92 form is identified by the BOOTP magic 93 cookie {99, 130, 83, 99}. 95 RFC TBD-form options A new option block form recommendation 96 to alleviate option code exhaustion 97 (described in section 3.6 below). This 98 option form will be identified by a TBD 99 BOOTP magic cookie issued by IANA. 101 2. Review Guidelines 103 We tackle the message type and option code review problem by 104 defining a set of categories based upon upon the impact the 105 adoption of an option or new message type will have on the DHCP 106 community. Option or new message drafts appropriately categorized 107 aid reviewers by helping them evaluate the draft. Once the DHC WG 108 and the draft author(s) agree on the category of the proposed 109 option or message type, that category will be listed explicitly 110 in the abstract of the option or message draft. 112 2.1. Hints for selecting the correct review category 114 A) This option has no relationship to other existing or proposed 115 options. It would not require change of existing DHCP client, 116 server, or BOOTP relay agent implementations. It would not 117 change the version of the DHCP protocol. Its introduction 118 would not invalidate previous version(s) of the DHCP 119 protocol. Is this option better handled by the Service Location 120 Protocol (SLP) [7]? If it provides data which is unrelated 121 to network interface configuration, then the option proposer 122 SHOULD consider the use of SLP for the delivery of this data, 123 if SLP is deployed widely enough to meet her needs. 125 B) This message type has no relationship to other existing or 126 proposed message types. It would not require change of 127 existing DHCP client, server, or BOOTP relay agent 128 implementations. It would not change the version of the DHCP 129 protocol. The message type is useful to the DHCP community at 130 large. 132 C) This option has no relationship to other existing or 133 proposed options or message types. It would not require 134 change of existing DHCP client, server, or BOOTP relay 135 agent implementations. It would not change the version of the 136 DHCP protocol. Its introduction would not invalidate previous 137 version(s) of the DHCP protocol. It isn't a candidate for SLP. 138 Is this option useful to the DHCP community at large (e.g. 139 implementors) or is it specific to a particular 140 implementation? If it is the latter, then the proposer of 141 the option should consider using the encapsulated vendor space 142 available to your implementation to encode this information. 143 Note that most DHCP implementations only support default 144 option types for encapsulated options. (see Section 3.6 below). 146 D) This option has no relationship to other existing or 147 proposed options or message types. It would not require change 148 of existing DHCP client, server, or BOOTP relay agent 149 implementations. It would not change the version of the DHCP 150 protocol. Its introduction would not invalidate previous 151 version(s) of the DHCP protocol. It is not a candidate for 152 SLP or the vendor's option space. Can this option be 153 effectively encoded in the default option type (Section 3.6 154 below)? For example, can it be communicated as a single 155 ASCII string? A list of IP addresses? If so, then one of the 156 default formats should be used. 158 E) This option would have a implicit or explicit relationship 159 between it and other existing options or other proposed 160 options, or the data it represents cannot be carried in a 161 default option type (Section 3.6 below). It MAY change the 162 behavior of existing DHCP client, server, and/or BOOTP relay 163 agent implementations. It would not change the DHCP protocol 164 version. Its introduction would not invalidate previous 165 version(s) of the DHCP protocol. 167 Examples of implicit/explicit option relationships: 169 Option Related Options 170 ------ --------------- 171 Vendor Class Identifier Encapsulated vendor option(s) 172 User Class Identifier Standard option's scope 174 F) This message type would have a implicit or explicit 175 relationship between it and other existing message types or 176 options Its adoption MAY change the behavior of existing DHCP 177 client, server, and/or BOOTP relay agent implementations. It 178 would not change the DHCP protocol version. Its introduction 179 would not invalidate previous version(s) of the DHCP protocol. 181 G) The addition of this option would change Table 3, "Fields and 182 options used by DHCP servers" and/or Table 5, "Fields and 183 options used by DHCP clients" in RFC 2131 [1], and thus 184 change the DHCP protocol. Pre-existing versions / 185 implementations would continue to interoperate. 187 H) The addition of this option or message type would invalidate 188 previous versions of the DHCP protocol, preventing client, 189 server, and/or BOOTP relay agents implementing the earlier 190 version(s) from functioning. 192 Guidelines Review Category 193 ---------- --------------- 194 A None. Use SLP to register and 195 deliver your information. 197 B Category One 199 C None. Use your Vendor-specific 200 option space for your option. 202 D Category One 204 E Category Two 206 F Category Two 208 G Category Three 210 H Category Four 212 2.2. Category One 214 Options in this category MUST NOT require changes to the DHCP 215 protocol, server, client, or BOOTP relay agent implementations. 216 They MAY be either RFC 2132-form or RFC TBD-form options. They MUST 217 NOT be dependent on other options being present or absent. Earlier 218 versions/implementations of the protocol continue to interoperate 219 in the presence of these options. Administrative tools and DHCP 220 protocol debugging tools which generically support the default 221 option types MAY need to be reconfigured in order to permit 222 management of the new option. Options of this type are "payload" 223 options, and MUST be of one of the default option types for the 224 option block form (RFC 2132 or RFC TBD). 226 Acceptance criteria: 228 Working group/IETF community review: Yes. 229 IANA option number registration: Yes. 230 Interoperability testing (2 or more implementations) No. 231 DHCP protocol version change: No. 233 2.3. Category Two 235 Options in this category MUST NOT require changes to the DHCP 236 protocol. They MAY require changes to server, client, relay agent 237 implementations, administrative tools, and DHCP protocol debugging 238 tools. They MAY depend on the presence or absence of other options, 239 as long as those other options are NOT in Table 3 or Table 5 of 240 RFC 2131 [1]. Any dependence on other options MUST be made 241 explicit in the new options draft. Existing versions / 242 implementations of the protocol continue to interoperate in the 243 presence of messages containing category two options. Options of 244 this type are "affect implementation" options. 246 An option MUST be designed in such a way as a reply/response from 247 non-compliant implementations can be easily distinguished from 248 those of compliant implementations. An option MUST NEVER change the 249 interpretation of existing options. The option draft author MUST 250 specify a compliant implementation's behavior if that implement- 251 ation receives a reply/response from a non-compliant implementation. 253 Acceptance criteria: 255 Working group/IETF community review: Yes. 256 IANA option number registration: Yes. 257 Interoperability testing (2 or more implementations) Yes. 258 DHCP protocol version change: No. 260 2.4. Category Three 262 Options in this category EXPLICITLY change the DHCP protocol. They 263 WILL require changes to server, client, and/or relay agent 264 implementations. They MAY depend on the presence or absence of 265 other options. Any dependence on other options MUST be made 266 explicit in the new option draft. The addition of such options 267 result in changes to Table 3, "Fields and options used by DHCP 268 servers" and/or Table 5, "Fields and options used by DHCP clients" 269 in RFC 2131 [1]. Existing versions / implementations of the 270 protocol continue to interoperate in the presence of traffic 271 containing category three options. Administrative tools MUST be 272 changed to support options of this type. DHCP protocol debugging 273 tools would need to be updated to recognize these options. Options 274 of this type are known as "affect protocol" options. The acceptance 275 of a Category Three option results in incrementing the DHCP version 276 option value. 278 An option MUST be designed in such a way as a reply/response from 279 non-compliant implementations can be easily distinguished from 280 those of compliant implementations. The option draft author MUST 281 specify a compliant implementation's behavior if that implement- 282 ation receives a reply/response from a non-compliant 283 implementation. An option MUST NEVER change the interpretation of 284 existing options. Category Three option implementations can easily 285 detect a non-compliant implementation due to the absence of the 286 DHCP version option or a lower than expected version number. 288 Acceptance criteria: 290 Working group/IETF community review: Yes. 291 IANA option number registration: Yes. 292 Interoperability testing (2 or more implementations) Yes. 293 DHCP protocol version change: Yes. 295 2.5. Category Four 297 Options in this category would EXPLICITLY change the DHCP 298 protocol in a non-backward compatible manner. They would require 299 changes to ALL DHCP client, server, and/or BOOTP relay agent 300 implementations. They INVALIDATE one or more of the previous 301 versions of the BOOTP/DHCP protocol. 303 Because category four options invalidate previous versions of the 304 protocol, they are NOT candidates for acceptance. Changes to the 305 the DHCP protocol MUST BE backward compatible. 307 3. New RFC 2132-form options for version, block-type, and parameter 308 request list. 310 We define three new RFC 2132-form options. The first is used by 311 a DHCP client to request a response in a certain option block form. 312 The second option is used by both DHCP clients and servers to 313 explicitly identify the version of protocol used in the messages 314 generated. The final option is used by RFC TBD client 315 implementations to request RFC TBD options from RFC TBD servers. 317 3.1. DHCP Option Block Request Option 319 This option is used by RFC TBD client implementations to request 320 RFC TBD-form replies from RFC TBD server implementations. This 321 option is included in RFC 2132-form DHCPDISCOVERs, INIT-REBOOT 322 DHCPREQUESTs, and DHCPINFORMs to request RFC TBD-form replies. 324 This option MUST NOT be used by DHCP servers in their responses 325 to DHCP clients. 327 The DHCP Option Block Request Option is of the RFC 2132-form, and 328 consists of a single 4 octet string holding the magic cookie of 329 the desired option block form. 331 Code Len Magic cookie 332 +-----+-----+----------------+ 333 | X | 4 | ... | 334 +-----+-----+----------------+ 336 3.2. DHCP Version Option 338 This option represents the DHCP version. DHCP messages without 339 this option are RFC 2131 [1]. The addition of Category Three 340 option(s) (perhaps grouped together) result in a DHCP version 341 change. All implementations supporting versions greater than RFC 342 2131 MUST include the DHCP version option in all messages, 343 generated by both client or server. 345 The DHCP Protocol Version Option is of the RFC 2132-form, and 346 consists of an single unsigned 16bit integer. The first Category 347 Three option accepted by the DHC WG will be assigned version zero 348 (0). 350 Code Len Value 351 +-----+-----+---------+ 352 | Y | 2 |(0-65535)| 353 +-----+-----+---------+ 355 DHCP protocol versions MUST be backward compatible with earlier 356 versions. 358 3.3. RFC TBD Parameter Request List Option 360 This option is used by a RFC TBD DHCP client to request values for 361 the specified configuration parameters. The list of requested 362 parameters is specified as a power of 2n octets, where each 16 bit 363 field carries an unsigned 16bit number from 1-65534 representing 364 valid DHCP option codes defined in RFC 2132 [2] and in separate 365 option specification drafts. Note that at most 128 options can be 366 requested. 368 The client MAY list the options in order of preference. The DHCP 369 server is not required to return the options in the requested 370 order. 372 The RFC TBD parameter request list option is intended for use by 373 RFC TBD DHCP clients and servers ONLY. While a RFC TBD client 374 could include use either (or both) parameter request list options 375 (RFC 2132 code 55 or this option), such a client SHOULD make 376 request its parameters using only the RFC TBD parameter request 377 list option. 379 Code Len Option Codes 380 +-----+-----+-----+-----+-----+-----+--- 381 | Z | 2n | s1 | s2 | ... 383 +-----+-----+-----+-----+-----+-----+--- 385 3.4 Allocation of options from RFC 2132 or RFC TBD option name spaces 387 Allocation of new options from the RFC TBD name space can only 388 occur if we have two (2) or more RFC TBD option name space 389 implementations which have demonstrated interoperability. Such 390 interoperability testing could occur at the next Connectathon 391 event (held late February/early March every year). 393 The selection of which name space from which to allocate an option 394 is left to the DHC WG and IESG, following the process outlined in 395 Ralph Drom's "Procedure for Defining New DHCP Options" [4]. 397 3.5. RFC 2132 Option Block Form 399 For convenience, I have extracted the description of RFC 2132-form 400 options from RFC 2132 [2]. 402 Code Len Value 403 +-----+-----+------- 404 | | | ... 405 +-----+-----+------- 407 Options of this form consist of three single octet fields: code, 408 len, and value. 410 The code value is a single octet (0-255). 0 (pad) and 255 (end) 411 are the only codes that do not follow the code, len, value form. 412 Len is a single octet (0-255) describing the length of the value 413 field. Value contains the data payload. 415 3.6. RFC 2132-form Default Option Types 417 1) Single variable-length ASCII string. 419 2) Single variable-length OCTET string. 421 3) 1-X Multiple of NUMBERs (1, 2, 4, 8 octets each). May consist of 422 a LIST where the list entries are defined as multiple NUMBERs. 424 Example: "A variable-length list of 2 32bit NUMBERs 425 representing the offset and length of a 426 block of data" 428 4) 1-X Multiple of IPv4 addresses. May consist of a LIST where the 429 list entries consist of multiple IP addresses. 431 Example: "A list of static routes (destination, router), ..." 433 If an implementation encounters RFC 2132-form options which it does 434 not understand, it will simply skip over the option (using that 435 option's len field) and continue option processing. This behavior 436 ensures that RFC 2131 compliant implementations safely ignore new 437 options (e.g. the DHCP version option). Current DHCP 438 implementations SHOULD ignore any non-RFC 2132-form option block. 440 3.7. Proposed RFC TBD Option Block Form 442 We propose the creation of the following option block form 443 described below, which greatly increases the option space and size 444 of individual options. We feel that the adoption of this option 445 block form will resolve the approaching RFC 2132 standard option 446 code availability problem. 448 Code Len Data 449 +---------+---------+------------------ 450 | uint16_t| uint16_t| ... 451 +---------+---------+------------------ 453 Code value is a network-order double-octet unsigned value (0- 454 65535). 0 (pad) and 65535 (end) are the only codes that do not 455 follow the code, len, value form. Len is a network-order 456 double-octet unsigned value (0-65535). Data contains Len octets. 458 The first 255 RFC TBD option codes are preassigned for mapping 459 RFC 2132 options into the RFC TBD option space. Because the size 460 limit of options within the RFC TBD option space is much higher 461 than that of options within the RFC 2132 option space, RFC TBD 462 server implementations MUST use care in responding to RFC 2132 463 clients. If the data for a mapped RFC 2132 option would exceed the 464 253 length restriction of RFC 2132 clients, the RFC TBD 465 implementation MUST drop the option from the reply, and SHOULD 466 increment an error count or log a message regarding this event. 467 Note that the creation of multiple instances of RFC 2132 options 468 in order to provide all of the data within the configured RFC TBD 469 option is not workable, since by definition options within the 470 RFC 2132 (and RFC TBD) option space are position-independent, and 471 thus deterministic ordering of data is not possible. 473 3.8. RFC TBD Default Option Types 475 All option types as listed in Section 3.6, and: 477 1) UNICODE string. 479 2) IPv6 addresses(s). Multiple of 16 octets. Encoded within an 480 implementation's configuration table using the text 481 representation as defined by Section 2.2 of RFC 2373 [6]. 483 3) Encapsulated RFC TBD options. For example, New User class, 484 Vendor class-style options. Encapsulated options follow same 485 code, len, value form of RFC TBD options. Overall length 486 specifies limit of encapsulation. 488 4) Mixed-type options. These options are made up of combinations 489 of 3.6/3.8 typed fields. Variable-length typed fields are 490 preceded by a two octet unsigned integer length field. Mixed 491 type options are useful for encoding combinations of data 492 (structures). 494 Example: The following option contains an NVT ASCII string 495 followed by a boolean, followed by a 32bit unsigned integer. 496 Code Len Data 497 +-------+-------+-------+-------------+---+---------------+ 498 | 771 | 17 | 13 |Hello, World!| 1 | 4123782 | 499 +-------+-------+-------+-------------+---+---------------+ 501 5) BOOLEAN. A single octet value which is explicitly TRUE if 502 non-zero, explicitly FALSE if zero (0). Len is always one. 504 4. Behavior of RFC 2132 and RFC TBD Client and Server Implementations 506 4.1 Client Behavior 508 A DHCP client in the INIT state prefers DHCP replies matching the 509 DHCP option block form (RFC 2132 or RFC TBD) and DHCP protocol 510 version of its DHCPDISCOVER. Option block form is preferred over 511 DHCP protocol version. 513 DHCP clients SHOULD always indicate the size of response they 514 can accept using the DHCP MTU option. 516 4.1.1 INIT/INFORM states 518 A client in one of these states pauses to collect replies (DHCP 519 of any type/version or BOOTP replies) for a tunable polling 520 interval (default: 5 seconds). Retransmissions use the algorithm 521 outlined in Section 4.1 of RFC 2131 [1]. 523 Existing RFC 2132-form clients require no change in their behavior 524 as specified in RFC 2131 [1]. 526 RFC 2132-form clients who support a later version of the DHCP 527 protocol include the DHCP version option identifying the version of 528 DHCP protocol they support. They prefer replies matching their 529 protocol version over older versions of DHCP and BOOTP replies. If 530 a RFC 2132-form client selects a reply from a down-rev DHCP protocol 531 server (or BOOTP server), then that client MAY update an error count 532 or log this event. 534 A RFC TBD-form client in one of these states forms the appropriate 535 RFC 2132-form message (DHCPDISCOVER, DHCPINFORM) and includes the 536 DHCP Option Block Request Option (set to the RFC TBD magic cookie) 537 and the DHCP version option if it supports a version greater than 538 that specified in RFC 2131, and sends this message in the manner 539 appropriate for the message type. A RFC TBD-form client 540 prefers RFC TBD-form responses over RFC 2132-form responses. Within 541 responses of a certain option form, responses which match the 542 client's DHCP protocol version are preferred over those responses 543 that are down-rev. If no DHCP responses are received, the client 544 MAY choose a BOOTP response if such a response is available. A RFC 545 TBD-form client MAY use the RFC TBD parameter request option to 546 request options in the RFC TBD option space (section 3.3). 548 In the case of an INIT state client, the DHCPREQUEST used to accept 549 the DHCPOFFER is formed using the option block form and DHCP 550 protocol version of the selected DHCPOFFER. 552 For the duration of the lease, the client MUST form request messages 553 using the option block form and DHCP protocol version of the 554 original DHCPACK (INIT/INFORM) states when verifying existing 555 configuration (INIT-REBOOT DHCPREQUEST), requesting lease 556 extensions (DHCPREQUEST), declining an IP address (DHCPDECLINE), 557 or releasing an IP address (DHCPRELEASE). 559 In summary, a RFC TBD-form DHCP client will prefer RFC TBD-form 560 replies over RFC 2132-form replies. Within replies which match the 561 selected option block form, a client will prefer replies which match 562 its DHCP protocol version. All subsequent traffic is done using the 563 option block form and DHCP protocol version of the accepted 564 DHCPOFFER/DHCPACK. 566 4.2 Server Behavior 568 4.2.1 Option Block Format-independent Server Behavior 570 A server which receives a BOOTP magic cookie it does not understand 571 SHOULD respond with a standard BOOTP reply ONLY if it is explicitly 572 configured to do so. Note that RFC TBD-form requests will appear to 573 RFC 2131 servers as BOOTP requests with an unrecognized magic 574 cookie. In such environments, the RFC 2131 server's ability to 575 respond to BOOTP clients SHOULD be restricted, and RFC TBD servers 576 SHOULD be configured to respond to BOOTP clients. 578 If a DHCPDISCOVER/DHCPINFORM is received which contains a DHCP 579 protocol version option, a server MUST: 581 a) If the DHCP protocol version is down-rev of that supported by 582 the server, the server will format all messages in that 583 earlier version. If the DHCP server does not support the 584 earlier version of the protocol, it MUST drop the request, 585 and MAY update an error counter or log the event. 587 b) If the DHCP protocol version is greater than that supported 588 by the server, it MAY either drop the request or respond to 589 the client using messages of the DHCP protocol version 590 supported by the server. This behavior SHOULD be configurable 591 by the administrator. The server SHOULD choose to delay 592 responding to the up-rev client for a configurable number of 593 seconds, in order to give potential higher-rev servers a 594 chance to reply. 596 c) If the DHCP protocol version matches that of the server, then 597 the server responds immediately (if possible) to the client 598 with the appropriately formatted reply. 600 4.2.2 RFC TBD-form Server Behavior 602 A RFC TBD-form server can identify a RFC TBD-form client by the 603 presence of the DHCP Option Block Request Option with the RFC TBD 604 magic cookie in the option value field in RFC 2132-form requests 605 or RFC TBD-form requests identified by the RFC TBD-form magic 606 cookie. For the following scenarios, assume a RFC TBD-form server 607 has free resources available for allocation. 609 a) If a RFC TBD-form response is requested, it MUST respond with 610 a RFC TBD-form response if it chooses to respond at all. The 611 server SHOULD endeavor to provide the information requested 612 in any present RFC 2132 code 55 (parameter request list 613 option) and/or RFC TBD parameter request list option (Section 614 3.3). 616 b) If a RFC 2132-form response is requested (no DHCP Option Block 617 Request Option is present) and the RFC TBD-form server is 618 explicitly configured to respond to RFC 2132-form clients, it 619 MUST respond with a RFC 2132-form response if it chooses to 620 respond at all. 622 c) If a request is received which contains a DHCP Option Block 623 Request Option with a value it does not recognize, the server 624 MUST either drop the request or respond with a RFC 2132-form 625 response. Its behavior in this situation SHOULD be an 626 administrator-configured option. 628 A DHCP server MUST NOT use the DHCP Option Block Request Option in 629 the messages it generates for DHCP clients. 631 5. Security Considerations 633 Not Applicable. 635 6. Acknowledgements 637 The author would like to gratefully acknowledge the active 638 participation of the following DHCP future panel members: 639 Ralph Droms, Kester Fong, Pratik Gupta, Barr Hibbs, Kim Kinnear, 640 Ted Lemon, Nathan Lane, and Glenn Waters. The author would also 641 like to thank Thomas Narten for his review comments. 643 7. Copyright 645 Copyright (C) The Internet Society (1999). All Rights Reserved. 647 This document and translations of it may be copied and furnished to 648 others, and derivative works that comment on or otherwise explain it 649 or assist in its implementation may be prepared, copied, published 650 and distributed, in whole or in part, without restriction of any 651 kind, provided that the above copyright notice and this paragraph are 652 included on all such copies and derivative works. However, this 653 document itself may not be modified in any way, such as by removing 654 the copyright notice or references to the Internet Society or other 655 Internet organizations, except as needed for the purpose of 656 developing Internet standards in which case the procedures for 657 copyrights defined in the Internet Standards process must be 658 followed, or as required to translate it into languages other than 659 English. 661 The limited permissions granted above are perpetual and will not be 662 revoked by the Internet Society or its successors or assigns. 664 This document and the information contained herein is provided on an 665 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 666 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 667 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 668 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 669 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 671 8. References 673 [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 674 Bucknell University, March 1997. 675 677 [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP 678 Vendor Extension", RFC 2132, March 1997. 679 681 [3] Prindeville, P. "BOOTP Vendor Information Extensions", RFC 1048, 682 McGill University, February 1988. 683 685 [4] Droms, R. "Procedure for Defining New DHCP Options", 687 689 [5] Bradner, "Key words for use in RFCs to Indicate Requirement 690 Levels", RFC 2119, Harvard University, March 1997. 691 693 [6] Hinden R. and Deering, S., "IP Version 6 Addressing 694 Architecture", RFC 2373, Nokia and Cisco Systems, July 1998. 695 697 [7] Guttman E., Perkins C., Veizades J., and Day M., "Service 698 Location Protocol, Version 2", April 1999. 699 701 9. Author's Address 703 Michael Carney 704 Sun Microsystems, Inc. 705 901 San Antonio Road 706 Palo Alto, CA 94303-4900 708 Phone: (650) 786-4171 709 Fax: (650) 786-5896 710 Email: Michael.Carney@sun.com 712 10. Expiration 713 This document will expire on September 30, 2000.