Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)
RFC 4578
|
| Document |
Type |
|
RFC - Informational
(November 2006; Errata)
|
|
Last updated |
|
2016-02-25
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4578 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Margaret Wasserman
|
|
Send notices to |
|
rdroms@cisco.com
|
Network Working Group M. Johnston
Request for Comments: 4578 Intel Corporation
Category: Informational S. Venaas, Ed.
UNINETT
November 2006
Dynamic Host Configuration Protocol (DHCP) Options for the
Intel Preboot eXecution Environment (PXE)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
We define Dynamic Host Configuration Protocol (DHCP) options being
used by Preboot eXecution Environment (PXE) and Extensible Firmware
Interface (EFI) clients to uniquely identify booting client machines
and their pre-OS runtime environment so that the DHCP and/or PXE boot
server can return the correct OS bootstrap image (or pre-boot
application) name and server to the client.
Table of Contents
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. Option Definitions ..............................................2
2.1. Client System Architecture Type Option Definition ..........2
2.2. Client Network Interface Identifier Option Definition ......3
2.3. Client Machine Identifier Option Definition ................4
2.4. Options Requested by PXE Clients ...........................4
3. Acknowledgements ................................................5
4. IANA Considerations .............................................5
5. Security Considerations .........................................5
6. Normative References ............................................5
Johnston & Venaas Informational [Page 1]
RFC 4578 DHCP PXE Options November 2006
1. Introduction
These DHCP [2] options are being widely used by PXE-compliant clients
to uniquely identify booting client machines themselves and their
pre-OS runtime environment so that the DHCP and/or PXE boot server
can return the correct OS bootstrap image (or pre-boot application)
name and server to the client. In the past, this work was done by
examining the network Media Access Code (MAC) address in the "chaddr"
field in the BOOTP/ DHCP header and keeping a database of MAC
addresses on the BOOTP/DHCP server. This was deemed insufficient for
large and complex networks for two main reasons. 1) Multiple laptops
could end up with the same MAC address if the network interface was
in a shared docking station. 2) Multiple network devices and MAC
addresses could be used by one machine for redundancy or because of
repairs. Another issue that came up was the machine that could
change its pre-OS runtime environment. This issue caused the
creation of another new option to identify the runtime environment so
that the correct binary image could be matched up with the booting
machine. These options are defined by Intel in the PXE [3] and EFI
[4] specifications and are being documented in this draft for
completeness within the IETF.
1.1. Requirements Language
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 RFC 2119 [1].
2. Option Definitions
There are three DHCP options [5] defined for use by PXE clients.
2.1. Client System Architecture Type Option Definition
The format of the option is:
Code Len 16-bit Type
+----+-----+-----+-----+
| 93 | n | n1 | n2 |
+----+-----+-----+-----+
Johnston & Venaas Informational [Page 2]
RFC 4578 DHCP PXE Options November 2006
Octet "n" gives the number of octets containing "architecture types"
(not including the code and len fields). It MUST be an even number
greater than zero. Clients that support more than one architecture
type MAY include a list of these types in their initial DHCP and PXE
boot server packets. The list of supported architecture types MAY be
reduced in any packet exchange between the client and server(s).
Show full document text