idnits 2.17.1 draft-ietf-dhc-implementation-02.txt: -(266): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(318): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(466): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(725): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(978): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1097): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1159): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1174): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1805): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1894. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1901. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1907. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 9 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 41 longer pages, the longest (page 3) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 660 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 350: '...ndicates that we MUST fill in both the...' RFC 2119 keyword, line 363: '... We SHOULD clarify what is dict...' RFC 2119 keyword, line 383: '...alue of "chaddr" MUST NOT change from ...' RFC 2119 keyword, line 387: '...ngth of "chaddr" SHOULD be exactly spe...' RFC 2119 keyword, line 388: '... "hlen," which SHOULD match the addr...' (79 more instances...) 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 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 (June 15, 2006) is 6517 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 187, but not defined == Missing Reference: 'STD 2' is mentioned on line 227, but not defined == Missing Reference: 'RFC 1700' is mentioned on line 227, but not defined ** Obsolete undefined reference: RFC 1700 (Obsoleted by RFC 3232) == Missing Reference: 'RFC1122' is mentioned on line 779, but not defined == Unused Reference: 'RFC1123' is defined on line 1827, but no explicit reference was found in the text == Unused Reference: 'RFC1542' is defined on line 1830, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 1833, but no explicit reference was found in the text == Unused Reference: 'RFC3203' is defined on line 1841, but no explicit reference was found in the text == Unused Reference: 'RFC4388' is defined on line 1844, but no explicit reference was found in the text Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Hibbs 3 INTERNET-DRAFT Richard Barr Hibbs, P.E. 4 Category: Informational R. Stevens 5 Expires: December 17, 2006 (no affiliation) 6 June 15, 2006 8 Implementation Issues with RFC 2131, "Dynamic Host Configuration 9 Protocol (DHCPv4)" 11 12 Saved: Tuesday, June 15, 2006, 13:27:17 14 Intellectual Property Rights 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Status of this Memo 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Comments are solicited and should be addressed to the working 40 group's mailing list at dhcwg@ietf.org and/or the author(s). 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This memo identifies implementation issues with RFC 2131, "Dynamic 49 Host Configuration Protocol," reported by a number of implementers, 50 assesses the severity of the problem, then proposes changes to RFC 51 2131 intended to overcome the issues. This is intended for use as 52 the basis for discussion of RFC 2131 before it is proposed for 53 Internet Standard status. 55 Table of Contents 57 1 Introduction...............................................4 58 2 Terminology................................................4 59 3 Applicability..............................................4 60 4 Issues with RFC 2131.......................................5 61 4.1 Outdated RFC Boilerplate...............................5 62 4.2 Organization and Typography............................5 63 4.2.1 Outdated References.............................5 64 4.2.2 Typographical Errors............................5 65 4.2.3 Omissions.......................................6 66 4.2.4 Tables..........................................6 67 4.2.5 Inconsistencies.................................7 68 4.3 Policy Issues..........................................7 69 4.4 The Client Hardware Address, "chaddr"..................8 70 4.5 The DHCP Client Identifier.............................8 71 4.5.1 Uniqueness......................................8 72 4.5.2 Prohibition in DHCPOFFER and DHCPACK............9 73 4.6 Duplicate Address Detection............................9 74 4.6.1 Client-side ARP................................10 75 4.6.2 Server side PING...............................10 76 4.6.3 Other Mechanisms...............................10 77 4.7 DHCP Relay Agents.....................................11 78 4.7.1 Relay Agent Source Addresses...................11 79 4.7.2 Relay Agent Port Usage.........................11 80 4.8 Host Name, Domain Name, and FQDNs.....................11 81 4.9 Overloading of DHCPREQUEST............................11 82 4.10 DHCPINFORM...........................................12 83 4.11 Unicast of DHCPDISCOVER..............................12 84 4.12 DHCPRELEASE..........................................13 85 4.13 Client State Diagram.................................13 86 4.14 Options..............................................14 87 4.14.1 Which Options to Return?......................14 88 4.14.2 Multiple Instances of Options.................16 89 4.14.3 Option Ordering...............................16 90 4.14.4 Options 66 and 67.............................16 91 4.15 Vendor Classes.......................................16 92 4.15.1 Character Set.................................17 93 4.15.2 Form of the Name Space........................17 94 4.15.3 Relationship to Vendor Options................17 95 4.15.4 Multiplicity..................................17 96 4.16 Client/Server Retransmission.........................18 97 4.17 Transmission of DHCPNAKs.............................18 98 4.18 Use of ciaddr........................................19 99 4.19 Size of a BOOTP/DHCP Frame...........................19 100 4.19.1 Minimum Packet Size...........................19 101 4.19.2 Maximum Size, MTU, and Message Size Option....19 102 4.20 Use of giaddr........................................20 103 4.21 Address Selection....................................20 104 4.22 Use of "secs" Field..................................21 105 4.23 Use of "htype" and "hlen" Fields.....................21 106 4.24 Use of "xid" Field...................................22 107 4.25 Options in DHCPOFFER and DHCPACK.....................22 108 4.26 Lease Times..........................................23 109 4.27 Miscellaneous........................................23 110 5 Proposed Replacements for RFC 2131 Figures and Tables.....25 111 5.1 Figures...............................................25 112 5.1.1 Figure 1: Format of a DHCP message..............25 113 5.1.2 Figure 2: Format of the 'flags' Field...........25 114 5.1.3 Figure 3: Timeline Diagram--Allocating a New 115 Address...............................26 116 5.1.4 Figure 4: Timeline Diagram--Reusing an Address..27 117 5.1.4 Figure 5: State-Transition Diagram for DHCP 118 Clients...............................28 119 5.2 Tables................................................29 120 5.2.1 Table 1: Description of fields in a DHCP 121 Message................................29 122 5.2.2 Table 2: DHCP Messages..........................30 123 5.2.3 Table 3: Fields Used by DHCP Servers............31 124 5.2.4 Table 4: Options Used by DHCP servers...........32 125 5.2.5 Table 5: Client Messages from Different States..32 126 5.2.6 Table 6: Fields Used by DHCP Clients............33 127 5.2.7 Table 7: Options Used by DHCP Clients...........34 128 5.2.8 Table 8: Host Configuration Parameters--IP 129 Layer..................................35 130 5.2.9 Table 9: Host Configuration Parameters--Link 131 Layer..................................36 132 5.2.10 Table 10: Host Configuration Parameters--TCP...36 133 6 Contributors..............................................37 134 7 IANA Considerations.......................................37 135 8 Security Considerations...................................37 136 9 References................................................37 137 9.1 Normative References..................................37 138 9.2 Informative References................................37 139 1 Introduction 141 This memo was produced by the DHC Working Group and attempts to 142 identify all known implementation issues with RFC 2131 as a basis 143 for discussion of RFC 2131 before it is published as an Internet 144 Standard. 146 This memo grew from a discussion item during the DHC Working Group 147 meeting at IETF-55 in Atlanta during November 2002. 149 The editors have solicited input through a general call for 150 participation and by direct request to all implementers that they 151 could identify. 153 There are four possible outcomes of this work: 155 1. The RFC Editor could publish the agreed clarifications as a note 156 ("Errata") linked to RFC 2131 in the RFC Editor's document 157 database. This almost insures that only the most conscientious 158 reviewer would ever read and apply the changes. 160 2. The proposed changes could be reworded and reformatted into a 161 new standards-track document, "RFC 2131 Errata." This has the 162 advantage of not disturbing RFC 2131 as it advances to Internet 163 Standard, but leaves the reader with multiple documents to read 164 for a full understanding of DHCP. 166 3. Proposed changes could be applied to RFC 2131 without assigning 167 a new document number, in effect becoming "RFC 2131-bis." This 168 course may not be open as the changes would still require IESG 169 approval, and it is unlikely that any changes other than 170 editorial or clarification would be permitted. 172 4. A new standards-track document would be created, obsoleting RFC 173 2131 (and possibly other documents as well.) This would 174 probably not require any more effort than outcome (2), but 175 conceivably take years to advance the document to full Standard. 177 The editors have not specifically addressed RFC 2132, although we 178 believe that it ought to be updated in conjunction with any updates 179 to RFC 2131. We propose that an update of the DHCP Options Document 180 should be separately considered in a second memo. 182 2 Terminology 184 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 185 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 3 Applicability 190 The intent of the work item that resulted in this memo was to 191 identify and clarify issues with RFC 2131 that made implementation 192 difficult, behavior ambiguous, or conflicted with other RFCs. The 193 authors imagined that RFC 2132 could also be updated as a result, 194 without expecting that additional RFCs might be affected. 196 As our investigation proceeded, it became evident that 197 clarifications might very well extend to other RFCs. The exact 198 scope of this effort will require additional discussion by the DHC 199 Working Group. 201 4 Issues with RFC 2131 203 This list may not include every implementation issue for RFC 2131 as 204 it is based on reported problems and those known to the editors. 206 4.1 Outdated RFC Boilerplate 208 RECOMMENDATIONS: 210 1. "Status of This Memo" should be replaced with standardized 211 language for RFCs as described in "Guidelines to Authors of 212 Internet-Drafts," dated March 25, 2005. 214 2. Section 1.4, "Requirements," should be replaced with 215 standardized language referring to RFC 2119 regarding the 216 definition and interpretation of specific key words. 218 3. References should be separated into normative and non-normative 219 sections. 221 4.2 Organization and Typography 223 4.2.1 Outdated References 225 RECOMMENDATIONS: 227 O References to the "Assigned Numbers" RFC [STD 2, RFC 1700] 228 should be changed to the "Assigned Numbers" database maintained 229 by IANA. References are found in Tables 3 and 5, and in the 230 "References" section. 232 O References to the "Interaction between DHCP and BOOTP" RFC 1534 233 should be integrated with the text of the memo, and RFC 1534 234 deprecated. 236 4.2.2 Typographical Errors 238 RECOMMENDATIONS: 240 O Page 23, third paragraph of section 4.1 -- "received" should be 241 "received." 243 O Page 23, sixth paragraph of section 4.1 -- refers to RFC 1533, 244 not RFC 2132. 246 O Page 15, Figure 3. Table is misformatted. 248 O Page 18, Figure 4. Table is misformatted. 250 O Page 25, ninth paragraph of section 4.1 -- "uicast" should be 251 "unicast." 252 O Page 38, first paragraph after Table 5. Orphaned sentence: 253 "The DHCPREQUEST message contains the same 'xid' as the 254 DHCPOFFER message." No, it does not. Not only that, but this 255 sentence makes no sense in its current location. It should be 256 removed. 258 O Page 39, Last paragraph of 4.4.3 should be moved up as the last 259 paragraph of 4.4.2. When the text for DHCPINFORM was added, the 260 text describing what a client should do if no DHCPACK is 261 received was mistakenly pushed below it. 263 O Apostrophes (') are used as single quotation marks, but outside 264 of an enclosing quotation (") throughout the document. 266 O Page 30, section 4.3.1, second from last bullet: "...client�s 267 vendor class identifier and client's classes identified in the 268 server". This text makes no sense and should be deleted. 270 O Inconsistent style regarding placement of periods (.), commas 271 (,) and semi-colons (;) with respect to quotation marks 272 throughout the document. 274 O Quotation marks (single and double) are overused through the 275 document. 277 4.2.3 Omissions 279 In several places there is missing or incomplete information, 280 including: 282 O Table 3, pages 27 and 28. The "options" entry for "DHCPNAK" in 283 the "fields" portion of the table is missing. All entries in 284 this line should refer to the subsequent "options" table. 285 Suggested replacements for Table 3 are shown in sections 5.2.3 286 and 5.2.4. 288 O Page 33, Table 4, and Page 35, Figure 5, do not include the 289 "DHCPINFORM" message. Suggested replacement for Table 4 is 290 shown in section 5.2.5. 292 O Table 5, pages 37 and 38. The "options" entry for "DHCPDECLINE, 293 DHCPRELEASE" is missing. Suggested replacement for Table 5 is 294 shown in sections 5.2.6 and 5.2.7. 296 4.2.4 Tables 298 RECOMMENDATIONS: 300 O Table 3 (pages 28 and 29) and Table 5 (pages 37 and 38) should 301 be separated into two tables each for readability. Suggested 302 replacements for Table 3 are shown in sections 5.2.3 and 5.2.4, 303 and for Table 5 are show in sections 5.2.6 and 5.2.7. 305 O Table 4 should be reorganized to show all messages (except 306 DHCPRELEASE) that are sent from each client state. Suggested 307 replacement for Table 4 is shown in section 5.2.5. 309 O The "Host Configuration Parameters" table now in an appendix 310 should be omitted and described in a revised "DHCP Options" 311 document (RFC 2132). Suggested replacement for that table is 312 shown in sections 5.2.8-5.2.10. 314 4.2.5 Inconsistencies 316 RECOMMENDATIONS: 318 O Page 1, Abstract, "TCPIP" should be "TCP/IP" � as it is in the 319 rest of the document. 321 O Page 10, Table 3, description of 'htype' and 'hlen' fields does 322 not capitalize "Ethernet." 324 O Lack of consistency when describing "IP broadcast." Sometimes 325 it is "0xffffffff IP broadcast," elsewhere "limited broadcast," 326 or "broadcast." Suggest using the "255.255.255.255 IP broadcast 327 address" form, as that is the most specific. References 328 include: 330 a. Page 19, third paragraph of section 3.2, List item #2. 332 b. Page 23, fifth paragraph of section 4.1 (twice). 334 c. Page 25, thirteenth paragraph of section 4.1 (twice). 336 d. Page 32, section 4.3.2, third bullet item. 338 e. Page 32, section 4.3.2, fifth bullet item. 340 f. Page 36, second paragraph of section 4.4.1. 342 g. Page 39, last paragraph of section 4.4.1. 344 h. Page 39, second paragraph of section 4.4.3. 346 4. Lack of consistency when referring to the BROADCAST (B) flag: 347 it is also referred to as the "broadcast bit." 349 5. Table 3, "Fields and options used by DHCP servers," is 350 problematic. It indicates that we MUST fill in both the "Server 351 Identifier" (and siaddr) in our DHCPACK (and DHCPNAK) response. 352 That is a change from RFC 1541 (which specifies a "MAY" and 353 which is consistent with RFC 2132 section 9.7 and identical to 354 RFC 1533 section 9.5 wording). 356 4.3 Policy Issues 358 There has in general been a certain amount of overlap in DHCP 359 between protocol and policy. The matters include lease times, 360 whether servers are willing to extend leases, timeouts, and re- 361 transmission. 363 We SHOULD clarify what is dictated by the protocol and what is a 364 policy decision at a given site. 366 The DHC Working Group philosophy ought to be to constrain client 367 behavior more closely than server behavior. DHCP interactions are 368 initiated (and continued) by clients: clients outnumber servers by 369 many tens of thousands to one; client implementers cannot be quite 370 certain of all the environments in which their client may ultimately 371 appear, whereas server implementations may be designed for very 372 specific environments. Policy is likely to be a matter of 373 centralized control, whereas clients are not likely to enjoy a 374 sufficient status to impose policy on servers. 376 The previous paragraph implies that the WORKING GROUP should tighten 377 the protocol with respect to such issues as retries and backoffs, 378 whereas servers should not be constrained on issues such as how to 379 uniquely identify clients, whether to offer or extend leases etc. 381 4.4 The Client Hardware Address, "chaddr" 383 The value of "chaddr" MUST NOT change from DHCPDISCOVER to 384 DHCPREQUEST, although the wording in Table 3 makes this point 385 unclear. 387 Further, the length of "chaddr" SHOULD be exactly specified by 388 "hlen," which SHOULD match the address length for "htype." 390 RECOMMENDATIONS: 392 O Update Table 3. 394 4.5 The DHCP Client Identifier 396 4.5.1 Uniqueness 398 DHCP servers must uniquely identify DHCP clients requesting services 399 in order to configure the client correctly. DHCP does not require 400 global uniqueness for client identifiers, only uniqueness within the 401 scope of [sub-] networks reachable by DHCP packets in any 402 installation. This is sometimes called "subnet uniqueness." 404 RFC 2131 provides two specific methods for identifying a client: 405 (1) the client identifier (DHCP Option 61) [RFC2132], and (2) the 406 "chaddr" field of the BOOTPREQUEST packet. 408 Confusion arises from the language of RFC 2131 Section 4.2. A DHCP 409 client "...MAY choose to explicitly provide the identifier through 410 the 'client identifier' option. If the client supplies a 'client 411 identifier,' the client MUST use that same identifier in all 412 subsequent messages, and the server MUST use that identifier to 413 identify the client. If the client does not provide a 'client 414 identifier' option, the server MUST use the contents of the 'chaddr' 415 field to identify the client." 417 The text of Section 4.2 goes on to state that subnet uniqueness is a 418 requirement for an identifier, but points out that "chaddr" may not 419 satisfy that requirement. Two alternatives for a unique identifier 420 were given: an unspecified manufacturer's serial number or a DNS 421 name. 423 RFC 2132 adds to the confusion by stating that the client identifier 424 "...is expected to be unique for all clients in an administrative 425 domain" without specifying what an "administrative domain" is. 427 RFC 2132 continues by suggesting use of "...type-value pairs similar 428 to the 'htype'/'chaddr' fields defined in" [RFC951], and that a 429 "...hardware type of 0 (zero) should be used when the value field 430 contains an identifier other than a hardware address (e.g., a fully 431 qualified domain name)." 433 This suggestion of using type-value pairs has been widely adopted by 434 DHCP client implementers, but the suggestion fails to heed the 435 warning about uniqueness issues with "chaddr." 437 RECOMMENDATIONS: 439 1. RFC 2131 SHOULD have made required the "client identifier" 440 either to be globally unique or, to be unique within an 441 "administrative domain," and, in the latter case, defined 442 "administrative domain." 444 2. RFC 2131 SHOULD NOT have suggested the use of DNS names for the 445 "client identifier" without also suggesting some mechanism for 446 maintaining a consistent name-to-address mapping. 448 3. RFC 2132 SHOULD NOT have suggested using the "htype" and 449 "chaddr" fields as a type-value pair because of the warning in 450 RFC 2131 Section 4.2 about potential problems using "chaddr" for 451 the purpose. 453 4. RFC 2132 SHOULD NOT have used the word "SHOULD" when suggesting 454 the use of type-value pairs for "client identifier" with a type 455 of 0 (zero) when the value is anything other than a hardware 456 address. 458 4.5.2 Prohibition in DHCPOFFER and DHCPACK 460 Table 3, in the "options" section, specifies that the server MUST 461 NOT send the "client identifier" in the DHCPOFFER or DHCPACK 462 messages, but MAY send it in a DHCPNAK message. There is no good 463 reason why DHCPNAK should be treated differently, and there is 464 considerable utility in returning the client identifier, as it 465 allows clients further corroboration, beyond that implied by 466 matching "xid�s" (see 2.23), that they are the intended recipient. 468 RECOMMENDATION: 470 Change the text in Table 3, for all three message-types, to read, 471 "MAY -- if included, MUST BE the client identifier sent by the 472 client." Suggested replacement for Table 3 are shown in sections 473 5.2.3 and 5.2.4. 475 4.6 Duplicate Address Detection 477 RFC 2131 Page 7, section 1.6, second set of bullet items, first 478 bullet says that DHCP must: "Guarantee that any specific network 479 address will not be in use by more than one client at a time," but 480 the protocol as later described does not fulfill this requirement. 482 Two mechanisms are presented: an ARP request generated by the 483 client, and an ICMP ECHO request generated by the server: 485 O Page 12, second paragraph of section 2.2, last sentence. 487 O Page 15, list item 2, section 3.1. 489 O Page 38, first paragraph after Table 5, section 4.4.1. 491 4.6.1 Client-side ARP 493 To meet the requirement of RFC 2131 page 7, a DHCP client MUST send 494 an ARP request for the IP address contained in a DHCPACK before 495 using it. This is presently a SHOULD: 497 Page 12, second paragraph of section 2.2: "... and the 498 client SHOULD probe the newly received address, e.g., with 499 ARP." 501 There has been confusion on this topic because many clients are 502 sending an ARP reply (after the DHCPACK). This often has nothing to 503 do with DHCP, and is triggered in many systems whenever an interface 504 IP address changes. (Without access to kernel code, there is 505 nothing to be done about it.) 507 RECOMMENDATION: 509 The Working Group should consider whether to make client ARP a MUST. 511 4.6.2 Server side PING 513 ICMP is inherently unreliable. Furthermore since success is "no 514 response" it is an imprecise matter to decide how long to wait 515 before one is certain that no response will ever occur. A possible 516 suggestion is a back off and retry for ping. 518 In cable modem environments, PING is not helpful because it is the 519 cable modem termination system (CMTS) that replies from its cache: 520 a cache which may not be perfectly reliable and which in many cases 521 has been constructed by listening to the DHCP traffic in the first 522 place! 524 It is known that some network administrators try to block 525 propagation of ICMP ECHO messages through internal routers, which 526 removes one of the two address conflict detection mechanisms. 528 RECOMMENDATION: 530 Use of ICMP on the server should be a "MAY", not a "SHOULD". 532 4.6.3 Other Mechanisms 534 Both the ICMP ECHO (Ping) and Address Resolution Protocol (ARP) 535 mechanisms are very lightweight by design, depending on clients with 536 conflicting addresses to "defend" their address by responding to 537 queries to show that an address is in use. Is there a better 538 alternative to ICMP ECHO and ARP that is backward compatible with 539 these two protocols? 540 4.7 DHCP Relay Agents 542 4.7.1 Relay Agent Source Addresses 544 There should be some text that specifies what the relay agent should 545 use for the IP source address of relayed packets. Because relay 546 agents change the payload ("giaddr" and relay agent option 82), 547 their operation does not amount to IP forwarding. The IP source 548 address they use should be their own. [Aside: for security 549 purposes it might have been better than they retain the source IP 550 address of the original packet, but it is too late to change all 551 that.] 553 RECOMMENDATION: 555 4.7.2 Relay Agent Port Usage 557 Relay agents should use port 67 as the source port number. Relay 558 agents always listen on port 67, but port 68 has sometimes been used 559 as the source port number probably because it was copied from the 560 source port of the incoming packet. 562 Cable modem vendors would like to install filters blocking outgoing 563 packets with source port 67. 565 RECOMMENDATIONS: 567 O Relay agents MUST use 67 as their source port number. 569 O Relay agents MUST NOT forward packets with non-zero giaddr 570 unless the source port number on the packet is 67. 572 4.8 Host Name, Domain Name, and FQDNs 574 A fully qualified domain name (FQDN) consists of two conceptual 575 parts: the host name portion and the domain name portion. Host 576 names consist of one or more non-null parts separated by the ISO 577 period (.) character ("separator") while domain names consist of two 578 or more non-null parts delimited by the separator, one of which must 579 be a valid top-level domain (TLD) name. DHCP options exist for 580 hostname (option 12) and domain name (option 15), and are proposed 581 for FQDN (draft-ietf-dhc-fqdn-option-05.txt) but the FQDN option is 582 not required to be a concatenation of hostname and domain name. 584 Should RFC 2131 explicitly state that the client FQDN MUST be the 585 host name (option 12) concatenated with the domain name (option 15)? 587 4.9 Overloading of DHCPREQUEST 589 The client sends a DHCPREQUEST message from several different 590 states: INIT, INIT-REBOOT, REBINDING, and RENEWING. 591 Differentiation among the states is done according to the context of 592 other message fields and option values. At this point, there 593 probably can be no change in this usage, but the content of other 594 message fields and option values should be carefully reviewed to 595 ensure consistency. 597 4.10 DHCPINFORM 599 The intent of DHCPINFORM messages is to allow clients to query 600 servers for configuration information WHETHER OR NOT their IP 601 address has been assigned by DHCP. 603 Section 3.4 Para 2 Page 21 states: "The server SHOULD check the 604 network address in a DHCPINFORM message for consistency." What the 605 server should be checking is a mystery. Possibly the intent was 606 that servers should verify that the source IP address in the packet 607 is identical to the "ciaddr." Since the server should reply to 608 "ciaddr," this affords some measure of security, preventing third 609 parties from discovering configuration information pertaining to 610 other clients. Whether that is desirable, or whether instead 611 DHCPINFORM should be available to third parties, such as proxies, 612 has never been resolved. 614 Section 4.4.4 Para 1, "Use of broadcast and unicast," hints that 615 clients may be able to broadcast DHCPINFORM messages to servers: 616 "The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM 617 messages, unless the client knows the address of a DHCP server." 619 This text suggests that a DHCP client may choose to broadcast a 620 DHCPINFORM request for whatever reason, and points out the need for 621 clarification of all text concerning multiple server responses and 622 consistency of returned options. 624 RECOMMENDATIONS: 626 O DHCPINFORM messages should be included in Table 4 to summarize 627 the fields and options usage with this message type. Suggested 628 replacement for Table 4 is shown in section 5.2.5. 630 O The Working Group should consider the ramifications of 631 permitting third party DHCPINFORMs, that is, DHCPINFORM messages 632 NOT sent by the DHCP client, but by other processes having 633 access to the ports. 635 O Section 4.3.1, "DHCPDISCOVER Message," and section 4.3.2, 636 "DHCPREQUEST Message" briefly mention consistency and uniform 637 responses from multiple servers: this text SHOULD be clarified 638 to state what consistency is expected or required of the server, 639 and what a client should do if a server supplies inconsistent 640 data. 642 4.11 Unicast of DHCPDISCOVER 644 Section 4.4.4 Paragraph 1, "Use of broadcast and unicast," hints 645 that clients may be able to unicast DHCPDISCOVER messages to 646 servers: "The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and 647 DHCPINFORM messages, unless the client knows the address of a DHCP 648 server." 650 This would be pointless unless "ciaddr" were non-zero, because the 651 server would not know how to respond. Neither does table 4 admit 652 the possibility. 654 We believe it is common practice for BOOTP Relay Agents to only 655 fill-in "giaddr" for broadcast packets. This requires 656 investigation: such behavior would restrict the use of unicast 657 DHCPDISCOVER messages to the same subnet on which the server resides 658 -- a very restricted condition. 660 One circumstance in which this might make sense is for proxies 661 gathering IP addresses on behalf of other clients. In that case, 662 the proxy could put its own IP address in "ciaddr" and perhaps use 663 multiple different client identifiers in multiple transmissions. 664 Table 5, however, asserts that ciaddr must be zero. 666 RECOMMENDATIONS: 668 O The Working Group should consider whether to allow this kind of 669 proxy usage, and what changes that might imply to RFC 2131. 671 O Tables 4 and 5 SHOULD be updated to reflect the possibility of 672 unicast DHCPDISCOVER messages. Suggested replacements for 673 Tables 4 and 5 are shown in sections 5.2.5-5.2.7. 675 O Figure 5 SHOULD be updated to reflect the uses of unicast and 676 broadcast packets. Suggested replacements for Figure 5 are 677 shown in sections 5.2.6 and 5.2.7. 679 4.12 DHCPRELEASE 681 There are several MUST NOT entries in the "options" portion of RFC 682 2131 table 5 specifying the inclusion of options in the DHCPRELEASE. 683 Some customers complained that a particular vendor included the 684 "hostname" option and that this seemed innocuous. The vendor said 685 that their reading of the RFC allows such an option to be included. 687 In the "fields" portion of table 5 there is the word "unused" for 688 the "sname" and "file" fields of a DHCPRELEASE message, while 689 "options" for the DHCPRELEASE was left blank. 691 A DHCPRELEASE message SHOULD be subject to some verification 692 criteria to reduce the chance of a bogus release. Two possible 693 changes to these tables are: 695 O In the "fields" portion of table 5, change the "xid" from 696 "selected by client" to "xid from server DHCPACK message." 698 O In the "options" portion of table 5, change the entry for 699 "client identifier" from "MAY" to "client identifier used in the 700 DHCPDISCOVER message." 702 4.13 Client State Diagram 704 Section 4.3.1 and Figure 5 do not accurately describe DHCP client 705 behavior: DHCP clients send messages to servers from the INIT, 706 INIT-REBOOT, SELECTING, REQUESTING, and BOUND states, not from 707 RENEWING or REBINDING. 709 RECOMMENDATION: 711 Change the text of section 4.3.1 and its schematic representation in 712 Figure 5 to correctly represent the states, transitions, triggering 713 events, and messages sent. Suggested replacements for Figure 5 are 714 shown in sections 5.2.6 and 5.2.7. 716 4.14 Options 718 The language in RFC 2131 concerning whether and which options to 719 return to the client is convoluted and apparently contradictory. 721 4.14.1 Which Options to Return? 723 There are two opposing philosophies regarding which options servers 724 should return to clients: to return every option with values within 725 the client�s scope, or to return only those options specifically 726 requested by a client and within scope. The following arguments 727 have been cited: 729 O Supporting the return of every option: 731 a. Consistency. A network administrator wants all of the 732 configured options to show up on each client on the network, 733 regardless of client vendor. 735 b. A DHCP client is likely only to request the options it 736 supports. However, many application layer options are not 737 used by the DHCP client but are useful to applications. 739 c. A DHCP client would either need to be configured or updated 740 to request new options. The whole idea of DHCP is to keep 741 configuration on the server, not on the client, which is 742 pointed out in: Page 7, second and third bullets of section 743 1.6. 745 5. Supporting the return only of requested options: 747 a. 748 Some DHCP clients may reject packets containing options 749 that they did not request especially if they are ignorant of 750 their semantics; therefore a DHCP server should only return 751 the options requested. 753 b. The DHCP packet size is limited. Options are often 754 configured on a per-network rather than a per-client basis, 755 and to return unwanted options risks exhausting the space 756 available while options remain which the client needs. 758 RFC 2131 does little to resolve the matter. Two different sections 759 are relevant: section 3.5 describes mechanisms to limit the number 760 of options sent, while section 4.3.1 subsequently presents an 761 apparently conflicting description of how to select values for 762 options requested by the client. 764 6. RFC 2131, Section 3.5: 766 "First, most parameters have defaults defined in the Host 767 Requirements RFCs; if the client receives no parameters from 768 the server that override the defaults, a client uses those 769 default values." 771 The list of parameters with a cross-reference to the defining RFC is 772 given in Appendix A of RFC 2131. 774 Several sources contend that virtually none of the parameters in the 775 list have a meaningful default value, which raises the issue of 776 viability of the technique described in this section for reducing 777 total server response message size. 779 Even if the option has a default value defined in [RFC1122], RFC 780 2131 is silent on the question of whether or not the server MUST, 781 SHOULD, or MAY choose not to send that option when its value is the 782 same as the default. 784 7. RFC 2131, Section 4.3: 786 "IF the server has been explicitly configured with a default 787 value for the parameter, the server MUST include that value 788 in an appropriate option in the 'option' field, ELSE IF the 789 server recognizes the parameter as a parameter defined in 790 the Host Requirements Document, the server MUST include the 791 default value for that parameter as given in the Host 792 Requirements Document in an appropriate option in the 793 'option' field, ELSE the server MUST NOT return a value for 794 that parameter." 796 The word "default" in the first statement seems misplaced. The 797 second statement seems contrary to the intent of minimizing the 798 amount of data sent by the server: if the scope of the Host 799 Requirements RFCs applies to all Internet-connected hosts, then a 800 DHCP server SHOULD NOT have to supply these values -- they should 801 already be assumed by the client as the default for the requested 802 option. 804 There is no mention of a minimum set of parameters to be sent to a 805 requesting client, nor any mention of which parameters to send if 806 the client does not request any not any guidance for what to do when 807 there is more data than will fit in a response packet. Can the 808 options be somehow prioritized? Could additional options be 809 obtained using the DHCPINFORM mechanism? Should an additional bit 810 in the "flags" field be defined as a "packet overflow" bit? 812 RECOMMENDATIONS: 814 O Clients MUST include the same parameter request list on all 815 messages. 817 O Clients MUST be prepared to receive responses containing options 818 they did not request and/or whose semantics are unknown. They 819 MAY choose silently to ignore such options. 821 O Language implying that parameters in "Requirements for Internet 822 Hosts" have defaults should be removed. 824 4.14.2 Multiple Instances of Options 826 Page 24, seventh paragraph, section 4.1: "Options may appear only 827 once, unless otherwise specified in the options document. The 828 client concatenates the values of multiple instances of the same 829 option into a single parameter list for configuration." 831 RECOMMENDATION: 833 The first sentence SHOULD begin "Options MUST appear only once, 834 unless...." The second sentence belongs in the options memo 835 [RFC2132] for options where there can be multiple instances. 836 Together, these two sentences are confusing. 838 4.14.3 Option Ordering 840 A number of clients require that the DHCP message type be the first 841 option (after the magic cookie). 843 RECOMMENDATION: 845 With the exception of option 82, which must be last (save option 255 846 which acts as a terminator), the clients MUST NOT make any 847 assumption about the ordering of options. 849 4.14.4 Options 66 and 67 851 Options 66 (TFTP server name) and 67 (bootfile name) were introduced 852 as an alternative to the fixed fields "sname" and "file" in BOOTP. 853 As discussed elsewhere, space is at a premium in DHCP, and reserving 854 64 octets ("sname") and 128 octets ("file") to contain values are 855 that potentially, and commonly, much shorter is wasteful. 856 Furthermore, the existence of these options allows the client to 857 either request those values from the server or not, according to 858 need. 860 At present, servers are at liberty to return values for these 861 options in either the fixed fields, or encapsulated like any other 862 DHCP option. Clients have sometimes assumed only the former. RFC 863 2131 should address this issue. 865 RECOMMENDATIONS: 867 1. Using "sname" and "file" for these options SHOULD be deprecated. 869 2. Clients MUST be prepared, at least for the time being, for 870 either method of delivery. 872 4.15 Vendor Classes 874 Page 3, section 1.1, first paragraph - includes the following 875 sentence: "The classing mechanism for identifying DHCP clients to 876 DHCP servers has been extended to include "vendor" classes as 877 defined in sections 4.2 and 4.3." Vendor classing has been there 878 since RFC 1541, thus there is nothing new about it. Should this 879 section be referring to User classing? 880 4.15.1 Character Set 882 Some new clients have spaces in their identifier, which broke some 883 implementations with configuration file records delimited by 884 whitespace. 886 4.15.2 Form of the Name Space 888 An early suggestion (RFC 1541 time-frame), expressed symbolically, 889 was the form "Stock symbol/Organization...." e.g., "SUNW.class- 890 1.class-2" or "CMU.edu.class-1.class-2". This would have had the 891 advantage of preventing collisions between vendors. This was not 892 adopted, and it is probably too late to resurrect it. 894 4.15.3 Relationship to Vendor Options 896 Text is needed describing how each unique vendor class identifier 897 implies a 254 unique encapsulated option name space. There are 254, 898 because even within the vendor space options 0 and 255 retain their 899 meaning as the pad value and terminator, respectively. An 900 occasional misconception is that there is only a single unique 901 encapsulated 254 option name space shared by all vendors, with the 902 effect that the same values being returned to *any* client 903 regardless of vendor class identifier. Obviously, we should include 904 text to clarify the relationship between Vendor Class identifier and 905 the encapsulated Vendor option. 907 4.15.4 Multiplicity 909 How many vendor class identifiers can a client have? Only one class 910 identifier, because the client is unique to a specific vendor. If 911 the client were to send more than one vendor class option it would 912 be impossible for the server to decide which set of encapsulated 913 vendor options to select. 915 Here is some more text regarding vendor options from a note by Mike 916 Carney regarding the use of vendor class / encapsulated options: 918 Vendor class support requires the ability to configure a 919 DHCP server to support a new vendor class by associating 920 that vendor class identifier with 254 options whose types 921 can then be defined by following the DHCP client's 922 documentation. Each group of 254 options has the "scope" of 923 that vendor. For example, suppose we have the following two 924 clients: 926 Vendor Class "SunBeam.Toaster.2slots" 927 Options for this class: 928 Code Len Data 929 1 2 Darkness setting ( a 2 octet integer) 931 Vendor Class "Voxpopulis.Answering.Machine" 932 Options for this class: 933 Code Len Data 934 1 4 Outgoing message index (pointer to messages) 936 Both clients are on the same network ("Kitchen"), and are clients of 937 the same DHCP server. Note that both use encapsulated option code 938 1. Looks like a conflict, but it is not: in the syntax of the DHCP 939 server's configuration table, one configures two new options, each 940 which has the "scope" of the vendor class. 942 What this means is that when the toaster boots, the DHCP server only 943 returns vendor class options associated with the 944 "SunBeam.Toaster.2slots" class. When the answering machine boots, 945 it only sees vendor class options associated with the 946 "GE.Answering.Machine" class. Clients of vendor classes not 947 currently configured on the server do not see any encapsulated 948 vendor options. 950 4.16 Client/Server Retransmission 952 Because DHCP servers are the passive participants and DHCP clients 953 are the active participants, the DHCP protocol is susceptible to 954 poorly behaved clients (retransmitting too fast, for example). 955 However, there is no text describing this susceptibility. 956 Furthermore, the use of the power-of-2 retransmission algorithm is a 957 SHOULD/MAY. This probably should be MUST. If we need different 958 retransmission algorithms for different media, then we should 959 develop/document them in table form. The specification as it stands 960 is too loose and does cause inter-operability problems: 962 O Page 16, section 3.1, last sentence of list item 3.1. 964 O Page 17, third paragraph of list item 5, section 3.1 966 O Page 24, eighth paragraph of section 4.1 968 O Page 36, first paragraph of section 4.4.1 970 4.17 Transmission of DHCPNAKs 972 DHCPNAKs MUST be broadcast or unicast to at the link level because 973 the client has no valid IP address. The same comment applies to 974 DHCPOFFERs but with one significant difference: a DHCPOFFER has a 975 valid "yiaddr" which a relay agent can use as the destination IP 976 address. It is not clear that whatever mechanism relay agents are 977 using to transmit offers will work when "yiaddr" is 0.0.0.0. 978 Therefore, for safety�s sake, the servers MUST set the broadcast bit 979 in DHCPNAK packets. The text describing a server's behavior when 980 the client is accessible through a BOOTP relay agent does not do 981 this: 983 O Page 19, last paragraph of list item 2, section 3.2. 985 O Page 23, fifth paragraph of section 4.1. 987 O Page 32, Last paragraph of "DHCPREQUEST generated during INIT- 988 REBOOT state," bullet, section 4.3.2. 990 This last describes the behavior that is required -- a server MUST 991 set the broadcast bit in order for the relay agent to properly 992 broadcast the DHCPNAK. 994 RECOMMENDATION: 996 Items (1) and (2) above should either duplicate the text of (3), or 997 should reference section 4.3.2. 999 4.18 Use of ciaddr 1001 According to RFC 951 and RFC 1542, clients use "ciaddr" when they 1002 have received an IP address from a source outside of BOOTP/DHCP, and 1003 can respond to ARPs. 1005 The text in RFC 2131 is mostly supportive of this point with the 1006 following exception: 1008 Page 32, "DHCPREQUEST generated during REBINDING state:" 1009 section 4.3.2: "The DHCP server SHOULD check 'ciaddr' for 1010 correctness before replying to the DHCPREQUEST." 1012 RECOMMENDATION: 1014 This line should be struck from the document. Servers trust 1015 "ciaddr," period. 1017 4.19 Size of a BOOTP/DHCP Frame 1019 The description in RFC 2131 relating to the size constraints of DHCP 1020 packets (Page 10, first paragraph after Table 1, section 2) is 1021 inadequate. 1023 4.19.1 Minimum Packet Size 1025 RFC 951 states that a minimum BOOTP frame is 300 octets in length. 1026 Some BOOTP relay agents have been known to drop frames of less than 1027 300 octets. RFC 951 is explicit on this point, but RFC 2131 just 1028 refers to RFC 951. Since DHCP is intended to be backward compatible 1029 with BOOTP, the protocol should continue to observe this lower 1030 bound. 1032 RECOMMENDATION: 1034 Text should be added stating explicitly that the minimum size of a 1035 DHCP frame is 300 octets. 1037 4.19.2 Maximum Size, MTU, and Message Size Option 1039 It has been thought necessary to avoid fragmentation of the IP 1040 packets in DHCP/BOOTP due to concerns that some clients would be 1041 unable to reassemble fragments before the IP stack is properly 1042 configured. RFC 951 states, "For simplicity it is assumed that the 1043 BOOTP packet is never fragmented." Regardless of theoretical 1044 limitations in IP stack implementations, it is certain that there 1045 are several DHCP/BOOTP implementations, at both ends of the 1046 protocol, which will not reassemble. 1048 Various comments in the WORKING GROUP imply that fragmentation could 1049 be avoided were the client consistently to include the MTU of the 1050 link layer interface. However, clients cannot be expected to be 1051 omniscient about other media over which packets travel en route to 1052 servers. Servers must be endowed with this knowledge, which they 1053 MUST use to avoid packet fragmentation. 1055 Once the IP stack is configured, and the IP stack is fully 1056 configured, the aforementioned limitation ceases to exist, and later 1057 stages of the protocol could allow larger packets (up to the UDP 1058 limit). DHCPINFORMs, especially, could benefit from this 1059 relaxation. There probably should be explicit text to allow larger 1060 packets (presumably up to the maximum PDU size) for later stages of 1061 the protocol. 1063 A number of clients send small packets with the assumption that 1064 servers will not return a packet that is any larger than the one 1065 received from the client. Clients MUST NOT assume this. If the 1066 client cannot process a response larger than a certain size, the 1067 client MUST use the message size option to inform servers of this 1068 size. Note that this is NOT the same option as the MTU. 1070 RECOMMENDATIONS: 1072 O Servers and relay agents MUST ensure that IP datagram 1073 fragmentation does not occur at any stage in the protocol before 1074 the client IP stack is fully configured. 1076 O Clients SHOULD communicate their link-layer frame size to the 1077 DHCP server via the DHCP MTU option. 1079 O Clients MUST NOT assume that servers will return a packet no 1080 larger than the one they send. If the client has a limit on the 1081 size of the packet that it can process it MUST convey that limit 1082 to the server in the "maximum message size" option (57). 1084 O Page 21, second paragraph, section 3.5, the first sentence 1085 SHOULD be changed to "The client SHOULD include the 'maximum 1086 DHCP message size' option to let the server know how large the 1087 server may make its DHCP messages, and the value of this option 1088 SHOULD be the MTU of the [client] network interface being 1089 configured." 1091 O The WORKING GROUP SHOULD consider whether to allow fragmentation 1092 of packets after the client is fully configured, and how servers 1093 can divine this fact (e.g. a non-zero "ciaddr.") 1095 4.20 Use of giaddr 1097 Page 23, fifth paragraph, section 4.1: "If the 'giaddr� field is 1098 zero and the 'ciaddr' field is nonzero, then the server unicasts 1099 DHCPOFFER and DHCPACK messages to the address in 'ciaddr.'" True 1100 for DHCPACK, false for DHCPOFFER (a DHCPDISCOVER will never have 1101 anything but 0 as "ciaddr.") 1103 4.21 Address Selection 1105 Page 27, third paragraph, section 4.3.1: "Note that, in some 1106 network architectures (e.g., internets with more than on IP subnet 1107 assigned to a physical network segment), it may be the case that the 1108 DHCP client should be assigned an address from a different subnet 1109 than the address recording in 'giaddr.'" 1110 There are two differing view of this sentence: 1112 There is considerable detail in the rest of RFC 2131 trying 1113 to get the use of "giaddr" clear as it relates to BOOTP 1114 relay agents (RFC 951 and RFC 1542), then this sentence 1115 "undoes" this work. Serving multiple IP networks on the 1116 same wire should be either described in detail in its own 1117 section (with caveats) or as a separate informational RFC. 1118 Otherwise, the use of "giaddr" is unclear. 1120 Alternatively: 1122 Additional supporting text should be added to RFC 2131 to 1123 the effect that servers having knowledge of network topology 1124 MAY choose to offer an address inconsistent with "giaddr" 1125 but consistent with that topology. Furthermore, the address 1126 offered may differ depending upon the contents of the vendor 1127 class, user class, and even the client identifier. All of 1128 these things are policy matters for the server. 1130 4.22 Use of "secs" Field 1132 The "secs" field has not been discussed much: many clients simply 1133 leave its value as zero, and few if any servers have used its value 1134 to modify their behavior. These practices seem acceptable. The 1135 value of "secs" SHOULD be the elapsed time (in seconds) since the 1136 client began trying to acquire or extend a lease on an IP address. 1137 A sixteen bit field, its maximum value is 65536. It is conceivable 1138 that due to server or network failure that a client may have been 1139 waiting longer than this. 1141 RECOMMENDATION: 1143 A client MAY choose to leave to ignore the secs field. If so, its 1144 value MUST be set to zero. If the client chooses to insert a value, 1145 the value SHOULD be time elapsed since the client began negotiating 1146 for an IP address. If the client has been waiting longer than 65536 1147 seconds its value SHOULD be 65536. The value SHOULD NOT wrap around 1148 to zero. 1150 4.23 Use of "htype" and "hlen" Fields 1152 At least one vendor has used chaddr as a place holder for a value 1153 that was not in fact a link-layer (hardware) address, while at the 1154 same type using an htype of 1 (meant to be Ethernet) but an hlen of 1155 16 (instead of 6). Many servers will reject a packet with this kind 1156 of inconsistency between the htype and hlen fields. 1158 Values of htype not equal to zero MUST correspond to the link-level 1159 medium to which the DHCP client is attached according to IANA�s 1160 Assigned Numbers database. 1162 RECOMMENDATIONS: 1164 1. The value of hlen MUST be consistent with the length of a link- 1165 level address implied by htype. 1167 2. An htype of zero SHOULD be used to mean that chaddr is an 1168 identifier unrelated to a specific link-level medium. 1170 4.24 Use of "xid" Field 1172 This field exists to allow clients to match replies to requests. In 1173 two places RFC 2131 erroneously states that the client should use 1174 the "xid" in the server�s DHCPOFFER as the value in its follow up 1175 request. 1177 1. Table 5, DHCPREQUEST column. 1179 2. Section 4.4.1, Paragraph 5. 1181 In principle, the 32 bits of "xid" should be sufficient to make the 1182 chance of collisions almost nil, provided it is randomly generated 1183 as 2131 suggests in section 4.4.1 paragraph 3. However, some 1184 vendors have admitted to generating "xid" which may not be 1185 sufficiently uniformly distributed. 1187 The randomness requirement on "xid" is not as stringent as would be 1188 required, say, in selecting a cryptographic key. It is quite 1189 permissible that the initial key be predictable given sufficient 1190 knowledge of the client, but clients MUST ensure that these 1191 identifiers are generated in such a way that the chance of collision 1192 with other clients in the DHCP administrative domain is what one 1193 should expect from a truly random number. 1195 Permitting the use of the same "xid" on a re-transmission might 1196 marginally improve the efficiency of the protocol. Server responses 1197 to the first transmission, which arrived after the timeout and 1198 retransmission would be accepted, and might avoid yet another client 1199 timeout. 1201 4.25 Options in DHCPOFFER and DHCPACK 1203 RFC 2131 says that the options delivered in these two cases should 1204 not be in conflict. It does not say what "conflict" means in that 1205 case. This SHOULD be clarified. 1207 RECOMMENDATIONS: 1209 1. Servers MAY deliver a full configuration in a DHCPOFFER, but are 1210 NOT required to do so. The DHCPOFFER MUST contain an IP address 1211 and a lease time, and MAY contain other information. As a 1212 client will presumably choose among multiple offers based on 1213 some criteria, perhaps completeness of response, the server 1214 SHOULD be permitted to return the 'parameter request list' 1215 including the option code for each option it is prepared to 1216 deliver in a DHCPACK message. 1218 2. In a DHCPACK message, the lease time offered MUST be at least as 1219 long as that in the DHCPOFFER. The IP address MUST be the same. 1221 3. The options delivered in a DHCPACK message MAY differ from those 1222 in a DHCPOFFER. Some DHCP servers attempt to balance the load 1223 for other services by permuting lists. For instance, a server 1224 configured with three DNS server addresses may rotate that list 1225 each time a client is serviced. It is a problem for some 1226 servers to deliver an identical OFFER and ACK (it implies 1227 keeping state.) 1229 4. If a particularly long option list must be delivered to the 1230 client, it might not be possible to fit all options in the DHCP 1231 payload of a UDP packet. RFC 2131 appears to permit a long list 1232 of options to be sent partly in the DHCPOFFER message and partly 1233 in the DHCPACK message. 1235 4.26 Lease Times 1237 RFC 2131 has some language (section 4.3.1) that might be interpreted 1238 as constraining the duration of a lease that can be offered based on 1239 history or what the client wants. This SHOULD be rewritten to make 1240 clear that in a DHCPOFFER a server can offer whatever lease time 1241 that local policy finds acceptable, without regard to what the 1242 client requests, or what was offered last time around. If a server 1243 offers a longer lease than the client requested, the client can 1244 simply enter the RENEWING or REBINDING states, or send a DHCPRELEASE 1245 message according to its desired [earlier] times. 1247 For RENEWALS, the text should be made clear that servers are not 1248 obligated to extend leases merely because the client wishes an 1249 extension [see also general comment below about policy.] 1251 There has sometimes been an issue with T1 and T2 times as follows. 1252 Let us say that a new lease is offered with a certain T0 (T0 is 1253 lease duration) and T1 = T0/2. Then, when T1 expired, the client 1254 attempts a renewal. The server in question, for whatever reason, 1255 does not want to extend the lease, but is willing to confirm the 1256 residual time (T0/2). If it also returns T1 in the options, it 1257 should ensure that T1 is adjusted from the original value else the 1258 new ACK will have T0 and T1 identical. 1260 4.27 Miscellaneous 1262 There are many SHOULDs and SHOULD NOTs that should perhaps be 1263 converted into MUSTs or MUST NOTs. Here is a summary: 1265 1. Page 16, item 4, section 3.1 "The server SHOULD NOT check the 1266 offered network address at this point." (MUST NOT) 1268 2. Page 16, item 5, section 3.1 "The client SHOULD perform a final 1269 check on the parameters..." (MUST) 1271 3. Page 17, item 5, section 3.1 "The client SHOULD wait a minimum 1272 of ten seconds..." (MUST) 1274 4. Page 18, item 2, section 3.2 "Servers SHOULD NOT check that the 1275 client's network address is already in use..." (MUST NOT) 1277 5. Page 19, item 2, second paragraph, section 3.2 "...servers 1278 SHOULD respond with a DHCPNAK message to the client" (MUST). 1279 The following sentences are rather dubious in this paragraph as 1280 well. 1282 6. Page 21, first paragraph, section 3.4 "The servers SHOULD 1283 unicast the DHCPACK replay to the address given in the 'ciaddr' 1284 field of the DHCPINFORM message" (MUST) 1286 7. Page 22, last paragraph, section 3.5 "If a server receives a 1287 DHCP request message with an invalid 'requested IP address', the 1288 server SHOULD respond to the client with a DHCPNAK message...." 1289 (MUST) 1291 RECOMMENDATION: 1293 The WORKING GROUP should review the use of emphasis words (e.g., 1294 MAY) in RFC 2131. Those SHOULDs that remain should list the valid 1295 exceptions (some do; most don't). 1297 5 Proposed Replacements for RFC 2131 Figures and Tables 1299 5.1 Figures 1301 5.1.1 Figure 1: Format of a DHCP message 1303 0 1 2 3 1304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | op (1) | htype (1) | hlen (1) | hops (1) | 1307 +---------------+---------------+---------------+---------------+ 1308 | xid (4) | 1309 +-------------------------------+-------------------------------+ 1310 | secs (2) | flags (2) | 1311 +-------------------------------+-------------------------------+ 1312 | ciaddr (4) | 1313 +---------------------------------------------------------------+ 1314 | yiaddr (4) | 1315 +---------------------------------------------------------------+ 1316 | siaddr (4) | 1317 +---------------------------------------------------------------+ 1318 | giaddr (4) | 1319 +---------------------------------------------------------------+ 1320 | | 1321 | chaddr (16) | 1322 | | 1323 | | 1324 +---------------------------------------------------------------+ 1325 | | 1326 | sname (64) | 1327 +---------------------------------------------------------------+ 1328 | | 1329 | file (128) | 1330 +---------------------------------------------------------------+ 1331 | | 1332 | options (variable) | 1333 +---------------------------------------------------------------+ 1335 Figure 1: Format of a DHCP Message 1337 5.1.2 Figure 2: Format of the 'flags' Field 1339 . . . . . . . . . . 1 1 1 1 1 1 1340 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 |B| MBZ | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 ----------------------------------------------- 1346 | Key: | 1347 | B: BROADCAST flag | 1348 | MBZ: MUST BE ZERO (reserved for future use) | 1349 ----------------------------------------------- 1351 Figure 2: Format of the 'flags' Field 1352 5.1.3 Figure 3: Timeline Diagram--Allocating a New Address 1354 Server Server 1355 (not selected) Client (selected) 1356 v v v 1357 | | | 1358 | Begins initialization | 1359 | | | 1360 | ______________/|\______________ | 1361 |/ DHCPDISCOVER | DHCPDISCOVER \| 1362 | | | 1363 Determines | Determines 1364 configuration | configuration 1365 | | /| 1366 |\ | ____________/ | 1367 | \___________ | / DHCPOFFER | 1368 | DHCPOFFER \ |/ | 1369 | \ | | 1370 | \| | 1371 | Collects replies | 1372 | Selects configuration | 1373 | | | 1374 | ______________/|\______________ | 1375 |/ DHCPREQUEST | DHCPREQUEST \| 1376 | | | 1377 | | Commits| 1378 | | configuration| 1379 | | | 1380 | | ______________/| 1381 | |/ DHCPACK | 1382 | | | 1383 | Initialization complete | 1384 | | | 1385 . . . 1386 . . . 1387 | | | 1388 | Graceful shutdown | 1389 | | | 1390 | |\______________ | 1391 | | DHCPRELEASE \| 1392 | | | 1393 | | Discards| 1394 | | lease| 1395 | | | 1396 v v v 1398 Figure 3: Timeline Diagram of Messages Exchanged between DHCP Client 1399 and Servers When Allocating a New Network Address 1400 5.1.4 Figure 4: Timeline Diagram--Reusing an Address 1402 Server Client Server 1403 v v v 1404 | | | 1405 | Begins | 1406 | initialization | 1407 | | | 1408 | /|\ | 1409 | ____________/ | \___________ | 1410 | /DHCPREQUEST | DHCPREQUEST\ | 1411 |/ | \| 1412 | | | 1413 Locates | Locates 1414 configuration | configuration 1415 | | | 1416 |\ | /| 1417 | \ | ___________/ | 1418 | \ | / DHCPACK | 1419 | \ _______ |/ | 1420 | DHCPACK\ | | 1421 | Initialization | 1422 | complete | 1423 | \| | 1424 | | | 1425 | (Subsequent | 1426 | DHCPACKS | 1427 | ignored) | 1428 | | | 1429 | | | 1430 v v v 1432 Figure 4: Timeline Diagram of Messages Exchanged between DHCP 1433 Client and Servers When Reusing a Previously Allocated Address 1434 5.1.4 Figure 5: State-Transition Diagram for DHCP Clients 1436 +-------+ 1437 Have Unexpired | | Do Not Have 1438 +---- Lease ------| START |--- Lease ----+ 1439 V | | V 1440 +--------+ +-------+ +-------+ 1441 | | +-------------------------->| |<-------------------+ 1442 | INIT- | | +------------------>| INIT | | 1443 | REBOOT | DHCPNAK/ | +-------->| |<---------------+ | 1444 | | Restart | | +---+---+ | | 1445 +----+---+ | | | | | | 1446 | | DHCPNAK/ | Broadcast | | 1447 Broadcast | Discard offer | DHCPDISCOVER | | 1448 DHCPREQUEST | | DHCPACK | | | 1449 | | | (not accepted)/ v | | 1450 V | | Send +-----------+ | | 1451 +---------+-+ | DHCPDECLINE | |<-----+ | | 1452 | | | | | SELECTING | | | | 1453 | REBOOTING | | +----+ | | DHCPOFFER/ | | 1454 | | | | +-+-------+-+ Collect | | 1455 +-+---------+ | | | | replies | | 1456 | | | Select offer/ | | | | 1457 DHCPACK/ | | send +--------+ | | 1458 Record lease, set | | DHCPREQUEST | | 1459 timers T1, T2 +-+----+-----+ | DHCPNAK, | 1460 | | |<-------+ Lease expires/ | 1461 | +-------->| REQUESTING | Halt network | 1462 | | | | | | 1463 | DHCPOFFER/ +-+--------+-+ +-----------+ | | 1464 | Discard | | | | | | 1465 | | | DHCPACK (accepted)/ +----+ REBINDING +---+ | 1466 | +-----------+ Record lease, set | | | | 1467 | timers T1, T2 | +-----------+ | 1468 | | DHCPACK/ ^ | 1469 | | Record lease, set | | 1470 | | timers T1, T2 | | 1471 | | | T2 expires/ | 1472 | v | Broadcast | 1473 | +-----+-+ | DHCPREQUEST | 1474 +----------------->| +<-----------+ | | 1475 +-------------------+ BOUND +-------------------------+ | 1476 | DHCPOFFER,+--->| |<-------------+ | 1477 | DHCPACK, or| +-+---+-+ | | 1478 | DHCPNAK/ | | | DHCPACK/ | 1479 | Discard +------+ | Record lease, set | 1480 | T1 expires/ timers T1, T2 | 1481 | Send DHCPREQUEST | | 1482 | to leasing server +-----+----+ | 1483 | | | | | 1484 Lease expires/ | | RENEWING +--DHCPNAK/ ----->| 1485 halt network +--------->| | halt network | 1486 | +----------+ | 1487 +-----------------------------------------------------------------+ 1489 Figure 5: State-transition diagram for DHCP clients 1490 5.2 Tables 1492 5.2.1 Table 1: Description of fields in a DHCP Message 1494 --------------------------------------------------------------------- 1495 |FIELD |OCTETS|DESCRIPTION | 1496 ----------------------------------------------------------------------- 1497 |'op' | 1 |Message op code / message type. | 1498 | | |1 = BOOTREQUEST, 2 = BOOTREPLY | 1499 |'htype' | 1 |Hardware address type, see ARP section in "Assigned | 1500 | | |Numbers" RFC; e.g., '1' = 10mb Ethernet. | 1501 |'hlen' | 1 |Hardware address length (e.g., '6' for 10mb | 1502 | | |Ethernet). | 1503 |'hops' | 1 |Client sets to zero, optionally used by relay agents| 1504 | | |when booting via a relay agent. | 1505 |'xid' | 4 |Transaction ID, a random number chosen by the | 1506 | | |client, used by the client and server to associate | 1507 | | |messages and responses between a client and a | 1508 | | |server. | 1509 |'secs' | 2 |Filled in by client, seconds elapsed since client | 1510 | | |began address acquisition or renewal process. | 1511 |'flags' | 2 |Flags (see Figure 2). | 1512 |'ciaddr' | 4 |Client IP address; only filled in if client is in | 1513 | | |BOUND, RENEW or REBINDING state and can respond | 1514 | | |to ARP requests. | 1515 |'yiaddr' | 4 |"your" (client) IP address. | 1516 |'siaddr' | 4 |IP address of next server to use in bootstrap; | 1517 | | |returned in DHCPOFFER, DHCPACK by server. | 1518 |'giaddr' | 4 |Relay agent IP address, used in booting via a | 1519 | | |relay agent. | 1520 |'chaddr' | 16 |Client hardware address. | 1521 |'sname' | 64 |Optional server host name, null terminated string. | 1522 |'file' | 128 |Boot file name, null terminated string; "generic" | 1523 | | |name or null in DHCPDISCOVER, fully qualified | 1524 | | |directory-path name in DHCPOFFER. | 1525 |'options'|vari- |Optional parameters field. See the options | 1526 | | able|documents for a list of defined options. | 1527 ----------------------------------------------------------------------- 1529 Table 1: Description of Fields in a DHCP message 1530 5.2.2 Table 2: DHCP Messages 1532 --------------------------------------------------------------------- 1533 |Message |Usage | 1534 --------------------------------------------------------------------- 1535 |DHCPDISCOVER|Client broadcast to locate available servers. | 1536 | | | 1537 |DHCPOFFER |Server to client in response to DHCPDISCOVER with | 1538 | |offer of configuration parameters. | 1539 | | | 1540 |DHCPREQUEST |Client message to servers either (a) requesting | 1541 | |offered parameters from one server and implicitly | 1542 | |declining offers from all others, (b) confirming | 1543 | |correctness of previously allocated address after, | 1544 | |e.g., system reboot, or (c) extending the lease on a | 1545 | |particular network address. | 1546 | | | 1547 |DHCPACK |Server to client with configuration parameters, | 1548 | |including committed network address. | 1549 | | | 1550 |DHCPNAK |Server to client indicating client's notion of network| 1551 | |address is incorrect (e.g., client has moved to new | 1552 | |subnet) or client's lease as expired | 1553 | | | 1554 |DHCPDECLINE |Client to server indicating network address is already| 1555 | |in use. | 1556 | | | 1557 |DHCPRELEASE |Client to server relinquishing network address and | 1558 | |canceling remaining lease. | 1559 | | | 1560 |DHCPINFORM |Client to server, asking only for local configuration | 1561 | |parameters; client already has externally configured | 1562 | |network address. | 1563 --------------------------------------------------------------------- 1565 Table 2: DHCP Messages 1566 5.2.3 Table 3: Fields Used by DHCP Servers 1568 --------------------------------------------------------------------- 1569 |Field |DHCPOFFER |DHCPACK |DHCPNAK | 1570 --------------------------------------------------------------------- 1571 |'op' |2 |2 |2 | 1572 |'htype' | (From "Assigned Numbers" Database) | 1573 |'hlen' | (Hardware address length in octets) | 1574 |'hops' |0 |0 |0 | 1575 |'xid' |'xid' from client |'xid' from client |'xid' from client | 1576 | |DHCPDISCOVER |DHCPREQUEST |DHCPREQUEST | 1577 | |message |message |message | 1578 |'secs' |0 |0 |0 | 1579 |'ciaddr' |0 |'ciaddr' from |0 | 1580 | | |DHCPREQUEST or 0 | | 1581 |'yiaddr' |IP address offered |IP address |0 | 1582 | |to client |assigned to client| | 1583 |'siaddr' |IP address of next |IP address of next|0 | 1584 | |bootstrap server |bootstrap server | | 1585 |'flags' |'flags' from |'flags' from |'flags' from | 1586 | |client DHCPDISCOVER|client DHCPREQUEST|client DHCPREQUEST| 1587 | |message |message |message | 1588 |'giaddr' |'giaddr' from |'giaddr' from |'giaddr' from | 1589 | |client DHCPDISCOVER|client DHCPREQUEST|client DHCPREQUEST| 1590 | |message |message |message | 1591 |'chaddr' |'chaddr' from |'chaddr' from |'chaddr' from | 1592 | |client DHCPDISCOVER|client DHCPREQUEST|client DHCPREQUEST| 1593 | |message |message |message | 1594 |'sname' |Server host name |Server host name |(unused) | 1595 | |or options |or options | | 1596 |'file' |Client boot file |Client boot file |(unused) | 1597 | |name or options |name or options | | 1598 |'options'|(see Table 4) |(see Table 4) |(see Table 4) | 1599 --------------------------------------------------------------------- 1601 Table 3: Fields Used by DHCP Servers 1602 5.2.4 Table 4: Options Used by DHCP servers 1604 --------------------------------------------------------------------- 1605 |Option |DHCPOFFER|DHCPACK |DHCPNAK | 1606 --------------------------------------------------------------------- 1607 |Requested IP address |MUST NOT |MUST NOT |MUST NOT| 1608 |IP address lease time |MUST |MUST (DHCPREQUEST) |MUST NOT| 1609 | | |MUST NOT (DHCPINFORM)| | 1610 |Use 'file'/'sname' fields |MAY |MAY |MUST NOT| 1611 |DHCP message type |DHCPOFFER|DHCPACK |DHCPNAK | 1612 |Parameter request list |MUST NOT |MUST NOT |MUST NOT| 1613 |Message |SHOULD |SHOULD |SHOULD | 1614 |Client identifier |MUST NOT |MUST NOT |MAY | 1615 |Vendor class identifier |MAY |MAY |MAY | 1616 |Server identifier |MUST |MUST |MUST | 1617 |Maximum message size |MUST NOT |MUST NOT |MUST NOT| 1618 |All others |MAY |MAY |MUST NOT| 1619 --------------------------------------------------------------------- 1621 Table 4: Options Used by DHCP servers 1623 5.2.5 Table 5: Client Messages from Different States 1625 --------------------------------------------------------------------- 1626 | |INIT-REBOOT |SELECTING |RENEWING |REBINDING | 1627 --------------------------------------------------------------------- 1628 |broad/uni-cast|broadcast |broadcast |unicast |broadcast | 1629 |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT | 1630 |requested-ip |MUST |MUST |MUST NOT |MUST NOT | 1631 |ciaddr |zero |zero |IP address |IP address| 1632 --------------------------------------------------------------------- 1634 Table 5: Client Messages from Different States 1635 5.2.6 Table 6: Fields Used by DHCP Clients 1637 --------------------------------------------------------------------- 1638 |Field |DHCPDISCOVER, |DHCPREQUEST |DHCPDECLINE, | 1639 | |DHCPINFORM | |DHCPRELEASE | 1640 --------------------------------------------------------------------- 1641 |'op' |1 |1 |1 | 1642 |'htype' | (From "Assigned Numbers" Database) | 1643 |'hlen' | (Hardware address length in octets) | 1644 |'hops' |0 |0 |0 | 1645 |'xid' |selected by client|'xid' from server |selected by | 1646 | | |DHCPOFFER message |client | 1647 |'secs' |seconds since |seconds since |0 | 1648 | |DHCP process |DHCP process | | 1649 | |started |started | | 1650 |'flags' |Set 'BROADCAST' |Set 'BROADCAST' |0 | 1651 | |flag if client |flag if client | | 1652 | |requires broadcast|requires broadcast | | 1653 | |reply |reply | | 1654 |'ciaddr' |0 (DHCPDISCOVER) |0 or client's |0 (DHCPDECLINE) | 1655 | |client's |network address |client's network | 1656 | |network address |(BOUND/RENEW/REBIND)|address | 1657 | |(DHCPINFORM) | |(DHCPRELEASE) | 1658 |'yiaddr' |0 |0 |0 | 1659 |'siaddr' |0 |0 |0 | 1660 |'giaddr' |0 |0 |0 | 1661 |'chaddr' |client's hardware |client's hardware |client's hardware| 1662 | |address |address |address | 1663 |'sname' |options, if |options, if |(unused) | 1664 | |indicated in |indicated in | | 1665 | |'sname/file' |'sname/file' | | 1666 | |option; otherwise |option; otherwise | | 1667 | |unused |unused | | 1668 |'file' |options, if |options, if |(unused) | 1669 | |indicated in |indicated in | | 1670 | |'sname/file' |'sname/file' | | 1671 | |option; otherwise |option; otherwise | | 1672 | |unused |unused | | 1673 |'options'|(see Table 7) |(see Table 7) |(see Table 7) | 1674 --------------------------------------------------------------------- 1676 Table 6: Fields Used by DHCP Clients 1677 5.2.7 Table 7: Options Used by DHCP Clients 1679 --------------------------------------------------------------------- 1680 |Option |DHCPDISCOVER,|DHCPREQUEST |DHCPDECLINE, | 1681 | |DHCPINFORM | |DHCPRELEASE | 1682 --------------------------------------------------------------------- 1683 |Requested IP address |MAY |MUST (in |MUST | 1684 | |(DISCOVER) |SELECTING or |(DHCPDECLINE)| 1685 | |MUST NOT |INIT-REBOOT) |MUST NOT | 1686 | |(INFORM) |MUST NOT (in |(DHCPRELEASE)| 1687 | | |BOUND or | | 1688 | | |RENEWING) | | 1689 |IP address lease time |MAY |MAY |MUST NOT | 1690 | |(DISCOVER) | | | 1691 | |MUST NOT | | | 1692 | |(INFORM) | | | 1693 |Use 'file'/'sname' |MAY |MAY |MAY | 1694 |fields | | | | 1695 |DHCP message type |DHCPDISCOVER/|DHCPREQUEST |DHCPDECLINE/ | 1696 | |DHCPINFORM | |DHCPRELEASE | 1697 |Client identifier |MAY |MAY |MAY | 1698 |Vendor class identifier|MAY |MAY |MUST NOT | 1699 |Server identifier |MUST NOT |MUST (after |MUST | 1700 | | |SELECTING) | | 1701 | | |MUST NOT (after| | 1702 | | |INIT-REBOOT, | | 1703 | | |BOUND, RENEWING| | 1704 | | |or REBINDING) | | 1705 |Parameter request list |MAY |MAY |MUST NOT | 1706 |Maximum message size |MAY |MAY |MUST NOT | 1707 |Message |SHOULD NOT |SHOULD NOT |SHOULD | 1708 |Site-specific |MAY |MAY |MUST NOT | 1709 |All others |MAY |MAY |MUST NOT | 1710 --------------------------------------------------------------------- 1712 Table 7: Options Used by DHCP Clients 1713 5.2.8 Table 8: Host Configuration Parameters--IP Layer 1715 --------------------------------------------------------------------- 1716 | IP-layer parameters, per host: | 1717 --------------------------------------------------------------------- 1718 |Parameter | Permissible Values | Reference | 1719 --------------------------------------------------------------------- 1720 |Be a router | on/off | HR 3.1 | 1721 |Non-local source routing | on/off | HR 3.3.5 | 1722 |Policy filters for | | | 1723 |non-local source routing | (list) | HR 3.3.5 | 1724 |Maximum reassembly size | integer | HR 3.3.2 | 1725 |Default TTL | integer | HR 3.2.1.7 | 1726 |PMTU aging timeout | integer | MTU 6.6 | 1727 |MTU plateau table | (list) | MTU 7 | 1728 --------------------------------------------------------------------- 1729 | IP-layer parameters, per interface: | 1730 --------------------------------------------------------------------- 1731 |Parameter | Permissible Values | Reference | 1732 --------------------------------------------------------------------- 1733 |IP address | (address) | HR 3.3.1.6 | 1734 |Subnet mask | (address mask) | HR 3.3.1.6 | 1735 |MTU | integer | HR 3.3.3 | 1736 |All-subnets-MTU | on/off | HR 3.3.3 | 1737 |Broadcast address flavor | 0.0.0.0 or | HR 3.3.6 | 1738 | | 255.255.255.255 | | 1739 |Perform mask discovery | on/off | HR 3.2.2.9 | 1740 |Be a mask supplier | on/off | HR 3.2.2.9 | 1741 |Perform router discovery | on/off | RD 5.1 | 1742 |Router solicitation address | (address) | RD 5.1 | 1743 |Default routers, list of: | | | 1744 | router address | (address) | HR 3.3.1.6 | 1745 | preference level | integer | HR 3.3.1.6 | 1746 |Static routes, list of: | | | 1747 | destination | (host/subnet/net) | HR 3.3.1.2 | 1748 | destination mask | (address mask) | HR 3.3.1.2 | 1749 | type-of-service | integer | HR 3.3.1.2 | 1750 | first-hop router | (address) | HR 3.3.1.2 | 1751 | ignore redirects | on/off | HR 3.3.1.2 | 1752 | PMTU | integer | MTU 6.6 | 1753 | perform PMTU discovery | on/off | MTU 6.6 | 1754 --------------------------------------------------------------------- 1755 | Key: | 1756 | HR -- Host Requirements Communications Layers (RFC 1122, | 1757 | Internet Standard) | 1758 | MTU -- Path MTU Discovery (RFC 1191, Proposed Standard) | 1759 | RD -- Router Discovery (RFC 1256, Proposed Standard) | 1760 --------------------------------------------------------------------- 1762 Table 8: Host Configuration Parameters--IP Layer 1763 5.2.9 Table 9: Host Configuration Parameters--Link Layer 1765 --------------------------------------------------------------------- 1766 | Link-layer parameters, per interface: | 1767 --------------------------------------------------------------------- 1768 |Parameter | Permissible Values | Reference | 1769 --------------------------------------------------------------------- 1770 |Trailers | on/off | HR 2.3.1 | 1771 |ARP cache timeout | integer | HR 2.3.2.1 | 1772 |Ethernet encapsulation | (RFC 894/RFC 1042) | HR 2.3.3 | 1773 --------------------------------------------------------------------- 1774 | Key: | 1775 | HR -- Host Requirements Communications Layers (RFC 1122, | 1776 | Internet Standard) | 1777 --------------------------------------------------------------------- 1779 Table 9: Host Configuration Parameters--Link Layer 1781 5.2.10 Table 10: Host Configuration Parameters--TCP 1783 --------------------------------------------------------------------- 1784 | TCP parameters, per host: | 1785 --------------------------------------------------------------------- 1786 |Parameter | Permissible Values | Reference | 1787 --------------------------------------------------------------------- 1788 |TTL | integer | HR 4.2.2.19 | 1789 |Keep-alive interval | integer | HR 4.2.3.6 | 1790 |Keep-alive data size | 0/1 | HR 4.2.3.6 | 1791 --------------------------------------------------------------------- 1792 | Key: | 1793 | HR -- Host Requirements Communications Layers (RFC 1122, | 1794 | Internet Standard) | 1795 --------------------------------------------------------------------- 1797 Table 10: Host Configuration Parameters--TCP 1798 6 Contributors 1800 This document is the result of work undertaken the by DHCP working 1801 group. The editors would like to include a number of contributors 1802 to this effort including Mike Carney of Sun Microsystems, Steve 1803 Tulloh of Shadow Support, Bernie Volz, Ted Lemon of Nominum, Simon 1804 Vogl, Edward Mascarenhas of SGI, Andre Kostur of Incognito, Bud 1805 Millwood of Weird Solutions, Patrick Gu�lat of ImproWare Network 1806 Services, and Swamy Narasimha of Nokia. 1808 7 IANA Considerations 1810 This memo contains no values requiring IANA attention. 1812 8 Security Considerations 1814 (To be defined when suggested text changes for RFC 2131 are 1815 completed.) 1817 A separate Internet-Draft is being created to provide a threat 1818 analysis of RFCs 2131 and 3118. 1820 9 References 1822 9.1 Normative References 1824 [RFC951] Croft, W., and Gilmore, J., "Bootstrap Protocol," RFC 951, 1825 September 1985. 1827 [RFC1123] R. Braden, "Requirements for Internet Hosts -- Application 1828 and Support," October 1989. 1830 [RFC1542] W. Wimer, "Clarifications and Extensions for the Bootstrap 1831 Protocol" RFC 1542, October 1993 1833 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol," March 1834 1997. 1836 [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP 1837 Vendor Extensions," March 1997. 1839 9.2 Informative References 1841 [RFC3203] T'Joens, Y., Hublet, C., and De Schrijver, P., "The DHCP 1842 Reconfigure Extension," July 2001. 1844 [RFC4388] Woundy, R., and Kinnear, K., "Dynamic Host Configuration 1845 Protocol (DHCP) Leasequery," February 2006. 1847 , Stapp, M., and Rekhter, Y., 1848 "The DHCP Client FQDN Option," March 2006. 1850 Authors' Addresses 1852 Barr Hibbs 1853 Richard Barr Hibbs, P.E. 1854 952 Sanchez Street 1855 San Francisco, California 94114-3362 1856 USA 1858 Phone: +1-(415)-648-3920 1859 E-mail: rbhibbs@pacbell.net 1861 Rob Stevens 1862 308 Arthur Avenue 1863 Aptos, California 95003-5202 1864 USA 1866 Phone: +1-(831)-688-9722 1867 E-mail: robs@cruzio.com 1869 Full Copyright Statement 1871 Copyright (C) The Internet Society (2006). All rights reserved. 1873 This document is subject to the rights, licenses and restrictions 1874 contained in BCP 78, and except as set forth therein, the authors 1875 retain all their rights. 1877 This document and the information contained herein are provided on 1878 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1879 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1880 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1881 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1882 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1883 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1885 Intellectual Property 1887 The IETF takes no position regarding the validity or scope of any 1888 Intellectual Property Rights or other rights that might be claimed 1889 to pertain to the implementation or use of the technology described 1890 in this document or the extent to which any license under such 1891 rights might or might not be available; nor does it represent that 1892 it has made any independent effort to identify any such rights. 1893 Information on the procedures with respect to rights in RFC 1894 documents can be found in BCP 78 and BCP 79. 1896 Copies of IPR disclosures made to the IETF Secretariat and any 1897 assurances of licenses to be made available, or the result of an 1898 attempt made to obtain a general license or permission for the use 1899 of such proprietary rights by implementers or users of this 1900 specification can be obtained from the IETF on-line IPR repository 1901 at http://www.ietf.org/ipr. 1903 The IETF invites any interested party to bring to its attention any 1904 copyrights, patents or patent applications, or other proprietary 1905 rights that may cover technology that may be required to implement 1906 this standard. Please address the information to the IETF at ietf- 1907 ipr@ietf.org. 1909 Acknowledgement 1911 Funding for the RFC Editor function is provided by the IETF 1912 Administrative Support Activity (IASA). 1914 APPENDIX: NOTES 1916 This appendix will be removed when this memo goes to Working Group 1917 Last Call. 1919 Issues List 1921 Open, unresolved issues about RFC 2131 include: 1923 1. What is the correct use of client identifier in DHCPOFFER and 1924 DHCPACK messages? 1926 2. Are there any effective alternatives to ICMP ECHO and ARP for 1927 address-in-use detection? 1929 3. What is the definition of a Fully Qualified Domain Name? 1931 4. Should DHCPINFORM messages be allowed from client proxies? 1933 5. Should client proxies, in general, be allowed, and how does a 1934 client proxy know the IP address of a DHCP server? 1936 6. Should a DHCP server send only options requested by a client, or 1937 should a server send all options for which it is configured with 1938 a value? 1940 7. Should required usage of "xid" and "client identifier" be 1941 changed to support server verification of DHCPRELEASE messages? 1943 8. What is the correct statement about selecting an IP address to 1944 offer a client when the offered address is on a different subnet 1945 than the client's "giaddr?" 1947 9. Should a new flags bit to signify "more options data available" 1948 be added? 1950 10. Do we need a new "Maximum Relay MTU Size" option to ensure that 1951 all reply packets sent by a server will pass without fragmenting 1952 or dropping packets? 1954 11. Would it help to set a sort of "more to come" option, indicating 1955 that more options will follow in a consecutive DHCPACK, where 1956 the subsequent DHCPACKs would have a "additional information" 1957 option indicating that the message contains only new options 1958 data similar to a DHCPACK in response to a DHCPINFORM message? 1960 12. Are unicast DHCPDISCOVER messages permitted? What are the 1961 requirements for specific message fields and options in this 1962 case? 1964 13. What level of consistency is required among responses from 1965 multiple servers? 1967 14. Can the REBINDING state be entered from the BOUND state on 1968 expiration of T2, or only if there is a timeout in RENEWING 1969 state? 1970 15. Should the text of RFC 4361, Node-Specific Client Identifiers, 1971 be folded into a revised RFC 2131 and RFC 2132? 1973 16. Should the text of RFC 4388, DHCP Leasequery, be folded into a 1974 revised RFC 2131 and RFC 2132? 1976 Changes from Prior Drafts 1978 "-00" Draft 1980 The "-00" revision was the initial version of this memo, submitted 1981 to the Internet-Drafts editor on 23 February 2003. 1983 "-01" Draft 1985 The "-01" revision contains substantial changes following a detailed 1986 review of DHC Working Group mailing list discussions on RFC 2131 1987 clarification issues, consideration of several directed questions, 1988 and comments received by the authors. Changes include: 1990 O Reorganization of the document to group all typographical errors 1991 together, separate from protocol or policy issues. 1993 O Elimination of "Interaction with DNS" and "Client and Server 1994 Administration" sections because the authors saw no clear 1995 resolution to the topics. 1997 O Creation of an issues list in section 4.1. 1999 "-02" Draft 2001 The "-02" revision consists of numerous minor typographical, 2002 spelling, and grammatical updates, plus: 2004 O Replaced all Internet-Draft Boilerplate with current versions. 2006 O Removed all of Section 5, "Notes" to this appendix. 2008 O Replaced Section 5 with the proposed figures and tables for use 2009 with revised text of RFC 2131-bis. 2011 O Removed Appendix A. 2013 O Separation of Section 9, "References," into Normative and 2014 Informative subsections. 2016 O Updated Authors' Addresses. 2018 O Added text to Section 4.5.1 covering RFC 4361, "Node-Specific 2019 Client Identifiers for DHCPv4." 2021 O Recent mailing list discussion about the correct use of the 2022 "secs" field was incorporated into Section 4.22.