idnits 2.17.1 draft-ietf-dhc-client-options-00.txt: -(264): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(415): 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): ---------------------------------------------------------------------------- ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 1) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview' ) ** 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 an Authors' Addresses Section. ** There are 708 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([It], [RFC2119], [RFC2131], [Client], [RFC2132]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 254: '...he editor, any server response MUST be...' RFC 2119 keyword, line 268: '...server pairing is a matter that SHOULD...' RFC 2119 keyword, line 272: '...Requirements, it SHOULD be returned in...' RFC 2119 keyword, line 279: '...orrect option(s) MUST be included in t...' RFC 2119 keyword, line 390: '...er a DHCP server SHOULD send options i...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 647 has weird spacing: '...tribute confi...' == Line 649 has weird spacing: '...robably use t...' == Line 655 has weird spacing: '...hine as the D...' == Line 656 has weird spacing: '...for the major...' == Line 659 has weird spacing: '... not yours...' == (4 more instances...) -- 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 (Oct 1999) is 8961 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 1343 looks like a reference -- Missing reference section? 'Client' on line 534 looks like a reference -- Missing reference section? 'It' on line 1133 looks like a reference -- Missing reference section? 'RFC2131' on line 1346 looks like a reference -- Missing reference section? 'RFC2132' on line 1349 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. B. Hibbs, Pacific*Bell 2 Internet-Draft N. Lane, Wal-Mart Stores 3 Category: Informational Oct 1999 5 Interpreting Client Options for the Dynamic Host Configuration 6 Protocol 8 10 Saved: Thursday, October 14, 1999, 2:24 PM 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 To learn the current status of any Internet-Draft, please check 35 the "1id-abstracts.txt" listing contained in the Internet-Drafts 36 Shadow Directories on ds.internic.net (US East Coast), 37 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 38 munnari.oz.au (Pacific Rim). 40 Copyright Notice 42 Copyright (C) The Internet Society (1999). All Rights Reserved. 44 Abstract 46 During the summer of 1999, a grand debate raged over the correct 47 interpretation of several DHCP client options as described in [RFC 48 2132], as well as the need for one option whose proposing 49 Internet-Draft expired. 51 As a result of that debate, the authors gained some insights into 52 the intended (or unintended!) interpretation of certain options 53 defined in [RFC 2132,] particularly the Vendor Class Identifier 54 (option 60) and Vendor Encapsulated Options (option 43.) 56 These insights are presented in this informational Internet-Draft, 57 whose reason for being is to act as an aid to implementers of the 58 DHC protocol, and to future editors of the underlying RFCs and 59 selected, current Internet-Drafts. This memo is not being 60 proposed as a standards-track document, but rather as an aid to 61 clarify existing and future RFCs. 63 Network Working Group R. B. Hibbs, Pacific*Bell 64 Internet-Draft N. Lane, Wal-Mart Stores 65 Category: Informational Oct 1999 67 Table of Contents 69 1. Introduction..................................................2 70 2. Overview......................................................2 71 3. Cases.........................................................3 72 3.1. Vendor Classing.............................................3 73 3.1.1. Classification Scheme.....................................3 74 3.1.2. Mode of Operation.........................................4 75 3.2. User Classing...............................................5 76 3.3 Client Identifiers...........................................6 77 3.4 Option Default Values........................................6 78 3.4.1 IP Stack Options...........................................7 79 3.4.2 Other Options..............................................7 80 3.5 Who Wins in a Conflict?......................................7 81 4. Discussion....................................................8 82 4.1 Vendor Classing..............................................8 83 4.2 User Classing...............................................22 84 4.3 Client Identifiers..........................................22 85 4.4 Option Default Values.......................................22 86 4.5 Who Wins in a Conflict?.....................................22 87 5. Acknowledgements.............................................22 88 6. Security Considerations......................................22 89 7. References...................................................23 90 8. Editors' Addresses...........................................23 91 9. Full Copyright Statement.....................................23 93 1. Introduction 95 This memo was produced by the DHCP Working Group and attempts to 96 identify and clarify a few specific cases where the use of client 97 options is not rigorously specified by the Dynamic Host 98 Configuration Protocol. 100 This memo does not cover every DHCP/BOOTP client option nor every 101 element of a DHCP/BOOTP request/response packet. 103 This memo is based on the Internet standards-track DHC protocol as 104 defined by documents [RFC2131 and RFC2132]. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 107 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in 109 document [RFC2119]. 111 2. Overview 113 DHCP is widely used by many different vendors of computer and 114 networking hardware and software to provide a straightforward 115 means of supplying IP address and networking configuration data to 116 individual client hosts from DHCP servers. The Requests for 117 Comments (RFCs) that specify the protocol and the configuration 118 elements that may be specified by a DHCP message exchange have 119 grown significantly as the protocol has become more widely 120 deployed until we find ourselves in the situation we experience 122 Network Working Group R. B. Hibbs, Pacific*Bell 123 Internet-Draft N. Lane, Wal-Mart Stores 124 Category: Informational Oct 1999 126 today with nearly 100 options the network administrator can use to 127 perform semi-automatic configuration of client hosts. The 128 proliferation of options has led to a small number of cases where 129 the interaction among options is not rigorously specified, causing 130 confusion or interoperability failures. This RFC attempts to 131 identify some of these cases and clarify the expected behavior of 132 both client and server. 134 In this memo, the specific cases to be studied will be first 135 identified and, hopefully, clarified, then some of the discussion 136 that lead to the author's contentions about the correct use of the 137 client options will be presented to show the rationale for 138 inclusion. 140 At the time of writing, the authors do not know the eventual form 141 of the investigation that led to the production of this memo. 142 Three alternatives exist: (1) publication as an "informational" 143 RFC, (2) publication as a "best computing practices" (BCP) memo, 144 or (3) justification for revision of the basic DHCP RFCs. None of 145 these is preferred by the authors over any other. Presumably the 146 DHC Working Group will review and decide the best course for the 147 memo. 149 3. Cases 151 3.1. Vendor Classing 153 Vendor classing is provided through the use of options 60 (Vendor 154 Class Identifier) and 43 (Vendor Encapsulated Options), in 155 conjunction with option 55 (Parameter Request List.) 157 3.1.1. Classification Scheme 159 Vendor classing attempts to address the question of "How do I 160 classify a client such that the client receives appropriate 161 configuration data for their specific situation?" While every 162 deployment of DHCP will have its own unique characteristics, 163 consider a large organization with geographically-dispersed 164 locations where clients requiring DHC services may be in different 165 organizational entities, with different user processing functions, 166 and of different generations and types. It is likely that the 167 client population can be viewed a number of different ways, such 168 as: 170 1. Geographical ("Where is the client located?") 172 2. Organizational ("In which department is the client 173 located?") 175 3. Functional ("What job does the user perform?") 177 4. Regulatory ("What statutory constraints affect the user?") 179 5. Networking ("How is the client connected to other hosts?") 181 6. Environmental ("What software is the client using?") 183 Network Working Group R. B. Hibbs, Pacific*Bell 184 Internet-Draft N. Lane, Wal-Mart Stores 185 Category: Informational Oct 1999 187 7. Platform ("What hardware is the client using?") 189 Some organizations may have fewer, others more, than these 190 different views. Each view, especially the latter three given 191 above, may be further subdivided: for example, Environment might 192 have as many as four dimensions (operating system, TCP/IP network 193 stack, DHCP client, and principal application software) while 194 Platform most likely always has two (system manufacturer's model, 195 network interface vendor's model.) RFCs 2131 and 2132 do not 196 specifically address how many views a network administrator could 197 or should take of the environment under their purview, but the 198 underlying intent seems to be that all necessary and sufficient 199 information to permit informed configuration of client hosts ought 200 to be available for exchange and use by the clients and servers. 202 Where does the Vendor Class fit in the hierarchy of client views? 203 While it could legitimately be argued that any "vendor-supplied" 204 component of the client (either hardware or software) is a 205 candidate, one of the editors believes the proper fit is aligned 206 with either the TCP/IP stack or DHCP client based on the following 207 argument: 209 Network interfaces numbered in conformance with IEEE standards 210 contain a manufacturer's code as part of the interface's hardware 211 address, which is already carried in the 'chaddr' field of a BOOTP 212 packet. Assuming that Mike Henry's proposal for a Globally Unique 213 Identifier tied to specific host systems is accepted by systems 214 manufacturers there will be a way to completely identify [newer] 215 systems unambiguously. Having covered the two primary views of 216 the hardware platform, the remaining "vendor-supplied" components 217 are software (or, possibly, embedded firmware such as a writeable 218 control store or flash PROM.) It will be argued in the next 219 section that application software is a user, not vendor, 220 characteristic. As the underlying operating system software is 221 much less important for determining client networking behavior 222 than the choice of the TCP/IP stack or DHCP client, the editors 223 propose discounting operating system as a factor. 225 In some cases LAA devices, where the vendor's MAC address is 226 replaced with a Locally-Assigned Address from the range 400000 227 (assigned by the IEEE for local addressing), it may be necessary 228 to override the Globally Unique Identifier that Mike Henry is 229 proposing. In some environments LAAs are a requirement for in 230 order to effectively manage BOOTP devices. However, when talking 231 DHCP, we should REQUIRE the use of the Client Identifier in lieu 232 of the LAA, so the conflict may not be as great. (Should we also 233 require that the Client Identifier be configurable by an 234 administrator?) 236 3.1.2. Mode of Operation 238 The basic mode of operation for vendor classing is that during the 239 discovery phase the client broadcasts a DHCPDISCOVER message 240 containing Vendor Class Information (option 60) which the server 241 optionally uses to select an IP address and other configuration 242 information to offer to the client in a DHCPOFFER message. Note 243 the word "optionally." RFC2132 stops short of mandating any 245 Network Working Group R. B. Hibbs, Pacific*Bell 246 Internet-Draft N. Lane, Wal-Mart Stores 247 Category: Informational Oct 1999 249 specific kind of server behavior on receipt of this option. This 250 is not quite an oversight by the RFC editor: the editor had to 251 consider the possibility that any specific server might not be 252 configured to recognize a particular Vendor Class Identifier. As 253 that case is an implementation issue under control of the network 254 administrator, not the editor, any server response MUST be 255 optional. 257 Let's continue by assuming that the server has been configured to 258 recognize the Vendor Class Identifier sent by the client, and has 259 stored some specific data to be used to configure any client 260 belonging to that class. What does the server do? There are 261 essentially three approaches: use the Vendor Encapsulated Options 262 string (option 43) to return data to the client, return data in 263 one of the options specified in the "Host Requirements" RFC [must 264 supply RFC number here � ed.], or return data in some other 265 option. 267 Which approach is correct? Actually, all of them are! The one 268 chosen by a specific client-server pairing is a matter that SHOULD 269 be specified by the vendor who declares the need for vendor- 270 specific options data. While no hard and fast rules apply, 271 generally, if the data to be returned is covered by the Host 272 Requirements, it SHOULD be returned in the proper option. If not 273 covered by Host Requirements, but is covered by another, existing 274 option, that option should be used. The Vendor Encapsulated 275 Options string should be used for data that fits within the 276 limitations of a BOOTP/DHCP option field (0-255 octets) that 277 doesn't also fit any other existing option. Note that except for 278 options necessitated by the Host Requirements, the option number 279 of the correct option(s) MUST be included in the Parameter Request 280 List (option 55) or the server has no obligation to return it to 281 the client. 283 What about longer aggregations of configuration data than will fit 284 in a single option? The editors are not prepared to offer a 285 general solution to this problem but will suggest that it may be 286 possible to use existing protocol facilities, such as 'file' or 287 'sname' to accomplish transfer of larger amounts of configuration 288 data. Clearly, this is an area for more study. 290 3.2. User Classing 292 User classing is provided through the use of option NN (User Class 293 Identifier) in conjunction with option 55. While it basically 294 performs a similar function to vendor classing, it differs in one 295 major respect: there is no User Encapsulated Options data 296 specified for DHCP. 298 The history of User Classing is a bit murky. First proposed (if 299 our memory is correct!) by Glenn Stump, the Internet-Draft of this 300 option was allowed to expire, then it was resurrected to the 301 objections of some members of the Working Group, and has again 302 fallen into limbo. The editors believe it continues to have value 303 and should be reinstated. An example will hopefully illustrate: 305 Network Working Group R. B. Hibbs, Pacific*Bell 306 Internet-Draft N. Lane, Wal-Mart Stores 307 Category: Informational Oct 1999 309 Suppose your organization operates a large call center, large 310 enough to warrant its own tandem switch which contains an adjunct 311 processor that includes DNS service for client workstations 312 matching client telephone sets. Further, suppose that in order to 313 perform database lookup of customer data based on incoming 314 Automatic Number Identification data and answer incoming calls 315 with 400 milliseconds, there is an insufficient time budget to 316 perform certain functions such as dynamic DNS update or even 317 dynamic assignment of IP addresses for newly-activated clients. 318 This entire group of clients are a natural grouping whose user 319 characteristics differ considerably from all others within your 320 organization. At the very minimum, they should be associated with 321 the adjunct DNS server rather than your organization's primary DNS 322 servers. Perhaps they are to be given a unique Domain Name. 324 The editors are neutral as to whether or not the User Class 325 Identifier option should have a corresponding User Encapsulated 326 Options String option, similar to option 43, but do believe that 327 the User Class Identifier should be part of the DHCP options 328 universe. 330 3.3 Client Identifiers 332 The DHCP Client Identifier (option 63) is specified in RFC2131 as 333 the primary key for locating IP address leases by both client and 334 server, yet considerable misunderstanding remains about this 335 option. Specific issues concern the uniqueness of the Client 336 Identifier and how the uniqueness influences selection of an IP 337 address lease to offer a client. 339 An early design decision for DHCP was to require the Client 340 Identifier to be unique only within a network segment. This 341 design choice permits roaming by mobile clients among a group of 342 disjoint subnets, and is a major convenience for implementers of 343 DHCP. Enlarging the scope of uniqueness for the Client Identifier 344 would "break" many existing installations, so is considered to be 345 "out-of-bounds" for future discussion. 347 As mentioned in section 3.1, Mike Henry of Intel Corporation 348 proposed a Globally Unique Identifier to the DHC Working group for 349 those instances where a unique identifier with scope greater than 350 a network segment is required. 352 Also, as mentioned in section 3.1.1, the editors believe that 353 providing an administrator the ability to configure the Client 354 Identifier may be a desirable feature for clients, especially if 355 the Globally Unique Identifier (tied to non-accessible hardware 356 identification) is available, and User Classing is not. This 357 would permit finer control of DHCP-supplied client configurations 358 by permitting more precise identification of the group to which a 359 particular client belongs. 361 3.4 Option Default Values 363 What happens when either the client does not request an option 364 essential to its operation, or the server is not configured to 365 provide that data (through oversight or administrative error)? 367 Network Working Group R. B. Hibbs, Pacific*Bell 368 Internet-Draft N. Lane, Wal-Mart Stores 369 Category: Informational Oct 1999 371 Are there reasonable default values that can be recommended for 372 specific options? While some values may be suggested [or 373 required] by Host Requirements and other RFCs, the editors believe 374 than a generally-accepted set of defaults that may be assumed by a 375 client or server deserves some additional study. 377 3.4.1 IP Stack Options 379 The editors know of very few DHCP clients that actually request 380 "path-mtu-discovery", but the host requirements RFCs state a 381 "reasonable" default for this value. Here there is a conflict 382 between the virtues of brevity, that is, supplying clients with 383 the smallest set of options necessary to begin functioning as a 384 host on the network, and the desirability of requiring minimal 385 assumed values by clients. The editors have encountered several 386 clients that were badly implemented, calling for every option (all 387 254!) in a Parameter Request List because they made no attempt to 388 understand or resolve the Host Requirements. 390 A related question is whether a DHCP server SHOULD send options it 391 knows to be required for successful operation (e.g., Router 392 Address) even if the client does not request them? The editors 393 know that many servers do send a minimal list of options, but is 394 there any need for agreement as to what constitutes a minimum set? 396 3.4.2 Other Options 398 Aside for options whose presence is required by various RFCs 399 (e.g., DHCP Message Type) is there any need to identify a minimal 400 set of other options to provide a client? Is there any need to 401 codify default values for options not mandated by the RFCs? 403 3.5 Who Wins in a Conflict? 405 In many of the Internet protocols, there are well-established 406 rules for settling conflicts that may arise in operation, for 407 example, the "lowest bid wins" rule often applies for durations or 408 lifetimes. When considering DHCP client options, can a consistent 409 and defensible set of guidelines or rules be established to 410 determine whether the client or server "wins" when a conflict 411 arises? 413 Taking the example of lease duration, the server is required only 414 to offer a lease to a client that is of satisfactory duration to 415 the server� if the client wants a longer lease, it merely chooses 416 not to request assignment of the offered lease. The assumption is 417 that the client can choose among competing offers, selecting the 418 one it prefers. Is there any need to recommend client behavior if 419 it should not like any of the offered leases. 421 The editors believe it is important to recommend client behavior 422 upon non-acceptance of an IP lease. Some sites have defined this 423 behavior for their clients, especially in reference to IPv4 424 autoconfiguration (not-enforceable until the clients actually 425 honor the new DHCP "do not autoconfigure" option), but is a 426 general policy appropriate? 428 Network Working Group R. B. Hibbs, Pacific*Bell 429 Internet-Draft N. Lane, Wal-Mart Stores 430 Category: Informational Oct 1999 432 The editors suggest the following client behavior: If a client is 433 offered a lease without acceptable parameters, but still allows 434 IP-level connectivity to function, the client MUST accept the. If 435 the client does not get a lease or if it is told not to configure 436 the IP stack, the client MAY continue trying at the standard 437 exponential backoff intervals as specified in RFC 2131. 439 For many administrators it is crucial that clients accept valid 440 leases offered to them: Failure to do so may result in a non- 441 functioning client. The editors are undecided if it is a good or 442 poor idea to permit clients to suggest values for options such as 443 the DNS Server, but we are in agreement that if a client were to 444 refuse all offered leases because a critical parameter didn't 445 satisfy the client's notion of what it was willing to accept, then 446 chaos would reign in the network. 448 4. Discussion 450 4.1 Vendor Classing 452 The following discussion took place on the ISC dhcp-server mailing 453 list during June, July and August of 1999, and has been edited 454 considerably to preserve the context of each comment while 455 eliminating unnecessary remarks: 457 [Bahman Sistany] 459 I have been looking for any "published" vendor-specific options by 460 vendors and I cannot find any. Does anyone know of a situation 461 where these options are being used (i.e., requested by a DHCP 462 client and their values returned by a DHCP server?) 464 The ISC dhcpd ignores any unrecognized options such as Vendor 465 Specific Options as the protocol suggests it can do. But if the 466 server were to return values for these options it would need to 467 know about them in advance. That's what I mean by "published" 468 above. 470 [Mike Henry] 472 The PXE specification from Intel addresses this area. At 473 http://developer.intel.com/ial/wfm/tools/index.htm you can find 474 specifications (including a generally useful set of vendor- 475 specific options), source code and binaries for the NT and Linux 476 environments to provide proxies for DHCP services not capable of 477 parsing Option 60, and the same for a boot service (daemon) to 478 allow a heterogeneous set of bootservers for the booting client to 479 choose from. 481 [unknown] 483 Sun JavaStations, the Solaris 7 boot system (I think), the Solaris 484 8 boot system (definitely), Sun workstation network boot ROMS.... 485 You're probably seeing a pattern here. I think vendors other than 486 Sun are using vendor encapsulated options, but I don't know of any 487 off the top of my head. 489 Network Working Group R. B. Hibbs, Pacific*Bell 490 Internet-Draft N. Lane, Wal-Mart Stores 491 Category: Informational Oct 1999 493 [Nathan Lane] 495 Unfortunately, there is a great lack of understanding in the 496 industry what these options are for. I know of one thin client 497 vendor that packs in the parameter request list ALL 127 site- 498 specific options (128 through 254) then parses each one to see if 499 their magic cookie is in the data of each option. Just off the top 500 of my head, it looks to me like a vendor should send in the 501 parameter request list option 60, vendor class identifier and then 502 the server should respond with the information in option 43 (data 503 which is totally opaque to the server.) Is this everyone else's 504 understanding of how it should operate? 506 [Ted Lemon] 508 It's mine, anyway. 510 [Stuart Stevens] 512 It is my understanding that Windows 2000 will support 3 vendor 513 options (1-3) and the Windows 2000 DHCP server is already 514 programmed for these vendor options. I am not aware of these 515 options being published. 517 I thought that option 43 is more appropriate for the parameter 518 request list. 520 [Ted Lemon] 522 The client should send option 60 and request option 43 in the 523 parameter request list. 525 [unknown] 527 The ISC DHCP server needs to know about them before the first 528 client requests one, but since you can define them in the 529 configuration file, it's not the case that the server needs to 530 have them compiled in or anything like that. 532 [Nathan Lane] 534 [Client] behavior, at least to me, seems well-defined in RFCs 535 2131, 2132 and 1497. Our "site specific" option space, 128 536 through 254, is being polluted by vendors who don't understand or 537 won't use vendor specific codes. 539 [Barr Hibbs] 541 I've seen the "request all" behavior from both Linux and thin 542 clients, and I wonder why they are so clueless... 544 I'm not sure how the association between vendor class identifier 545 (60) and vendor encapsulated options (43) can be inferred -- I see 546 lots of clients send me option 43, but they almost never request 547 it! 549 Network Working Group R. B. Hibbs, Pacific*Bell 550 Internet-Draft N. Lane, Wal-Mart Stores 551 Category: Informational Oct 1999 553 I've also had thin client vendors tell me that I should "capture" 554 the data sent in option 43 and return it to them when requested! 556 This may be an area where the RFCs need to be reworded. 558 [Dave Gotwisner] 560 The only problem with using option 43 (or options 128-254) for the 561 vendor specific options, as I understand it, is that option 43 is 562 of the same format as the rest of the option space (i.e., a series 563 of option numbers, followed by lengths and data) and there is no 564 definition that states what vendors use what codes. If the DHCP 565 server is not smart enough to send different option 43's (or any 566 other option) based upon a vendor or client ID (note, this would 567 typically need to be a wild-carded selection, since otherwise you 568 hit the same problems of the old bootptab format -- proliferation 569 of entries because of MAC values). ISC MAY be smart enough to be 570 configured this way. Microsoft's DHCP server is not, at least 571 without having to do a lot of work to get around their UI. 573 As someone else said, Microsoft 2000 is using vendor options 1, 2, 574 and 3. Assuming this is correct, how do you deal with someone 575 else who is also defining their device to look for these options 576 (for completely different purposes), especially when both are 577 deployed in the corporate environment? 579 RFC 2132 says that options 128 to 254 are reserved for site 580 specific options. Vendors can read this two ways. I read it one 581 way, Nathan, another. Is the site specificity specifically for 582 the end user to use, or is it for manufacturers to provide 583 optional capabilities (outside of RFC 2132) which a site may use 584 if they want those capabilities? If I want to guarantee that I 585 don't step on another vendor's custom option, the only way I can 586 do it is to submit a set of options (via RFC) and go through the 587 review process. This may be the best way, but the under option 588 128 space is filling up, and I don't think it is appropriate for 589 each vendor to reserve blocks of a very limited space for their 590 stuff (just look at some of the options already reserved (10, 14, 591 16, 68, 75, and 76 all come to mind)). Novell submitted their own 592 set of options in RFC 2241 using 85 and 86. 594 We are a vendor. We make network terminals and Windows-based 595 terminals. We have several different product lines, all of which 596 want a different set of data for configuration. Our customer base 597 has stated that they want to use DHCP to be able to configure the 598 devices for ease of use. Many have also demanded plug and play 599 capability -- you connect the device to your network and turn it 600 on, everything that you need for running the device the way the 601 customer wants autoconfigures itself from the network. 603 Some of our products hard code the set of options (in 128-254) 604 that they use, and once the terminal comes up, you can configure 605 it. If our choice of defaults is acceptable (i.e., doesn't 606 conflict with other devices in the customer's environment) no 607 other configuration need be done with respect to the DHCP set of 608 options. 610 Network Working Group R. B. Hibbs, Pacific*Bell 611 Internet-Draft N. Lane, Wal-Mart Stores 612 Category: Informational Oct 1999 614 Our other products use string tags (TAG = value) with a custom tag 615 prefix, which we put anywhere in the 128-254 option space. This 616 allows the administrator to chose what options he/she wants to 617 support and to guarantee that there isn't a conflict with other 618 devices in the environment from the DHCP server side. 619 Unfortunately, this approach forced us to request (via option 43) 620 all options in 128-254. 622 Neither is a good solution. Unfortunately, there is no way to 623 really protect against two devices (from two different vendors) 624 from wanting the same option number for different purposes, 625 whether they are through option 60 (in encapsulated form) or in 626 128-254. 628 DHCP servers which are smart enough (or configurable enough) to 629 provide different data based upon Vendor ID, Client ID, or some 630 other tag would do a great deal to reduce the problem, but not all 631 DHCP server vendors do this. 633 Of course, servers which only support the minimum record size and 634 fail to support Option Overload further exacerbate the problem. 636 Also, clients which support option 18 (Extensions Path) would also 637 help, especially if the format of this option lent itself to 638 editing the file. Unfortunately, many clients fail to support it 639 without going outside the client. 641 [David Corlette] 643 Excellent points all, but it seems to me that there are lots of 644 ways around the problems stated. For instance, why not pick a 645 single option, register it so no other vendor "steps" on it, and 646 then have that option contain the address of a server that can 647 distribute configuration information for your terminals? As I 648 understand it, this is similar to the TFTP server option; indeed, 649 you could probably use that one if need be. 651 As for the configuration server, you could quite quickly write one 652 up, as all it really needs to do is be a FTP or TFTP server, maybe 653 with some custom code to detect what type of terminal is 654 requesting. Release the server as source code; it can run on 655 the same machine as the DHCP server, and you could provide 656 precompiled binaries for the major platforms. 658 This is how many other terminals and machines autoconfigure, why 659 not yours? I'm sure there are other ways to deal with the issue, 660 all of which avoid the overuse/misuse of the ill-defined vendor 661 option codes. I mention the above only as an example of how 662 simple it would be to limit your use of option codes to a single, 663 already defined one. 665 [Brian Murrell] 667 You have to tell the server [which clients] are what kind [of 668 devices]. This is how Merit RADIUS deals with the same problem in 669 the "vendor-defined attribute" space. You tell it that a device 670 is (say) a Livingston Portmaster and it uses the Livingston 672 Network Working Group R. B. Hibbs, Pacific*Bell 673 Internet-Draft N. Lane, Wal-Mart Stores 674 Category: Informational Oct 1999 676 attribute space. You tell it that a device is an Ascend TNT and 677 it uses the Ascend attribute space. This is quite manageable for 678 things like NAS. Doing the same in a DHCP environment does get a 679 whole lot uglier, I will admit. Perhaps the use of Client 680 Identifiers will help this situation out. Perhaps vendors should 681 be identifying themselves in the Client Identifier and that can be 682 keyed (via wild cards, perhaps) to a vendor option space. 684 How about clients that do the same thing [support only the minimum 685 packet size]? 687 [Ted Lemon] 689 The option codes in [option 43] are reserved for the vendor's use. 690 Every DHCP server of which I am aware, with one possible 691 exception, is capable of returning different values based on the 692 value in option 60 that the vendor sends. 694 [Dave Gotwisner] 696 If you can tailor option 43 based upon what option 60 sends, you 698 should also be able to tailor what other options get sent, since 699 you may want to use a different Boot File (option 13), swap server 700 (option 16), extensions path (option 18), maximum record size 701 (option 57), etc. Likewise, you should be able to send different 702 128-254 based upon option 60. Option 43 is limited in that it 703 can't span the standard space + sname + file space's, individual 704 options can span them. 706 [Ted Lemon] 708 This isn't a practical limitation, as long as you negotiate for a 709 large DHCP packet using the Maximum Message Size option. You 710 aren't hoping to stuff your complete terminal configuration into a 711 DHCP packet, I hope! 713 [Dave Gotwisner] 715 My issue is that [one vendor] uses vendor option 1, [a second] 716 uses vendor option 1, [a third] uses vendor option 1. Without a 717 smart server capable of triggering based upon option 60 (or 718 equivalent), a site that uses all three products may get incorrect 719 behavior on two of them, maybe even disastrous behavior making the 720 device unusable. 722 [Ted Lemon] 724 The protocol specifically states that option one in the vendor 725 option data is different for every vendor. 727 [Barr Hibbs] 729 Some of the problems [we've experienced with client 730 implementations include;] 732 Network Working Group R. B. Hibbs, Pacific*Bell 733 Internet-Draft N. Lane, Wal-Mart Stores 734 Category: Informational Oct 1999 736 1. Clients would send five or six options in the 128-254 range in 737 discover packets, and if we didn't return those in an ack 738 packet, they would immediately cycle back to discover, without 739 issuing a release, effectively abandoning the lease. Of 740 course, they were offered the same lease again, and so we 741 cycled endlessly, never committing a lease to the client.... 743 2. If we didn't return options 58 and 59 (T1 and T2 values) they 744 dropped into INIT-REBOOT state every 60 seconds and sent a new 745 request packet. 747 3. Clients expected the TFTP server option to contain the address 748 of the Winterm server. Curious, but not really a problem, just 749 a misinformed use of the option. 751 4. lients complained when we didn't return hostname, even though 752 it wasn't in the parameter request list. [The vendor] never 753 budged on this one, completely ignoring the RFCs, including 754 host requirements. 756 5. [One vendor] insisted that RFC2131 wasn't compliant with 757 RFC1541 and refused to acknowledge that 2131 superseded 1541. 759 [Nathan Lane] 761 [One vendor] wouldn't use the "swap-server" option because they 762 felt it was reserved for use by Sun Microsystems. They wouldn't 763 use the "rootpath" option because it didn't exactly specify the 764 swap path file (wouldn't conventional use be to append rootpath 765 with "client-name.swapfile" or something like what Sun used to do 766 with that option?) 768 [Mike Henry] 770 Interesting -- the fuzziness in this area (option 60 and option 771 43) is surprising, but in retrospect it certainly explains a bit 772 of our confusion about guidance received in this area that didn't 773 seem to match our reading of the specification. But then, we 774 weren't very confident of our reading in the first place because 775 the spec did not seem to be completely clear. 777 My reading of the text for option 43 (see below) is that the 778 client is expected to use option 43 to send information about 779 itself to the DHCP server and the DHCP server is expected use 780 option 43 to send configuration information to the client that is 781 specific to the client's vendor class. In both cases, the 782 information in option 43 is specific to the vendor class indicated 783 in option 60. Is this interpretation incorrect? Are there DHCP 784 servers that actually parse incoming option 43? 786 The general direction we have been given is to embed client- 787 specific information in the Vendor Class Identifier (option 60). 788 This clearly can be made to work, but embedding a number of 789 attributes in option 60 leads to creation of ad hoc formats for 790 what amount to encapsulated options. Setting aside for a moment 791 current DHCP service implementation, it seems like it would be 792 more logical to put this "subclass" information into option 43 and 794 Network Working Group R. B. Hibbs, Pacific*Bell 795 Internet-Draft N. Lane, Wal-Mart Stores 796 Category: Informational Oct 1999 798 leave option 60 to define the general class. This seems to be 799 what option 43 text is saying. Am I misinterpreting the option 43 800 text? 802 Finally, taking the option 60 and option 43 text together, my 803 impression is that the DHCP service is supposed to know what to do 804 with option 60, but option 43 is opaque, to be interpreted by 805 vendor specific code. Does this imply that DHCP services should 806 have some means of plugging in vendor specific code to interpret 807 option 43 and, presumably, generate the option 43 response to the 808 client? Also, it seems to imply that the DHCP service should hand 809 off processing to the vendor supplied code if the DHCP service 810 sees an option 60! 812 [Bahman Sistany] 814 As far as I can tell, you are almost right. Here's my 815 correction(s). Someone else will correct me if I misunderstand 816 Vendor specific options as well. The client wants a specific 817 vendor's options, say, vendor1. Here is part of what he'll send 818 the server: 820 option code, length, value 822 60 7 vendor1 824 55 1 43 826 So this means I am [requesting vendor-specific options] for 827 vendor1. The server should have something like the following in 828 its config file: 830 vendor1 data1 832 vendor2 data2 834 ... 836 When the server receives the request, it will send data1 in 837 encapsulated form using option 43: 839 option code, length, value 841 43 len(data1) data1 843 Note that like you said data1 is opaque as far as the server is 844 concerned and the client who asked for [the option data] should be 845 able to interpret [the option] on its own. The server doesn't 846 really care about this part though. 848 Here's a question on something related: My understanding is that 849 the client can ask for specific options using option 55 (parameter 850 request). The server doesn't have to supply those though. Also 851 the server can send arbitrary options (not requested by the 852 client) and the client can pick and choose among them or not use 853 any of them at all. Is this right? 855 Network Working Group R. B. Hibbs, Pacific*Bell 856 Internet-Draft N. Lane, Wal-Mart Stores 857 Category: Informational Oct 1999 859 [Mike Henry] 861 Thanks, but I am afraid you only addressed the well-known half of 862 the question. There is no doubt the DHCP service returns 863 information to the client in encapsulated options in Option 43. 864 However, the part I am really interested in is whether real "live" 865 DHCP services have the ability to make use of encapsulated options 866 within Option 43 that the client sends to the DHCP service. RFC 867 2132 seems to clearly say this is expected use of Option 43, but I 868 am not aware of a DHCP service actually capable of providing this 869 functionality. 871 Here is the 2132 text: 873 "This option is used by clients and servers to exchange vendor- 874 specific information. The information is an opaque object of n 875 octets, presumably interpreted by vendor-specific code on the 876 clients and servers." 878 [Bahman Sistany] 880 You are right in interpreting the protocol (I reread it again and 881 compared it to RADIUS which in a very limited sense is a similar 882 protocol). However, I have not heard of any DHCP servers that 883 would actually use vs. info sent by the client (they ignore it [as 884 permitted by the RFC.]) If a server has to use this info, then 885 like you said it would have to load some [vendor-specific] code 886 based on the value of option 60. 888 [Barr Hibbs] 890 Am I correct that what Mike and Bahman are asserting is that a 891 DHCP server should not only accept option 43 from a client but 892 should also do "something" with the received data? Does that 893 "something" specifically include, in your understanding, returning 894 the encapsulated data, verbatim, to the client if the client 895 requests that option 43 be returned by its inclusion in the 896 parameter request list? 898 While that is certainly possible, I wonder if that is the "right 899 thing" to do because of the Pandora's box that it opens: I've 900 already had problems, as Nathan has, with thin-client vendors who 901 think that a DHCP server should be an external data store for a 902 client. If your view of a server's role is to receive, store, and 903 replay encapsulated data using option 43, then I don't know how we 904 could prevent similar interpretations of a server's role for most 905 other options. 907 I also wonder how you might resolve potential configuration and 908 usage problems: suppose a server is configured with a specific 909 set of vendor-encapsulated options for a specific vendor-class 910 identifier and the client sends additional or different 911 encapsulated options to the server as part of the protocol 912 exchange -- what does the server do? 914 Finally, I wonder what was intended by the RFC text that Mike 915 quotes, as it does seem to imply that a server ought to be able to 917 Network Working Group R. B. Hibbs, Pacific*Bell 918 Internet-Draft N. Lane, Wal-Mart Stores 919 Category: Informational Oct 1999 921 take some action based on the receipt of vendor encapsulated 922 options. 924 [Kevin Bracey] 926 As I understand it, the logic looks like this: The client MAY 927 send option 60, vendor class. If it does, it may also send option 928 43, vendor specific options. 930 If the server gets option 60, and recognizes the vendor class: 932 1. Process the vendor specific options in a vendor-specific way 933 (specific to the vendor class of the client). This may affect 934 what is returned. For example, you might have a vendor specific 935 option for a device to specify its memory size, which might 936 lead the server to return a different boot file. 938 2. Return any standard options suitable for that vendor class. 940 3. Put any vendor-specific options for the client in option 43. 942 Option 43 can mean anything the client wants, in either direction 943 -- what it means depends on the vendor class. The suboptions 944 could be totally different in the two directions, although that 945 would probably be a bad design decision. 947 The behavior you describe of "storing" option 43 would be one 948 permissible use of it, as "vendor-specific" allows anything. It 949 would take more than a [server configuration] tweak to achieve 950 that though, and it would have to be a particular behavior invoked 951 only for certain known vendor classes. 953 [Barr Hibbs] 955 This gets to the heart of the issue that Mike Henry raised! 957 ...just what does "Process the ... options ..." actually mean to 958 you (and anyone else who wishes to comment)? If you are 959 suggesting that an arbitrary server must somehow not only be 960 configured to identify the vendor class but also perform some 961 vendor-specific processing on the encapsulated options which may 962 have been sent by the client, just how does the vendor/ user/ 963 administrator "know" what processing to perform? Do you imagine 964 that a vendor would develop "plug-ins" for popular DHCP servers? 965 Would DHCP servers be required to publish an API to permit plug- 966 ins? Do you expect that IETF would codify the interface in an 967 RFC? This gets nasty "real quick now!" 969 ...I have no problem at all with option 43 containing opaque 970 values, which is the current state of RFC 2132, for the server to 971 return from its configuration to a client when requested, but if 972 you are suggesting that the server somehow accepts one set for 973 some purpose then returns another set, I really would have to see 974 a convincing argument to support that.... I think it would be an 975 implementation nightmare with very, very few benefits to offset 976 the monumental headaches. 978 Network Working Group R. B. Hibbs, Pacific*Bell 979 Internet-Draft N. Lane, Wal-Mart Stores 980 Category: Informational Oct 1999 982 ...my specific objection to storing, then replaying, any option 983 (not just 43) is that such behavior turns the DHCP server from an 984 information provider to a limited file server or database system, 985 neither of which is an appropriate use for a service which is 986 intended only to provide the networking configuration for 987 acceptable clients. My servers support over 118,000 clients: if 988 I had to store up to 255 bytes of data for 254 options for all of 989 my clients, then the additional storage requirement for my servers 990 could be as great as 7.6 Gbytes! This is because I don't believe 991 you could prevent nearly every option from being used this way: 992 after all, why couldn't a client "suggest" which name servers or 993 routers it prefers to use? 995 This is a great deal more than merely tweaking [the server 996 configuration] -- it is, I believe, a complete change in the way 997 some of us believe a DHCP service should operate. If a client 998 really needs a file service to save data between reboots, then it 999 should do so with some server intended to be a data repository, 1000 not try to piggy-back onto DHCP, which really is not intended for 1001 that purpose. I also can't imagine how any DHCP server could 1002 effectively implement per-vendor processing of options where the 1003 server actually manipulates what is supposed to be opaque data 1004 (option 43). 1006 [Nathan Lane] 1008 I can see this need [to process vendor-specific options in a 1009 vendor-specific way.] I think there must be a better or different 1010 way. 1012 Yes, the DHCP server does indeed know how to process vendor class 1013 options on a vendor by vendor basis and will pick a vendor 1014 specific option 43 to send only to that vendor's product. It does 1015 NOT get as complicated as you mention, though, in my opinion. The 1016 server designer and implementer must actually communicate with the 1017 developer implementing the device and get the specifications and 1018 requirements from the vendor. No more can a device implementer 1019 envision that DHCP only provides an IP address. It is the host 1020 configuration protocol, so it reasons that one should use it to 1021 configure as much as possible in the device that relates to its 1022 network configuration and connectivity. It sure does make a 1023 server implementer's job much more complex, but I think it is a 1024 reasonable step to take. The device implementer's desires are for 1025 "plug and play network". I feel DHCP's job is to facilitate that 1026 idea. 1028 I feel it is absolutely not the DHCP server's responsibility to 1029 actually touch or process any data within option 43 and, according 1030 to my interpretation of the RFCs, the client has no business even 1031 sending an option 43. 1033 [It should] not be necessary [that a vendor develop "plug-ins" for 1034 popular DHCP servers.] A vendor class would become a fairly 1035 overloaded field, but I think it is appropriate in this example. I 1036 see the configuration like this (pseudo code): 1038 if [ vendor-class-identifier = "SUN-JAVASTATION-8MB" ] 1040 Network Working Group R. B. Hibbs, Pacific*Bell 1041 Internet-Draft N. Lane, Wal-Mart Stores 1042 Category: Informational Oct 1999 1044 then send option-43 1046 "sun-specific-data-for-an-8MB-javastation" 1048 else 1050 if .... 1052 endif 1054 endif 1056 # resume normal option processing to build the 1057 # rest of the response packet. 1059 Yes, this would require most servers out there right now to be 1060 modified and a scripting like language possibly be established. 1062 It is not the IETF's job to specify any DHCP vendor's API or 1063 interface [to a DHCP server to permit "plug-ins."] Perhaps the 1064 IETF should specify how a DHCP server should make the information 1065 available to an externalized process (I'm not using externalized 1066 to mean a callout; just generically) or script language. I 1067 believe the ISC server's direction is to make some kind of 1068 embedded language available for just this type of thing. It is 1069 nearing a requirement in my environment that servers do implement 1070 some kind of regular expression pattern matching on DHCP input 1071 packets and intelligently decide, via external policy lookups, 1072 what should be done with the device. It is much more than just 1073 "to give an IP or not to give an IP." 1075 I really do not see option 43 as a bi-directional communications 1076 channel. It is one way only. 1078 No, I don't support [storing, then replaying any option] either. A 1079 DHCP server is not a little 255 byte or so data store the client 1080 can use to stash that information. However, if I have a vendor 1081 class of "SUN-JAVASTATION," I DO want to be able to send a pre- 1082 configured option 43 to the client. 1084 Again, no way. I [also] couldn't support a client suggesting what 1085 it wanted [for every option] -- that would be mighty presumptuous 1086 of it! 1088 I don't see the server as actually manipulating the opaque data. 1089 I see the server intelligently choosing which set of opaque data 1090 to send to which set of vendor classes. 1092 I strongly think it is time to clarify the clarifications in 1093 regards to vendor encapsulated options and their behavior. I 1094 think we should take this to DHC and start working up a draft. I 1095 have a good base for one that is an internal document I'm 1096 completing describing our internal requirements for a DHCP client. 1098 [Nicolas Williams] 1100 Network Working Group R. B. Hibbs, Pacific*Bell 1101 Internet-Draft N. Lane, Wal-Mart Stores 1102 Category: Informational Oct 1999 1104 DHCP's original purpose was to allow clients to obtain a 1105 reasonably small set of configuration information needed to 1106 connect to a network and where the clients know nothing more than 1107 a simple Client Identifier which can be as simple as the vendor 1108 provided hardware address of the vendor provided network 1109 interface. 1111 This "small set of configuration information" means network 1112 address and routing configuration + name service configuration + 1113 [optionally] boot file server and path. The client can go from 1114 there. 1116 It would be best if DHCP continued to do nothing more than that. 1118 If any software on the client needs to be configured beyond the 1119 above, then a different protocol should then be used to retrieve 1120 the information from a configuration server; this is much easier 1121 to do when a client has become a full-fledged node in a network 1122 and there's no excuse for a client not to be able to do this today 1123 via DHCP. 1125 What's missing is an open protocol and data format standard for 1126 storing, administering and obtaining post-DHCP configuration 1127 information. Some platforms offer their own system to do this, 1128 usually based on a proprietary name service system; I'm thinking 1129 of NetInfo (for NextStep/OpenStep/MacOS), NIS/NIS+ (Sun et. al.), 1130 Active Directory (Microsoft, Cisco), even flat files (for poor 1131 administrators). 1133 [It] is reasonable [not to expect the server as actually 1134 manipulating opaque data,] but there will always be people for 1135 whom it's not enough. 1137 [Barr Hibbs] 1139 The pseudo-code fragment from Nathan's note is a pretty concise 1140 statement of how I believe that options 60 and 43 should interact. 1141 Given that, I imagine that it is a vendor's responsibility to 1142 offer network administrators something like the following: 1144 "PDQ tiny-stations (tm) identify themselves to a DHCP server by 1145 sending a vendor class identifier (option 60) that specifically 1146 names the tiny-station sending the request. Series 100's send the 1147 string 'pdq-tiny-station-100' while series 250's send the string 1148 'pdq-tiny-station-250.' If your tiny-station series 100 contains 1149 the optional writeable control store (model 103) your DHCP server 1150 should return the hex value '30:cf:12:59:72:21' as a vendor 1151 encapsulated option 43...." 1153 Then it would be the responsibility of the network administration 1154 to ensure that, like most other bits and pieces of configuration 1155 data, the precise vendor encapsulated option (if any) for a 1156 specific vendor class identifier is included in the server 1157 configuration. 1159 I also agree that the vendor class identifier could be used in 1160 similar ways with other options, for example: 1162 Network Working Group R. B. Hibbs, Pacific*Bell 1163 Internet-Draft N. Lane, Wal-Mart Stores 1164 Category: Informational Oct 1999 1166 if [ vendor-class-identifier = "SONY Playstation SE" 1168 then 1170 send interface-mtu 768 1172 endif 1174 I believe that is a consistent use of the class identifier as 1175 well. 1177 I think we are actually closing on the essential points here. 1179 I'll have to defer to Ralph about original purposes, but I do 1180 generally concur that DHCP is not really intended to do anything 1181 other than configure the networking software in a host computer. 1182 Whatever the protocol options may have grown to include, the 1183 process for getting there is well understood and very public, so 1184 unless there is a compelling need such as inability to 1185 interoperate or insufficient options to communicate required 1186 information, we pretty much have to live with what we've got. 1188 I'm all for (1) configuring the networking software, (2) 1189 identifying servers which can provide extended system 1190 configuration, and (3) identifying services location servers which 1191 can locate applications or generally useful services for a host 1192 computer. I think (2) and (3) are consistent with my 1193 understanding of the purposes of DHCP. I'm not so keen on 1194 providing application-specific configuration data or locating 1195 individual application-specific configuration servers, but only 1196 because I can imagine these growing in number almost without 1197 limit. A lot of this discussion really should be moved to the 1198 dhcpv4 mailing list, as most implementers follow that list. 1200 I generally support the more general configuration of client 1201 software beyond network configuration, although I would add the 1202 restriction that some other source of this configuration 1203 *referral* data other than the DHCP server be used. What I mean by 1204 that is that instead of the DHCP server having an option for each 1205 of the dozens or thousands of applications which might like to 1206 receive configuration data from a server, that it might be a 1207 better choice to devise something akin to the Service Location 1208 protocol to provide the address of individual configuration 1209 servers -- all the DHCP server would do is to identify the 1210 "application configuration locator" server. 1212 The proper forum for this is the DHC Working Group of IETF -- 1213 possibly a BOF session at the next working groups meeting to 1214 determine if there is interest, then either the formation of a new 1215 working group or incorporation of this work item into an existing 1216 group's charter. 1218 [Dave Gotwisner] 1220 Nathan is dead on with [his contention that DHCP should be able to 1221 be used to configure as much as possible in the client,] although 1222 it isn't just the implementers who desire plug and play. Many of 1224 Network Working Group R. B. Hibbs, Pacific*Bell 1225 Internet-Draft N. Lane, Wal-Mart Stores 1226 Category: Informational Oct 1999 1228 our customers are requiring that DHCP be used in many different 1229 methods to configure our devices so the user/ administrator does 1230 not have to configure them once deployed. They want to turn on the 1231 power and let DHCP provided all useful information to configure 1232 the device. Unfortunately, with the UDP packet length, this can't 1233 really happen on complex devices, but an appropriate sub-set can 1234 be used. Other methods are better for plug and play configuration 1235 in some ways and worse in some ways (SNMP comes to mind). With 1236 plug-and-play of complex devices being configured through option 1237 43, you run into two fundamental problems. First, the UDP maximum 1238 record size (option 57 may allow an increase in size, but not 1239 significantly). Second, option 43 is limited to 255 bytes in 1240 length, and if you encapsulate several strings (such as network 1241 pathnames) you will exceed this length for option 43. 1243 My only other objection to option 43 (and option 18, for that 1244 matter) is that it is a bear to create an opaque option containing 1245 a heterogeneous set of option types. It makes perfect sense to 1246 send it as encapsulated data, but the tools should be smarter in 1247 how to deal with it, maybe as (expanding on Nathan's pseudo-code 1248 below): 1250 if [ vendor-class-identifier = "SUN-JAVASTATION-8MB" ] 1252 then send option-43 { 1254 send vendor-option-1 1256 { IP = 10.2.1.2,10.2.1.3 }, 1258 send vendor-option-2 { STR = "string-data"}, 1260 send vendor-option-3 { STR = "more-string-data" }, 1262 send vendor-option-30 { BOOL = True }; 1264 }; 1266 else 1268 .... 1270 endif 1272 This may be harder to parse, but it would make it a lot easier to 1273 configure by a user. 1275 I understand that option 43 should be [used for responses] as 1276 illustrated above. What I don't understand is why you can't also 1277 send different other options in this case also 1279 send option-48 (X font server) 1281 send option-49 (XDMCP addresses) 1283 or other options as well, since you might want a different set of 1284 fonts loaded (for example) based upon which manufacturer's X 1286 Network Working Group R. B. Hibbs, Pacific*Bell 1287 Internet-Draft N. Lane, Wal-Mart Stores 1288 Category: Informational Oct 1999 1290 terminal you are booting. Although the RFC says that an 43 should 1291 be given based upon option 60, it does not say that other options 1292 can't be given as well. 1294 There are some options which a client can suggest (requested IP, 1295 requested lease time, max record size, host name (only because the 1296 server can also provide one), and option overload). I don't know 1297 why a device which has no knowledge of it's global environment can 1298 request DNS, routers, etc. 1300 [Nathan Lane] 1302 I should have put that (sending options other than 43) in my 1303 example since Kevin specifically mentioned a different bootfile. 1305 Do you think we should take this over to DHC and get something 1306 going on it? We all have access to the same RFCs...I just wonder 1307 why people have such a broad interpretation of how they should be 1308 used. 1310 [C. J. Consodine] 1312 Any "intelligent" complication should be in the code TFTP'd to the 1313 client, not in that executed by the DHCP server. Option 60 should 1314 contain a UPC or other SKU or SKU class identifier. The logic 1315 then is to add on additional options found via option 60, 1316 subordinate to those options that would have been sent without it. 1317 One needs but a single pass through the rule base. The 1318 alternative is to add in CGI, Java or DLL like madness. 1320 5. Acknowledgements 1322 This document is the result of work undertaken the by DHCP working 1323 group. The authors would like to particularly acknowledge the 1324 development team from Carnegie-Mellon University whose work 1325 creating a private MIB for their DHCP server inspired the 1326 development of this proposal. In particular, many thanks to Ryan 1327 Troll who provided a great deal of useful feedback during the 1328 development of this MIB. 1330 6. Security Considerations 1332 Security considerations are not applicable, as this memo does not 1333 specify the interoperation of network equipment or systems, merely 1334 seeking to codify some elements of behavior not well specified by 1335 the underlying protocol. 1337 Network Working Group R. B. Hibbs, Pacific*Bell 1338 Internet-Draft N. Lane, Wal-Mart Stores 1339 Category: Informational Oct 1999 1341 7. References 1343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1344 Requirement Levels", RFC 2119, BCP 14, March 1997. 1346 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1347 2131, March 1997. 1349 [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP 1350 Vendor Extensions", RFC 2132, March 1997. 1352 8. Editors' Addresses 1354 Richard Barr Hibbs 1355 Pacific Bell 1356 666 Folsom Street, Room 1225 1357 San Francisco, CA 94107-1384 1358 USA 1360 Phone: +1 415-545-1576 1361 Fax: +1 415-543-3539 1362 Email: rbhibbs@pacbell.com 1364 Nathan Lane 1365 Wal-Mart Stores, Inc. 1366 702 SW 8th Street 1367 Bentonville, AR 72716-8025 1368 USA 1370 Phone: +1 501-277-5786 1371 Fax: +1 501-273-6879 1372 Email: nathan@terminus.com 1374 9. Full Copyright Statement 1376 Copyright (C) The Internet Society (1999). All Rights Reserved. 1378 This document and translations of it may be copied and furnished 1379 to others, and derivative works that comment on or otherwise 1380 explain it or assist in its implementation may be prepared, 1381 copied, published and distributed, in whole or in part, without 1382 restriction of any kind, provided that the above copyright notice 1383 and this paragraph are included on all such copies and derivative 1384 works. However, this document itself may not be modified in any 1385 way, such as by removing the copyright notice or references to the 1386 Internet Society or other Internet organizations, except as needed 1387 for the purpose of developing Internet standards in which case the 1388 procedures for copyrights defined in the Internet Standards 1389 process must be followed, or as required to translate it into 1390 languages other than English. 1392 The limited permissions granted above are perpetual and will not 1393 be revoked by the Internet Society or its successors or assigns. 1395 Network Working Group R. B. Hibbs, Pacific*Bell 1396 Internet-Draft N. Lane, Wal-Mart Stores 1397 Category: Informational Oct 1999 1399 This document and the information contained herein is provided on 1400 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1401 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1402 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1403 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1404 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.