One document matched: draft-dittert-host-sys-char-00.txt
INTERNET DRAFT Mike Henry
Eric Dittert
Intel Corp.
April 25, 1997
DHCP Options For Host System Characteristics
<draft-dittert-host-sys-char-00.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 September 1997 [Page 1]
<draft-dittert-host-sys-char-00.txt> April 25, 1997
The proposed options are
* Client System Architecture
* Client Network Device Interface
This draft also proposes a new type of client identifier based on
generated UUID/GUIDs to be used in conjunction with the DHCP client
identifier option (61).
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 mechanisms is the DHCP client identifier option (code 61)
[2]. Section 3 of this draft defines for use in this option an
identifier type based on generated GUIDs - identifiers that are
Expires September 1997 [Page 2]
<draft-dittert-host-sys-char-00.txt> April 25, 1997
guaranteed to be, or are very, very likely to be unique across time
and all clients.
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 SHOULD 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
+-----+-----+-----+-----+
| TBD | 2 | s1 | s2 |
+-----+-----+-----+-----+
The currently defined types and their codes are
System Architecture Code
------------------- ----
Intel Architecture PC 1
NEC PC-9800 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 SHOULD 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 September 1997 [Page 3]
<draft-dittert-host-sys-char-00.txt> April 25, 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
+-----+-----+-----+-----+-----+
| TBD | 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
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| TBD | 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
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| TBD | 8 | 3 | e1 | e2 | e3 | e4 | c1 | c2 | c3 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Expires September 1997 [Page 4]
<draft-dittert-host-sys-char-00.txt> April 25, 1997
3.0 UUID/GUID-based Client Identifiers
Whenever a client identifier option is included in a DHCP message, it
MAY contain an identifier in UUID/GUID format. A client identifier
option containing a type code of <TBD> MUST contain a 128-bit GUID as
follows:
Code Len Type Client GUID
+------+------+------+------+------+------+
| 61 | 17 | t1 | g1 | g2 | ... |
+------+------+------+------+------+------+
The format of the GUID MUST be as specified in the design guidelines
for Net PCs [3].
4.0 References
[1] Droms, R. "Dynamic Host Configuration Protocol", RFC 1531
[2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor
Extension" RFC 1533.
[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 September 1997 [Page 5]
<draft-dittert-host-sys-char-00.txt> April 25, 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 September 1997 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-24 10:29:50 |