Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 Interpreting Client Options for the Dynamic Host Configuration Protocol Saved: Thursday, October 14, 1999, 2:24 PM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract During the summer of 1999, a grand debate raged over the correct interpretation of several DHCP client options as described in [RFC 2132], as well as the need for one option whose proposing Internet-Draft expired. As a result of that debate, the authors gained some insights into the intended (or unintended!) interpretation of certain options defined in [RFC 2132,] particularly the Vendor Class Identifier (option 60) and Vendor Encapsulated Options (option 43.) These insights are presented in this informational Internet-Draft, whose reason for being is to act as an aid to implementers of the DHC protocol, and to future editors of the underlying RFCs and selected, current Internet-Drafts. This memo is not being proposed as a standards-track document, but rather as an aid to clarify existing and future RFCs. Hibbs & Lane Expires: Oct 1999 + 6 months [Page 1] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 Table of Contents 1. Introduction..................................................2 2. Overview......................................................2 3. Cases.........................................................3 3.1. Vendor Classing.............................................3 3.1.1. Classification Scheme.....................................3 3.1.2. Mode of Operation.........................................4 3.2. User Classing...............................................5 3.3 Client Identifiers...........................................6 3.4 Option Default Values........................................6 3.4.1 IP Stack Options...........................................7 3.4.2 Other Options..............................................7 3.5 Who Wins in a Conflict?......................................7 4. Discussion....................................................8 4.1 Vendor Classing..............................................8 4.2 User Classing...............................................22 4.3 Client Identifiers..........................................22 4.4 Option Default Values.......................................22 4.5 Who Wins in a Conflict?.....................................22 5. Acknowledgements.............................................22 6. Security Considerations......................................22 7. References...................................................23 8. Editors' Addresses...........................................23 9. Full Copyright Statement.....................................23 1. Introduction This memo was produced by the DHCP Working Group and attempts to identify and clarify a few specific cases where the use of client options is not rigorously specified by the Dynamic Host Configuration Protocol. This memo does not cover every DHCP/BOOTP client option nor every element of a DHCP/BOOTP request/response packet. This memo is based on the Internet standards-track DHC protocol as defined by documents [RFC2131 and RFC2132]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in document [RFC2119]. 2. Overview DHCP is widely used by many different vendors of computer and networking hardware and software to provide a straightforward means of supplying IP address and networking configuration data to individual client hosts from DHCP servers. The Requests for Comments (RFCs) that specify the protocol and the configuration elements that may be specified by a DHCP message exchange have grown significantly as the protocol has become more widely deployed until we find ourselves in the situation we experience Hibbs & Lane Expires: Oct 1999 + 6 months [Page 2] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 today with nearly 100 options the network administrator can use to perform semi-automatic configuration of client hosts. The proliferation of options has led to a small number of cases where the interaction among options is not rigorously specified, causing confusion or interoperability failures. This RFC attempts to identify some of these cases and clarify the expected behavior of both client and server. In this memo, the specific cases to be studied will be first identified and, hopefully, clarified, then some of the discussion that lead to the author's contentions about the correct use of the client options will be presented to show the rationale for inclusion. At the time of writing, the authors do not know the eventual form of the investigation that led to the production of this memo. Three alternatives exist: (1) publication as an "informational" RFC, (2) publication as a "best computing practices" (BCP) memo, or (3) justification for revision of the basic DHCP RFCs. None of these is preferred by the authors over any other. Presumably the DHC Working Group will review and decide the best course for the memo. 3. Cases 3.1. Vendor Classing Vendor classing is provided through the use of options 60 (Vendor Class Identifier) and 43 (Vendor Encapsulated Options), in conjunction with option 55 (Parameter Request List.) 3.1.1. Classification Scheme Vendor classing attempts to address the question of "How do I classify a client such that the client receives appropriate configuration data for their specific situation?" While every deployment of DHCP will have its own unique characteristics, consider a large organization with geographically-dispersed locations where clients requiring DHC services may be in different organizational entities, with different user processing functions, and of different generations and types. It is likely that the client population can be viewed a number of different ways, such as: 1. Geographical ("Where is the client located?") 2. Organizational ("In which department is the client located?") 3. Functional ("What job does the user perform?") 4. Regulatory ("What statutory constraints affect the user?") 5. Networking ("How is the client connected to other hosts?") 6. Environmental ("What software is the client using?") Hibbs & Lane Expires: Oct 1999 + 6 months [Page 3] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 7. Platform ("What hardware is the client using?") Some organizations may have fewer, others more, than these different views. Each view, especially the latter three given above, may be further subdivided: for example, Environment might have as many as four dimensions (operating system, TCP/IP network stack, DHCP client, and principal application software) while Platform most likely always has two (system manufacturer's model, network interface vendor's model.) RFCs 2131 and 2132 do not specifically address how many views a network administrator could or should take of the environment under their purview, but the underlying intent seems to be that all necessary and sufficient information to permit informed configuration of client hosts ought to be available for exchange and use by the clients and servers. Where does the Vendor Class fit in the hierarchy of client views? While it could legitimately be argued that any "vendor-supplied" component of the client (either hardware or software) is a candidate, one of the editors believes the proper fit is aligned with either the TCP/IP stack or DHCP client based on the following argument: Network interfaces numbered in conformance with IEEE standards contain a manufacturer's code as part of the interface's hardware address, which is already carried in the 'chaddr' field of a BOOTP packet. Assuming that Mike Henry's proposal for a Globally Unique Identifier tied to specific host systems is accepted by systems manufacturers there will be a way to completely identify [newer] systems unambiguously. Having covered the two primary views of the hardware platform, the remaining "vendor-supplied" components are software (or, possibly, embedded firmware such as a writeable control store or flash PROM.) It will be argued in the next section that application software is a user, not vendor, characteristic. As the underlying operating system software is much less important for determining client networking behavior than the choice of the TCP/IP stack or DHCP client, the editors propose discounting operating system as a factor. In some cases LAA devices, where the vendor's MAC address is replaced with a Locally-Assigned Address from the range 400000 (assigned by the IEEE for local addressing), it may be necessary to override the Globally Unique Identifier that Mike Henry is proposing. In some environments LAAs are a requirement for in order to effectively manage BOOTP devices. However, when talking DHCP, we should REQUIRE the use of the Client Identifier in lieu of the LAA, so the conflict may not be as great. (Should we also require that the Client Identifier be configurable by an administrator?) 3.1.2. Mode of Operation The basic mode of operation for vendor classing is that during the discovery phase the client broadcasts a DHCPDISCOVER message containing Vendor Class Information (option 60) which the server optionally uses to select an IP address and other configuration information to offer to the client in a DHCPOFFER message. Note the word "optionally." RFC2132 stops short of mandating any Hibbs & Lane Expires: Oct 1999 + 6 months [Page 4] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 specific kind of server behavior on receipt of this option. This is not quite an oversight by the RFC editor: the editor had to consider the possibility that any specific server might not be configured to recognize a particular Vendor Class Identifier. As that case is an implementation issue under control of the network administrator, not the editor, any server response MUST be optional. Let's continue by assuming that the server has been configured to recognize the Vendor Class Identifier sent by the client, and has stored some specific data to be used to configure any client belonging to that class. What does the server do? There are essentially three approaches: use the Vendor Encapsulated Options string (option 43) to return data to the client, return data in one of the options specified in the "Host Requirements" RFC [must supply RFC number here û ed.], or return data in some other option. Which approach is correct? Actually, all of them are! The one chosen by a specific client-server pairing is a matter that SHOULD be specified by the vendor who declares the need for vendor- specific options data. While no hard and fast rules apply, generally, if the data to be returned is covered by the Host Requirements, it SHOULD be returned in the proper option. If not covered by Host Requirements, but is covered by another, existing option, that option should be used. The Vendor Encapsulated Options string should be used for data that fits within the limitations of a BOOTP/DHCP option field (0-255 octets) that doesn't also fit any other existing option. Note that except for options necessitated by the Host Requirements, the option number of the correct option(s) MUST be included in the Parameter Request List (option 55) or the server has no obligation to return it to the client. What about longer aggregations of configuration data than will fit in a single option? The editors are not prepared to offer a general solution to this problem but will suggest that it may be possible to use existing protocol facilities, such as 'file' or 'sname' to accomplish transfer of larger amounts of configuration data. Clearly, this is an area for more study. 3.2. User Classing User classing is provided through the use of option NN (User Class Identifier) in conjunction with option 55. While it basically performs a similar function to vendor classing, it differs in one major respect: there is no User Encapsulated Options data specified for DHCP. The history of User Classing is a bit murky. First proposed (if our memory is correct!) by Glenn Stump, the Internet-Draft of this option was allowed to expire, then it was resurrected to the objections of some members of the Working Group, and has again fallen into limbo. The editors believe it continues to have value and should be reinstated. An example will hopefully illustrate: Hibbs & Lane Expires: Oct 1999 + 6 months [Page 5] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 Suppose your organization operates a large call center, large enough to warrant its own tandem switch which contains an adjunct processor that includes DNS service for client workstations matching client telephone sets. Further, suppose that in order to perform database lookup of customer data based on incoming Automatic Number Identification data and answer incoming calls with 400 milliseconds, there is an insufficient time budget to perform certain functions such as dynamic DNS update or even dynamic assignment of IP addresses for newly-activated clients. This entire group of clients are a natural grouping whose user characteristics differ considerably from all others within your organization. At the very minimum, they should be associated with the adjunct DNS server rather than your organization's primary DNS servers. Perhaps they are to be given a unique Domain Name. The editors are neutral as to whether or not the User Class Identifier option should have a corresponding User Encapsulated Options String option, similar to option 43, but do believe that the User Class Identifier should be part of the DHCP options universe. 3.3 Client Identifiers The DHCP Client Identifier (option 63) is specified in RFC2131 as the primary key for locating IP address leases by both client and server, yet considerable misunderstanding remains about this option. Specific issues concern the uniqueness of the Client Identifier and how the uniqueness influences selection of an IP address lease to offer a client. An early design decision for DHCP was to require the Client Identifier to be unique only within a network segment. This design choice permits roaming by mobile clients among a group of disjoint subnets, and is a major convenience for implementers of DHCP. Enlarging the scope of uniqueness for the Client Identifier would "break" many existing installations, so is considered to be "out-of-bounds" for future discussion. As mentioned in section 3.1, Mike Henry of Intel Corporation proposed a Globally Unique Identifier to the DHC Working group for those instances where a unique identifier with scope greater than a network segment is required. Also, as mentioned in section 3.1.1, the editors believe that providing an administrator the ability to configure the Client Identifier may be a desirable feature for clients, especially if the Globally Unique Identifier (tied to non-accessible hardware identification) is available, and User Classing is not. This would permit finer control of DHCP-supplied client configurations by permitting more precise identification of the group to which a particular client belongs. 3.4 Option Default Values What happens when either the client does not request an option essential to its operation, or the server is not configured to provide that data (through oversight or administrative error)? Hibbs & Lane Expires: Oct 1999 + 6 months [Page 6] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 Are there reasonable default values that can be recommended for specific options? While some values may be suggested [or required] by Host Requirements and other RFCs, the editors believe than a generally-accepted set of defaults that may be assumed by a client or server deserves some additional study. 3.4.1 IP Stack Options The editors know of very few DHCP clients that actually request "path-mtu-discovery", but the host requirements RFCs state a "reasonable" default for this value. Here there is a conflict between the virtues of brevity, that is, supplying clients with the smallest set of options necessary to begin functioning as a host on the network, and the desirability of requiring minimal assumed values by clients. The editors have encountered several clients that were badly implemented, calling for every option (all 254!) in a Parameter Request List because they made no attempt to understand or resolve the Host Requirements. A related question is whether a DHCP server SHOULD send options it knows to be required for successful operation (e.g., Router Address) even if the client does not request them? The editors know that many servers do send a minimal list of options, but is there any need for agreement as to what constitutes a minimum set? 3.4.2 Other Options Aside for options whose presence is required by various RFCs (e.g., DHCP Message Type) is there any need to identify a minimal set of other options to provide a client? Is there any need to codify default values for options not mandated by the RFCs? 3.5 Who Wins in a Conflict? In many of the Internet protocols, there are well-established rules for settling conflicts that may arise in operation, for example, the "lowest bid wins" rule often applies for durations or lifetimes. When considering DHCP client options, can a consistent and defensible set of guidelines or rules be established to determine whether the client or server "wins" when a conflict arises? Taking the example of lease duration, the server is required only to offer a lease to a client that is of satisfactory duration to the serverù if the client wants a longer lease, it merely chooses not to request assignment of the offered lease. The assumption is that the client can choose among competing offers, selecting the one it prefers. Is there any need to recommend client behavior if it should not like any of the offered leases. The editors believe it is important to recommend client behavior upon non-acceptance of an IP lease. Some sites have defined this behavior for their clients, especially in reference to IPv4 autoconfiguration (not-enforceable until the clients actually honor the new DHCP "do not autoconfigure" option), but is a general policy appropriate? Hibbs & Lane Expires: Oct 1999 + 6 months [Page 7] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 The editors suggest the following client behavior: If a client is offered a lease without acceptable parameters, but still allows IP-level connectivity to function, the client MUST accept the. If the client does not get a lease or if it is told not to configure the IP stack, the client MAY continue trying at the standard exponential backoff intervals as specified in RFC 2131. For many administrators it is crucial that clients accept valid leases offered to them: Failure to do so may result in a non- functioning client. The editors are undecided if it is a good or poor idea to permit clients to suggest values for options such as the DNS Server, but we are in agreement that if a client were to refuse all offered leases because a critical parameter didn't satisfy the client's notion of what it was willing to accept, then chaos would reign in the network. 4. Discussion 4.1 Vendor Classing The following discussion took place on the ISC dhcp-server mailing list during June, July and August of 1999, and has been edited considerably to preserve the context of each comment while eliminating unnecessary remarks: [Bahman Sistany] I have been looking for any "published" vendor-specific options by vendors and I cannot find any. Does anyone know of a situation where these options are being used (i.e., requested by a DHCP client and their values returned by a DHCP server?) The ISC dhcpd ignores any unrecognized options such as Vendor Specific Options as the protocol suggests it can do. But if the server were to return values for these options it would need to know about them in advance. That's what I mean by "published" above. [Mike Henry] The PXE specification from Intel addresses this area. At http://developer.intel.com/ial/wfm/tools/index.htm you can find specifications (including a generally useful set of vendor- specific options), source code and binaries for the NT and Linux environments to provide proxies for DHCP services not capable of parsing Option 60, and the same for a boot service (daemon) to allow a heterogeneous set of bootservers for the booting client to choose from. [unknown] Sun JavaStations, the Solaris 7 boot system (I think), the Solaris 8 boot system (definitely), Sun workstation network boot ROMS.... You're probably seeing a pattern here. I think vendors other than Sun are using vendor encapsulated options, but I don't know of any off the top of my head. Hibbs & Lane Expires: Oct 1999 + 6 months [Page 8] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 [Nathan Lane] Unfortunately, there is a great lack of understanding in the industry what these options are for. I know of one thin client vendor that packs in the parameter request list ALL 127 site- specific options (128 through 254) then parses each one to see if their magic cookie is in the data of each option. Just off the top of my head, it looks to me like a vendor should send in the parameter request list option 60, vendor class identifier and then the server should respond with the information in option 43 (data which is totally opaque to the server.) Is this everyone else's understanding of how it should operate? [Ted Lemon] It's mine, anyway. [Stuart Stevens] It is my understanding that Windows 2000 will support 3 vendor options (1-3) and the Windows 2000 DHCP server is already programmed for these vendor options. I am not aware of these options being published. I thought that option 43 is more appropriate for the parameter request list. [Ted Lemon] The client should send option 60 and request option 43 in the parameter request list. [unknown] The ISC DHCP server needs to know about them before the first client requests one, but since you can define them in the configuration file, it's not the case that the server needs to have them compiled in or anything like that. [Nathan Lane] [Client] behavior, at least to me, seems well-defined in RFCs 2131, 2132 and 1497. Our "site specific" option space, 128 through 254, is being polluted by vendors who don't understand or won't use vendor specific codes. [Barr Hibbs] I've seen the "request all" behavior from both Linux and thin clients, and I wonder why they are so clueless... I'm not sure how the association between vendor class identifier (60) and vendor encapsulated options (43) can be inferred -- I see lots of clients send me option 43, but they almost never request it! Hibbs & Lane Expires: Oct 1999 + 6 months [Page 9] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 I've also had thin client vendors tell me that I should "capture" the data sent in option 43 and return it to them when requested! This may be an area where the RFCs need to be reworded. [Dave Gotwisner] The only problem with using option 43 (or options 128-254) for the vendor specific options, as I understand it, is that option 43 is of the same format as the rest of the option space (i.e., a series of option numbers, followed by lengths and data) and there is no definition that states what vendors use what codes. If the DHCP server is not smart enough to send different option 43's (or any other option) based upon a vendor or client ID (note, this would typically need to be a wild-carded selection, since otherwise you hit the same problems of the old bootptab format -- proliferation of entries because of MAC values). ISC MAY be smart enough to be configured this way. Microsoft's DHCP server is not, at least without having to do a lot of work to get around their UI. As someone else said, Microsoft 2000 is using vendor options 1, 2, and 3. Assuming this is correct, how do you deal with someone else who is also defining their device to look for these options (for completely different purposes), especially when both are deployed in the corporate environment? RFC 2132 says that options 128 to 254 are reserved for site specific options. Vendors can read this two ways. I read it one way, Nathan, another. Is the site specificity specifically for the end user to use, or is it for manufacturers to provide optional capabilities (outside of RFC 2132) which a site may use if they want those capabilities? If I want to guarantee that I don't step on another vendor's custom option, the only way I can do it is to submit a set of options (via RFC) and go through the review process. This may be the best way, but the under option 128 space is filling up, and I don't think it is appropriate for each vendor to reserve blocks of a very limited space for their stuff (just look at some of the options already reserved (10, 14, 16, 68, 75, and 76 all come to mind)). Novell submitted their own set of options in RFC 2241 using 85 and 86. We are a vendor. We make network terminals and Windows-based terminals. We have several different product lines, all of which want a different set of data for configuration. Our customer base has stated that they want to use DHCP to be able to configure the devices for ease of use. Many have also demanded plug and play capability -- you connect the device to your network and turn it on, everything that you need for running the device the way the customer wants autoconfigures itself from the network. Some of our products hard code the set of options (in 128-254) that they use, and once the terminal comes up, you can configure it. If our choice of defaults is acceptable (i.e., doesn't conflict with other devices in the customer's environment) no other configuration need be done with respect to the DHCP set of options. Hibbs & Lane Expires: Oct 1999 + 6 months [Page 10] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 Our other products use string tags (TAG = value) with a custom tag prefix, which we put anywhere in the 128-254 option space. This allows the administrator to chose what options he/she wants to support and to guarantee that there isn't a conflict with other devices in the environment from the DHCP server side. Unfortunately, this approach forced us to request (via option 43) all options in 128-254. Neither is a good solution. Unfortunately, there is no way to really protect against two devices (from two different vendors) from wanting the same option number for different purposes, whether they are through option 60 (in encapsulated form) or in 128-254. DHCP servers which are smart enough (or configurable enough) to provide different data based upon Vendor ID, Client ID, or some other tag would do a great deal to reduce the problem, but not all DHCP server vendors do this. Of course, servers which only support the minimum record size and fail to support Option Overload further exacerbate the problem. Also, clients which support option 18 (Extensions Path) would also help, especially if the format of this option lent itself to editing the file. Unfortunately, many clients fail to support it without going outside the client. [David Corlette] Excellent points all, but it seems to me that there are lots of ways around the problems stated. For instance, why not pick a single option, register it so no other vendor "steps" on it, and then have that option contain the address of a server that can distribute configuration information for your terminals? As I understand it, this is similar to the TFTP server option; indeed, you could probably use that one if need be. As for the configuration server, you could quite quickly write one up, as all it really needs to do is be a FTP or TFTP server, maybe with some custom code to detect what type of terminal is requesting. Release the server as source code; it can run on the same machine as the DHCP server, and you could provide precompiled binaries for the major platforms. This is how many other terminals and machines autoconfigure, why not yours? I'm sure there are other ways to deal with the issue, all of which avoid the overuse/misuse of the ill-defined vendor option codes. I mention the above only as an example of how simple it would be to limit your use of option codes to a single, already defined one. [Brian Murrell] You have to tell the server [which clients] are what kind [of devices]. This is how Merit RADIUS deals with the same problem in the "vendor-defined attribute" space. You tell it that a device is (say) a Livingston Portmaster and it uses the Livingston Hibbs & Lane Expires: Oct 1999 + 6 months [Page 11] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 attribute space. You tell it that a device is an Ascend TNT and it uses the Ascend attribute space. This is quite manageable for things like NAS. Doing the same in a DHCP environment does get a whole lot uglier, I will admit. Perhaps the use of Client Identifiers will help this situation out. Perhaps vendors should be identifying themselves in the Client Identifier and that can be keyed (via wild cards, perhaps) to a vendor option space. How about clients that do the same thing [support only the minimum packet size]? [Ted Lemon] The option codes in [option 43] are reserved for the vendor's use. Every DHCP server of which I am aware, with one possible exception, is capable of returning different values based on the value in option 60 that the vendor sends. [Dave Gotwisner] If you can tailor option 43 based upon what option 60 sends, you should also be able to tailor what other options get sent, since you may want to use a different Boot File (option 13), swap server (option 16), extensions path (option 18), maximum record size (option 57), etc. Likewise, you should be able to send different 128-254 based upon option 60. Option 43 is limited in that it can't span the standard space + sname + file space's, individual options can span them. [Ted Lemon] This isn't a practical limitation, as long as you negotiate for a large DHCP packet using the Maximum Message Size option. You aren't hoping to stuff your complete terminal configuration into a DHCP packet, I hope! [Dave Gotwisner] My issue is that [one vendor] uses vendor option 1, [a second] uses vendor option 1, [a third] uses vendor option 1. Without a smart server capable of triggering based upon option 60 (or equivalent), a site that uses all three products may get incorrect behavior on two of them, maybe even disastrous behavior making the device unusable. [Ted Lemon] The protocol specifically states that option one in the vendor option data is different for every vendor. [Barr Hibbs] Some of the problems [we've experienced with client implementations include;] Hibbs & Lane Expires: Oct 1999 + 6 months [Page 12] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 1. Clients would send five or six options in the 128-254 range in discover packets, and if we didn't return those in an ack packet, they would immediately cycle back to discover, without issuing a release, effectively abandoning the lease. Of course, they were offered the same lease again, and so we cycled endlessly, never committing a lease to the client.... 2. If we didn't return options 58 and 59 (T1 and T2 values) they dropped into INIT-REBOOT state every 60 seconds and sent a new request packet. 3. Clients expected the TFTP server option to contain the address of the Winterm server. Curious, but not really a problem, just a misinformed use of the option. 4. lients complained when we didn't return hostname, even though it wasn't in the parameter request list. [The vendor] never budged on this one, completely ignoring the RFCs, including host requirements. 5. [One vendor] insisted that RFC2131 wasn't compliant with RFC1541 and refused to acknowledge that 2131 superseded 1541. [Nathan Lane] [One vendor] wouldn't use the "swap-server" option because they felt it was reserved for use by Sun Microsystems. They wouldn't use the "rootpath" option because it didn't exactly specify the swap path file (wouldn't conventional use be to append rootpath with "client-name.swapfile" or something like what Sun used to do with that option?) [Mike Henry] Interesting -- the fuzziness in this area (option 60 and option 43) is surprising, but in retrospect it certainly explains a bit of our confusion about guidance received in this area that didn't seem to match our reading of the specification. But then, we weren't very confident of our reading in the first place because the spec did not seem to be completely clear. My reading of the text for option 43 (see below) is that the client is expected to use option 43 to send information about itself to the DHCP server and the DHCP server is expected use option 43 to send configuration information to the client that is specific to the client's vendor class. In both cases, the information in option 43 is specific to the vendor class indicated in option 60. Is this interpretation incorrect? Are there DHCP servers that actually parse incoming option 43? The general direction we have been given is to embed client- specific information in the Vendor Class Identifier (option 60). This clearly can be made to work, but embedding a number of attributes in option 60 leads to creation of ad hoc formats for what amount to encapsulated options. Setting aside for a moment current DHCP service implementation, it seems like it would be more logical to put this "subclass" information into option 43 and Hibbs & Lane Expires: Oct 1999 + 6 months [Page 13] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 leave option 60 to define the general class. This seems to be what option 43 text is saying. Am I misinterpreting the option 43 text? Finally, taking the option 60 and option 43 text together, my impression is that the DHCP service is supposed to know what to do with option 60, but option 43 is opaque, to be interpreted by vendor specific code. Does this imply that DHCP services should have some means of plugging in vendor specific code to interpret option 43 and, presumably, generate the option 43 response to the client? Also, it seems to imply that the DHCP service should hand off processing to the vendor supplied code if the DHCP service sees an option 60! [Bahman Sistany] As far as I can tell, you are almost right. Here's my correction(s). Someone else will correct me if I misunderstand Vendor specific options as well. The client wants a specific vendor's options, say, vendor1. Here is part of what he'll send the server: option code, length, value 60 7 vendor1 55 1 43 So this means I am [requesting vendor-specific options] for vendor1. The server should have something like the following in its config file: vendor1 data1 vendor2 data2 ... When the server receives the request, it will send data1 in encapsulated form using option 43: option code, length, value 43 len(data1) data1 Note that like you said data1 is opaque as far as the server is concerned and the client who asked for [the option data] should be able to interpret [the option] on its own. The server doesn't really care about this part though. Here's a question on something related: My understanding is that the client can ask for specific options using option 55 (parameter request). The server doesn't have to supply those though. Also the server can send arbitrary options (not requested by the client) and the client can pick and choose among them or not use any of them at all. Is this right? Hibbs & Lane Expires: Oct 1999 + 6 months [Page 14] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 [Mike Henry] Thanks, but I am afraid you only addressed the well-known half of the question. There is no doubt the DHCP service returns information to the client in encapsulated options in Option 43. However, the part I am really interested in is whether real "live" DHCP services have the ability to make use of encapsulated options within Option 43 that the client sends to the DHCP service. RFC 2132 seems to clearly say this is expected use of Option 43, but I am not aware of a DHCP service actually capable of providing this functionality. Here is the 2132 text: "This option is used by clients and servers to exchange vendor- specific information. The information is an opaque object of n octets, presumably interpreted by vendor-specific code on the clients and servers." [Bahman Sistany] You are right in interpreting the protocol (I reread it again and compared it to RADIUS which in a very limited sense is a similar protocol). However, I have not heard of any DHCP servers that would actually use vs. info sent by the client (they ignore it [as permitted by the RFC.]) If a server has to use this info, then like you said it would have to load some [vendor-specific] code based on the value of option 60. [Barr Hibbs] Am I correct that what Mike and Bahman are asserting is that a DHCP server should not only accept option 43 from a client but should also do "something" with the received data? Does that "something" specifically include, in your understanding, returning the encapsulated data, verbatim, to the client if the client requests that option 43 be returned by its inclusion in the parameter request list? While that is certainly possible, I wonder if that is the "right thing" to do because of the Pandora's box that it opens: I've already had problems, as Nathan has, with thin-client vendors who think that a DHCP server should be an external data store for a client. If your view of a server's role is to receive, store, and replay encapsulated data using option 43, then I don't know how we could prevent similar interpretations of a server's role for most other options. I also wonder how you might resolve potential configuration and usage problems: suppose a server is configured with a specific set of vendor-encapsulated options for a specific vendor-class identifier and the client sends additional or different encapsulated options to the server as part of the protocol exchange -- what does the server do? Finally, I wonder what was intended by the RFC text that Mike quotes, as it does seem to imply that a server ought to be able to Hibbs & Lane Expires: Oct 1999 + 6 months [Page 15] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 take some action based on the receipt of vendor encapsulated options. [Kevin Bracey] As I understand it, the logic looks like this: The client MAY send option 60, vendor class. If it does, it may also send option 43, vendor specific options. If the server gets option 60, and recognizes the vendor class: 1. Process the vendor specific options in a vendor-specific way (specific to the vendor class of the client). This may affect what is returned. For example, you might have a vendor specific option for a device to specify its memory size, which might lead the server to return a different boot file. 2. Return any standard options suitable for that vendor class. 3. Put any vendor-specific options for the client in option 43. Option 43 can mean anything the client wants, in either direction -- what it means depends on the vendor class. The suboptions could be totally different in the two directions, although that would probably be a bad design decision. The behavior you describe of "storing" option 43 would be one permissible use of it, as "vendor-specific" allows anything. It would take more than a [server configuration] tweak to achieve that though, and it would have to be a particular behavior invoked only for certain known vendor classes. [Barr Hibbs] This gets to the heart of the issue that Mike Henry raised! ...just what does "Process the ... options ..." actually mean to you (and anyone else who wishes to comment)? If you are suggesting that an arbitrary server must somehow not only be configured to identify the vendor class but also perform some vendor-specific processing on the encapsulated options which may have been sent by the client, just how does the vendor/ user/ administrator "know" what processing to perform? Do you imagine that a vendor would develop "plug-ins" for popular DHCP servers? Would DHCP servers be required to publish an API to permit plug- ins? Do you expect that IETF would codify the interface in an RFC? This gets nasty "real quick now!" ...I have no problem at all with option 43 containing opaque values, which is the current state of RFC 2132, for the server to return from its configuration to a client when requested, but if you are suggesting that the server somehow accepts one set for some purpose then returns another set, I really would have to see a convincing argument to support that.... I think it would be an implementation nightmare with very, very few benefits to offset the monumental headaches. Hibbs & Lane Expires: Oct 1999 + 6 months [Page 16] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 ...my specific objection to storing, then replaying, any option (not just 43) is that such behavior turns the DHCP server from an information provider to a limited file server or database system, neither of which is an appropriate use for a service which is intended only to provide the networking configuration for acceptable clients. My servers support over 118,000 clients: if I had to store up to 255 bytes of data for 254 options for all of my clients, then the additional storage requirement for my servers could be as great as 7.6 Gbytes! This is because I don't believe you could prevent nearly every option from being used this way: after all, why couldn't a client "suggest" which name servers or routers it prefers to use? This is a great deal more than merely tweaking [the server configuration] -- it is, I believe, a complete change in the way some of us believe a DHCP service should operate. If a client really needs a file service to save data between reboots, then it should do so with some server intended to be a data repository, not try to piggy-back onto DHCP, which really is not intended for that purpose. I also can't imagine how any DHCP server could effectively implement per-vendor processing of options where the server actually manipulates what is supposed to be opaque data (option 43). [Nathan Lane] I can see this need [to process vendor-specific options in a vendor-specific way.] I think there must be a better or different way. Yes, the DHCP server does indeed know how to process vendor class options on a vendor by vendor basis and will pick a vendor specific option 43 to send only to that vendor's product. It does NOT get as complicated as you mention, though, in my opinion. The server designer and implementer must actually communicate with the developer implementing the device and get the specifications and requirements from the vendor. No more can a device implementer envision that DHCP only provides an IP address. It is the host configuration protocol, so it reasons that one should use it to configure as much as possible in the device that relates to its network configuration and connectivity. It sure does make a server implementer's job much more complex, but I think it is a reasonable step to take. The device implementer's desires are for "plug and play network". I feel DHCP's job is to facilitate that idea. I feel it is absolutely not the DHCP server's responsibility to actually touch or process any data within option 43 and, according to my interpretation of the RFCs, the client has no business even sending an option 43. [It should] not be necessary [that a vendor develop "plug-ins" for popular DHCP servers.] A vendor class would become a fairly overloaded field, but I think it is appropriate in this example. I see the configuration like this (pseudo code): if [ vendor-class-identifier = "SUN-JAVASTATION-8MB" ] Hibbs & Lane Expires: Oct 1999 + 6 months [Page 17] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 then send option-43 "sun-specific-data-for-an-8MB-javastation" else if .... endif endif # resume normal option processing to build the # rest of the response packet. Yes, this would require most servers out there right now to be modified and a scripting like language possibly be established. It is not the IETF's job to specify any DHCP vendor's API or interface [to a DHCP server to permit "plug-ins."] Perhaps the IETF should specify how a DHCP server should make the information available to an externalized process (I'm not using externalized to mean a callout; just generically) or script language. I believe the ISC server's direction is to make some kind of embedded language available for just this type of thing. It is nearing a requirement in my environment that servers do implement some kind of regular expression pattern matching on DHCP input packets and intelligently decide, via external policy lookups, what should be done with the device. It is much more than just "to give an IP or not to give an IP." I really do not see option 43 as a bi-directional communications channel. It is one way only. No, I don't support [storing, then replaying any option] either. A DHCP server is not a little 255 byte or so data store the client can use to stash that information. However, if I have a vendor class of "SUN-JAVASTATION," I DO want to be able to send a pre- configured option 43 to the client. Again, no way. I [also] couldn't support a client suggesting what it wanted [for every option] -- that would be mighty presumptuous of it! I don't see the server as actually manipulating the opaque data. I see the server intelligently choosing which set of opaque data to send to which set of vendor classes. I strongly think it is time to clarify the clarifications in regards to vendor encapsulated options and their behavior. I think we should take this to DHC and start working up a draft. I have a good base for one that is an internal document I'm completing describing our internal requirements for a DHCP client. [Nicolas Williams] Hibbs & Lane Expires: Oct 1999 + 6 months [Page 18] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 DHCP's original purpose was to allow clients to obtain a reasonably small set of configuration information needed to connect to a network and where the clients know nothing more than a simple Client Identifier which can be as simple as the vendor provided hardware address of the vendor provided network interface. This "small set of configuration information" means network address and routing configuration + name service configuration + [optionally] boot file server and path. The client can go from there. It would be best if DHCP continued to do nothing more than that. If any software on the client needs to be configured beyond the above, then a different protocol should then be used to retrieve the information from a configuration server; this is much easier to do when a client has become a full-fledged node in a network and there's no excuse for a client not to be able to do this today via DHCP. What's missing is an open protocol and data format standard for storing, administering and obtaining post-DHCP configuration information. Some platforms offer their own system to do this, usually based on a proprietary name service system; I'm thinking of NetInfo (for NextStep/OpenStep/MacOS), NIS/NIS+ (Sun et. al.), Active Directory (Microsoft, Cisco), even flat files (for poor administrators). [It] is reasonable [not to expect the server as actually manipulating opaque data,] but there will always be people for whom it's not enough. [Barr Hibbs] The pseudo-code fragment from Nathan's note is a pretty concise statement of how I believe that options 60 and 43 should interact. Given that, I imagine that it is a vendor's responsibility to offer network administrators something like the following: "PDQ tiny-stations (tm) identify themselves to a DHCP server by sending a vendor class identifier (option 60) that specifically names the tiny-station sending the request. Series 100's send the string 'pdq-tiny-station-100' while series 250's send the string 'pdq-tiny-station-250.' If your tiny-station series 100 contains the optional writeable control store (model 103) your DHCP server should return the hex value '30:cf:12:59:72:21' as a vendor encapsulated option 43...." Then it would be the responsibility of the network administration to ensure that, like most other bits and pieces of configuration data, the precise vendor encapsulated option (if any) for a specific vendor class identifier is included in the server configuration. I also agree that the vendor class identifier could be used in similar ways with other options, for example: Hibbs & Lane Expires: Oct 1999 + 6 months [Page 19] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 if [ vendor-class-identifier = "SONY Playstation SE" then send interface-mtu 768 endif I believe that is a consistent use of the class identifier as well. I think we are actually closing on the essential points here. I'll have to defer to Ralph about original purposes, but I do generally concur that DHCP is not really intended to do anything other than configure the networking software in a host computer. Whatever the protocol options may have grown to include, the process for getting there is well understood and very public, so unless there is a compelling need such as inability to interoperate or insufficient options to communicate required information, we pretty much have to live with what we've got. I'm all for (1) configuring the networking software, (2) identifying servers which can provide extended system configuration, and (3) identifying services location servers which can locate applications or generally useful services for a host computer. I think (2) and (3) are consistent with my understanding of the purposes of DHCP. I'm not so keen on providing application-specific configuration data or locating individual application-specific configuration servers, but only because I can imagine these growing in number almost without limit. A lot of this discussion really should be moved to the dhcpv4 mailing list, as most implementers follow that list. I generally support the more general configuration of client software beyond network configuration, although I would add the restriction that some other source of this configuration *referral* data other than the DHCP server be used. What I mean by that is that instead of the DHCP server having an option for each of the dozens or thousands of applications which might like to receive configuration data from a server, that it might be a better choice to devise something akin to the Service Location protocol to provide the address of individual configuration servers -- all the DHCP server would do is to identify the "application configuration locator" server. The proper forum for this is the DHC Working Group of IETF -- possibly a BOF session at the next working groups meeting to determine if there is interest, then either the formation of a new working group or incorporation of this work item into an existing group's charter. [Dave Gotwisner] Nathan is dead on with [his contention that DHCP should be able to be used to configure as much as possible in the client,] although it isn't just the implementers who desire plug and play. Many of Hibbs & Lane Expires: Oct 1999 + 6 months [Page 20] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 our customers are requiring that DHCP be used in many different methods to configure our devices so the user/ administrator does not have to configure them once deployed. They want to turn on the power and let DHCP provided all useful information to configure the device. Unfortunately, with the UDP packet length, this can't really happen on complex devices, but an appropriate sub-set can be used. Other methods are better for plug and play configuration in some ways and worse in some ways (SNMP comes to mind). With plug-and-play of complex devices being configured through option 43, you run into two fundamental problems. First, the UDP maximum record size (option 57 may allow an increase in size, but not significantly). Second, option 43 is limited to 255 bytes in length, and if you encapsulate several strings (such as network pathnames) you will exceed this length for option 43. My only other objection to option 43 (and option 18, for that matter) is that it is a bear to create an opaque option containing a heterogeneous set of option types. It makes perfect sense to send it as encapsulated data, but the tools should be smarter in how to deal with it, maybe as (expanding on Nathan's pseudo-code below): if [ vendor-class-identifier = "SUN-JAVASTATION-8MB" ] then send option-43 { send vendor-option-1 { IP = 10.2.1.2,10.2.1.3 }, send vendor-option-2 { STR = "string-data"}, send vendor-option-3 { STR = "more-string-data" }, send vendor-option-30 { BOOL = True }; }; else .... endif This may be harder to parse, but it would make it a lot easier to configure by a user. I understand that option 43 should be [used for responses] as illustrated above. What I don't understand is why you can't also send different other options in this case also send option-48 (X font server) send option-49 (XDMCP addresses) or other options as well, since you might want a different set of fonts loaded (for example) based upon which manufacturer's X Hibbs & Lane Expires: Oct 1999 + 6 months [Page 21] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 terminal you are booting. Although the RFC says that an 43 should be given based upon option 60, it does not say that other options can't be given as well. There are some options which a client can suggest (requested IP, requested lease time, max record size, host name (only because the server can also provide one), and option overload). I don't know why a device which has no knowledge of it's global environment can request DNS, routers, etc. [Nathan Lane] I should have put that (sending options other than 43) in my example since Kevin specifically mentioned a different bootfile. Do you think we should take this over to DHC and get something going on it? We all have access to the same RFCs...I just wonder why people have such a broad interpretation of how they should be used. [C. J. Consodine] Any "intelligent" complication should be in the code TFTP'd to the client, not in that executed by the DHCP server. Option 60 should contain a UPC or other SKU or SKU class identifier. The logic then is to add on additional options found via option 60, subordinate to those options that would have been sent without it. One needs but a single pass through the rule base. The alternative is to add in CGI, Java or DLL like madness. 5. Acknowledgements This document is the result of work undertaken the by DHCP working group. The authors would like to particularly acknowledge the development team from Carnegie-Mellon University whose work creating a private MIB for their DHCP server inspired the development of this proposal. In particular, many thanks to Ryan Troll who provided a great deal of useful feedback during the development of this MIB. 6. Security Considerations Security considerations are not applicable, as this memo does not specify the interoperation of network equipment or systems, merely seeking to codify some elements of behavior not well specified by the underlying protocol. Hibbs & Lane Expires: Oct 1999 + 6 months [Page 22] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 7. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. 8. Editors' Addresses Richard Barr Hibbs Pacific Bell 666 Folsom Street, Room 1225 San Francisco, CA 94107-1384 USA Phone: +1 415-545-1576 Fax: +1 415-543-3539 Email: rbhibbs@pacbell.com Nathan Lane Wal-Mart Stores, Inc. 702 SW 8th Street Bentonville, AR 72716-8025 USA Phone: +1 501-277-5786 Fax: +1 501-273-6879 Email: nathan@terminus.com 9. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Hibbs & Lane Expires: Oct 1999 + 6 months [Page 23] Network Working Group R. B. Hibbs, Pacific*Bell Internet-Draft N. Lane, Wal-Mart Stores Category: Informational Oct 1999 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hibbs & Lane Expires: Oct 1999 + 6 months [Page 24]