Internet Draft
INTERNET DRAFT                                                Mike Henry
                                                             Intel Corp.
                                                            Feb 22, 1999


               DHCP Options For Host System Characteristics
                    <draft-dittert-host-sys-char-03.txt>


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. 


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 three
   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.

   The options in question are
             Option 93 - Client System Architecture
             Option 94 - Client Network Device Interface
             Option 97 - UUID/GUID-based Client Identifier

   Subsequent to IANA issuing the above DHCP option numbers, the DHCP Working
   Group has determined that use of these options is not appropriate. As a
   result, it was agreed in the August 1998 IETF DHCP WG meeting that use of
   Options 93, 94, and 97 as described in this draft would be allowed until
   August of 2004 (six years), after which time the option numbers would be
   made available for new options.



Expires  Aug  22, 1999                                               [Page 1]
<draft-dittert-host-sys-char-03.txt>                           Feb 22, 1999


   In the interim, it is expected that systems using Options 93, 94, and 97
   will be redefined to use Options 60 and 61.  It is allowable that systems
   may use both methods during the 6 year interim period as a means of
   migrating to exclusive use of Options 60 and 61 for this functionality by
   the end of the interim period.

   The DHCP Working Group has agreed that this draft will be published as
   an Informational RFC to document the expected term of use for Options 93,
   94, and 97 as defined in this ID.


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  Aug  22, 1999                                               [Page 2]
<draft-dittert-host-sys-char-03.txt>                           Feb 22, 1999


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
       Intel Architecture 64 PC              2
       DEC Alpha                             3
       ARCx86                                4
       Intel Lean Client                     5


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  Aug  22, 1999                                               [Page 3]
<draft-dittert-host-sys-char-03.txt>                           Feb 22, 1999


   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 [5]
       * PCI devices [6]

   Each device that supports (UNDI) MUST 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  |
    +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+


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 
   UUID as follows:

     Code   Len    Type  Client UUID
    +------+------+-----+------+------+------+
    |  97  |  17  |  0  |  g1  |  g2  |  ... |
    +------+------+-----+------+------+------+


   The format and content of the UUID MUST be as specified in the RPC
   Specification from the Open Group [4].

Expires  Aug  22, 1999                                               [Page 4]
<draft-dittert-host-sys-char-03.txt>                           Feb 22, 1999


   A client machine providing this option MUST use the same UUID value
   each time the option is used. That is, the UUID MUST be static.

   DHCP clients SHOULD include this option in all DHCP 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]     CAE Specification
           DCE 1.1: Remote Procedure Call
           Document Number: C706
           Universal Unique Identifier Appendix
           Copyright (c) 1997 The Open Group 
           http://www.opengroup.org/onlinepubs/9629399/toc.htm

   [5]     Intel Corp. and Microsoft Corp., "Plug and Play ISA
           Specification", Version 1.0a, May 5, 1994

   [6]     Peripheral Component Interconnect Special Interest Group,
           "Peripheral Component Interconnect Specification", Revision
           2.1, available through PCISIG,
           http://www.pcisig.com/specs.html



5.0 Author's Address

               Mike Henry
               Intel Corporation, MS JF3-206
               5200 NE Elam Young Pkwy
               Hillsboro, OR  97124

               Phone: (503) 264-9689
               Email: mike.henry@intel.com






Expires  Aug  22, 1999                                               [Page 5]