INTERNET DRAFT Mike Henry Eric Dittert Intel Corp. December 8th, 1997 DHCP Options For Host System Characteristics Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Notice All product and company names mentioned herein might be trademarks of their respective owners. Abstract The interoperability of configuration services based on the Dynamic Host Configuration Protocol (DHCP) [1] in an environment of heterogeneous clients depends on clients accurately identifying themselves and their relevant characteristics to configuration servers. The class identifier provided through DHCP option 60 [2] helps in this regard, but such identifiers essentially only enable clients and servers that are ''good friends'' to find each other. This draft proposes the definition of two options that convey particular, generally useful information about the client system. This enables all servers to recognize this information, and is a step toward a richer form of interoperability for configuration services. Expires June 1998 [Page 1] December 8, 1997 The proposed options are * Client System Architecture * Client Network Device Interface * UUID/GUID-based Client Identifier 1.0 Introduction The use of DHCP to provide clients with configuration information in general, and boot images in particular can be complicated by several circumstances. Among these are 1) clients in the same service domain with different system architectures or hardware configurations 2) clients in the same service domain for which different software configurations are desired 3) the desire to have clients and servers provided by different vendors successfully interact (By "clients in the same service domain" we mean clients, requests from which can reach the same server.) A key element in enabling the successful use of DHCP in such circumstances is the provision of mechanisms by which clients can accurately identify themselves and their relevant characteristics to a server. For identifying characteristics of the client that are relevant to the selection of a boot image, the currently available mechanisms are the DHCP class identifier option (code 60) and the DHCP vendor specific information option (code 43). By definition, the vendor specific information option does not address the problem of enabling interoperability of clients and servers provided by different vendors. Information conveyed by the class identifier option could enable interoperability, provided that a sufficiently specific and complete set of class identifiers were defined and agreed to. We suggest using an alternate approach, in which new, specific options are used to convey the characteristics of the client that determine which boot image(s) could run on the client, and the class identifier is used as a (site-specific) designation of the desired software configuration for the client. Section 2 defines two new options that are useful for conveying the client's hardware configuration. For identifying the client as a unique entity, the currently available mechanism is the DHCP client identifier option (code 61) [2]. Section 3 of this draft defines an alternative option (code 97) identifier type based on generated GUIDs - identifiers that are guaranteed to be, or are very, very likely to be unique across time and all clients. Expires June 1998 [Page 2] December 8, 1997 2.0 Client Characteristics Options The options defined in this section provide the server with explicit knowledge about the client system that is generally useful in selecting an executable that the client can use as a boot image. 2.1 Client System Architecture Option DHCP clients SHOULD include this option in DHCPDISCOVER and DHCPREQUEST messages. Doing so provides the server with explicit knowledge of the client's system architecture. DHCP servers that use this option MAY include the option in responses that contain a bootfile name. If included, the value of the option MUST denote a system architecture for which the bootfile named is valid. DHCP servers MUST NOT include this option in responses that do not contain a bootfile name. The format for this option is as follows: Code Len System Arch Code +-----+-----+-----+-----+ | 93 | 2 | s1 | s2 | +-----+-----+-----+-----+ The currently defined types and their codes are System Architecture Code ------------------- ---- Intel Architecture PC 0 NEC PC-9800 1 DEC Alpha 2 2.2 Client Network Device Interface Option DHCP clients SHOULD include this option in DHCPDISCOVER and DHCPREQUEST messages. Doing so provides the server with explicit knowledge of the client's network device. DHCP servers that use this option MAY include the option in responses that contain a bootfile name. If included, the value of the option MUST denote a network device for which the bootfile named is valid. DHCP servers MUST NOT include this option in responses that do not contain a bootfile name. Expires June 1998 [Page 3] December 8, 1997 Three types of network device specifications are defined for use with this option: * devices that support the Universal Network Driver Interface (UNDI), as described in "Network PC System Design Guidelines: A Reference for Designing Net PC Systems for Use with the Microsoft Windows and Windows NT Operating Systems" [3] * Plug-and-Play devices [4] * PCI devices [5 Each devices that supports (UNDI) SHOULD be specified as an UNDI device, regardless of whether it is also a Plug-and-Play device or a PCI device. To specify an UNDI device, the option contains a type code of 1 and the major and minor UNDI version numbers: Code Len Type Major Minor +-----+-----+-----+-----+-----+ | 94 | 3 | 1 | m1 | m2 | +-----+-----+-----+-----+-----+ To specify a PCI network device, a type code of 2 is used, and the vendor ID, device ID, class code, and revision are included: Code Len Type Vendor ID Device ID Class code Rev +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 94 | 9 | 2 | v1 | v2 | d3 | d4 | c1 | c2 | c3 | r1 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ To specify a Plug-and-Play network device, a type code of 3 is used, and the EISA device ID and the class code are included: Code Len Type EISA device ID Class code +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 94 | 8 | 3 | e1 | e2 | e3 | e4 | c1 | c2 | c3 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ Expires June 1998 [Page 4] December 8, 1997 3.0 Unique Client Identifier This option (code 97) provides a unique client identifier. Type 0 of this identifier is defined to be in UUID/GUID format. A client identifier option containing a type code of 0 MUST contain a 128-bit GUID as follows: Code Len Type Client GUID +------+------+-----+------+------+------+ | 97 | 17 | 0 | g1 | g2 | ... | +------+------+-----+------+------+------+ The format of the GUID MUST be as specified in the design guidelines for Net PCs [3]. A client machine providing this option MUST use the same GUID value each time the option is used. That is, the GUID MUST be static. DHCP clients SHOULD include this option in DHCPDISCOVER and DHCPREQUEST messages. Doing so provides the server with a unique and static identifier for the client platform. 4.0 References [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131 [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor Extension" RFC 2132. [3] "Network PC System Design Guidelines: A Reference for Designing Net PC Systems for Use with the Microsoft Windows and Windows NT Operating Systems", http://www.intel.com/managedpc [4] Intel Corp. and Microsoft Corp., "Plug and Play ISA Specification", Version 1.0a, May 5, 1994 [5] Peripheral Component Interconnect Special Interest Group, "Peripheral Component Interconnect Specification", Revision 2.1, available through PCISIG, http://www.pcisig.com/specs.html Expires June 1998 [Page 5] December 8, 1997 5.0 Authors' Addresses Mike Henry Intel Corporation, MS JF3-408 5200 NE Elam Young Pkwy Hillsboro, OR 97124 Phone: (503) 264-9689 Email: Mike_Henry@ccm.jf.intel.com Eric Dittert Intel Corporation, MS JF3-206 5200 NE Elam Young Pkwy Hillsboro, OR 97124 Phone: (503) 264-8461 Email: Eric_Dittert@ccm.jf.intel.com Expires June 1998 [Page 6]