[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
INTERNET DRAFT                                                Mike Henry
                                                            Eric Dittert
                                                             Intel Corp.
                                                           July 31, 1998


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


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 December 1998                                               [Page 1]


<draft-dittert-host-sys-char-02.txt>                          June 16, 1998


   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 December 1998                                               [Page 2]


<draft-dittert-host-sys-char-02.txt>                          June 16, 1998



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


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 December 1998                                               [Page 3]


<draft-dittert-host-sys-char-02.txt>                          June 16, 1998


   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 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  |
    +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
















Expires December 1998                                               [Page 4]


<draft-dittert-host-sys-char-02.txt>                          June 16, 1998



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 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]     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 December 1998                                               [Page 5]


<draft-dittert-host-sys-char-02.txt>                          June 16, 1998


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 December 1998                                               [Page 6]