INTERNET DRAFT Vish Viswanathan Intel Corp. Feb 26, 1999 Intel PXE Remote Boot Protocol 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 This document defines the protocol that is used for remote booting of client systems in a Preboot eXecution Environment (PXE) as implemented in Intel's Universal Network Boot [1], which is part of Intel's Wired for Management initiative [2]. 1.0 Introduction PXE defines a wire protocol to standardize an environment for remote booting of Intel architecture systems. This protocol makes heavy use of the DHCP options fields to exchange configuration information, locate different services etc. 1.1 Terminology 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. Expires Aug 26, 1999 [Page 1] Feb 26, 1999 2. Protocol Details The PXE wire protocol is a combination of an extension of DHCP [3](through the use of several new DHCP option tags) and the definition of simple packet transactions that use the DHCP packet format and options to pass additional information between the client and the server. This added complexity is introduced by the requirement to operate without disturbing existing DHCP services. A client provides the following configuration specific details to the boot server during a remote boot session. * Client system's ID (16 byte UUID - Universally Unique ID) * Client system's architecture type (like X86PC, Alpha etc) * Type of boot server from which the client is requesting a response. 2.1 Steps taken during a client boot in PXE 2.1.1 Step 1 The client, wishing to remote boot an operating system image, broadcasts a DHCPDISCOVER packet as per the DHCP protocol. This packet is transmitted to acquire an IP address. The client also sends PXE protocol specific information along with this packet. The following PXE specific information is transmitted as DHCP options. * Client Machine Identifier - UUID (DHCP Option#61). * PXE Client Class Identifier (DHCP option #60 - "PXEClient:Arch:xxxxx:UNDI:yyyzzz") 2.1.2 Step 2 A DHCP server responds to the above DHCPDISCOVER packet by sending a DHCPOFFER packet that contains the IP Address allocated to the client. In a PXE remote boot, the DHCP server also sends a special tag (option 60, with the value set to the string "PXEClient") to identify that it is capable of configuring a PXE client. Expires Aug 26, 1999 [Page 2] Feb 26, 1999 2.1.3 Step 3 At this time, the PXE client may receive DHCPOFFER messages from several DHCP servers. However, the PXE client gives preference to servers whose replies contain the option tag 60 ("PXEClient"). When the PXE client receives such an offer, it implies that the PXE client has to engage in more transactions with the DHCP server after completion of the dynamic IP address acquisition. Once an IP address is acquired, the client contacts a special service (known as "PXE service") running on the DHCP server. "PXE service" is listening on the UDP port 4011 for such requests. The PXE client sends a DHCPREQUEST packet along with the following DHCP option tags (as specified in step 1). * Client machine identifier - UUID (DHCP Option#61). * PXE Client Class Identifier (DHCP option #60 - "PXEClient:Arch:xxxxx:UNDI:yyyzzz") 2.1.4 Step 4 "PXE service" (that is running on the DHCP server) receives the above DHCPREQUEST packet directed to port 4011. The response DHCP ACK packet for this request includes the following information that the client needs to access/locate the boot servers. * Information on how to locate boot servers. This option specifies whether the boot servers could be discovered by a broadcast DHCP packet, a multicast packet or by unicasting a packet to the IP address from a list. * The multicast discovery address that the client can use to locate the boot servers if the multicast discovery option is enabled through the previous option. * A menu prompt that the client displays to the user. Also, a timeout value in seconds is included in this option. The client has to display this menu for this timeout period before a default action is taken. * A list of menu items, which describe the types of boot servers available. The client typically displays this list to the user and lets the user select the boot server of their choice. * A list of boot server types and their IP addresses. This option is useful if a boot server cannot be located by broadcast or multicast discovery. In this case, the client is told the IP address(es) of the boot server type that it wants. The actual formats of all the option tags in this step are described in Appendix A. Expires Aug 26, 1999 [Page 3] Feb 26, 1999 2.1.5 Step 5 The client displays the menu prompt that it received from the previous step and lets the user pick a boot server type. Once the user makes a selection, the client tries to locate a boot server of that type. This is done by sending a DHCPREQUEST packet with the same information as in Step 1 along with the type of the boot server it is trying to discover. The discovery method by which this is done is determined by the option received through the previous step. That option could specify a multicast discovery, in which case, the client sends a multicast DHCP REQUEST packet to port 4011. If there is no response to the multicast discovery, then the client tries to broadcast the same request to the DHCP server port (port 67). If there is no response to this request as well, then the client tries to unicast the request to port 4011 using the list of IP addresses (one after another) obtained through step 4. The DHCPREQUEST packet that the client sends out contains the following information. * Client UUID (DHCP option #61) * PXE Client Class Identifier Tag (DHCP option #60) * PXE_BOOT_ITEM tag embedded in vendor specific information option (DHCP option #43) 2.1.6 Step 6 Boot servers receiving the above mentioned packet MUST respond if they have boot image files for the boot server type defined in the PXE_BOOT_ITEM tag and the client system architecture defined in the class identifier tag. If the above conditions are satisfied, the server responds with a DHCPACK packet containing the following information. * PXE Client Class Identifier (DHCP option #60 - "PXEClient") * Several MTFTP related options embedded in vendor specific information option #43. These are described more in detail in the internet draft "Multicast TFTP in the Intel PXE Remote Boot Environment" [work in progress] * PXE_BOOT_ITEM tag embedded in vendor specific information option (DHCP option #43) * Boot file name specified in the fixed DHCP header bootfile portion 2.1.7 Step 7 The client, on receiving the response mentioned above, contacts the (m)TFTP service on the boot server which sent the reply and downloads the boot file. If the Multicast TFTP option is chosen by the client, then the client follows the guidelines provided in the internet draft "Multicast TFTP in the Intel PXE Remote Boot Environment" Expires Aug 26, 1999 [Page 4] Feb 26, 1999 Appendix A. PXE Related DHCP Options Definitions A.1 PXE Class Identifier This option identifies PXE clients. This option also identifies the client system's architecture and the version of the Universal Network Driver Interface (UNDI) provided by the client. The code for this option is 60 and its length is 32 octets long. This option is of the form "PXEClient:Arch:xxxxx:UNDI:yyyzzz", where xxxxx = Client System Architecture (5 octets long, value 0 to 65535) yyy = UNDI Major Version Number (3 octets long, value 0 to 255) zzz = UNDI Minor Version Number (3 octets long, value 0 to 255) Code Len 32-octet String +-----+-----+-----+-----+-----+-----+-----+-----+ | 60 | 32 | PXEClient:Arch:xxxxx:UNDI:yyyzzz | +-----+-----+-----+-----+-----+-----+-----+-----+ A.2 PXE Client Machine Identifier (UUID) This option uniquely identifies a client machine. A 16-byte universally unique identifier (UUID) is used for this purpose [5]. A server can uniquely identify a client using this UUID and provide customized service. The code for this option is 61 and its length is 17, including the type identifier that appears before the UUID. PXE requires a type-identifier value of zero. Code Len Type 16-octet Identifier +-----+-----+-----+-----+-----+-----+-----+-----+ | 61 | 17 | 0 | o1 | o2 | . . . . | o16 | +-----+-----+-----+-----+-----+-----+-----+-----+ A.3 PXE Related DHCP options contained in DHCP Vendor specific information Option The DHCP vendor specific information option is used by clients and servers to exchange vendor specific information. The information is an opaque object of n octets. The Encapsulated vendor-specific options field MUST be encoded as a sequence of code/length/value fields of identical syntax to the DHCP options field. Code Len Vendor-specific information +-----+-----+-----+-----+--- | 43 | n | i1 | i2 | ... +-----+-----+-----+-----+--- Expires Aug 26, 1999 [Page 5] Feb 26, 1999 Within this vendor specific information, we have several code/length/value fields to specify the PXE related configuration information. A.3.1 PXE_DISCOVERY_CONTROL This option specifies the different methods by which a client can discover boot servers. The code for this option is 6 and its length is 1. Code Len PXE_DISCOVERY_CONTROL +-----+-----+-----+ | 6 | 1 | b1 | +-----+-----+-----+ The individual bits in this octet (bit 0 is the least significant bit) are defined as follows: Bit 0 - If set, broadcast discovery of servers is NOT allowed. Bit 1 - If set, multicast discovery of servers is NOT allowed. Bit 2 - If set, only use and/or accept replies from servers in the list defined by PXE_BOOT_SERVERS tag (defined in A.3.3) If this tag is not supplied, all bits are assumed to be 0. A.3.2 DISCOVERY_MCAST_ADDR This option specifies the multicast IP address that is used by the client to discover boot servers. The client sends DHCPREQUEST packets to this multicast address. The code for this option is 7 and its length is 4. Code Len DISCOVERY_MCAST_ADDR +-----+-----+-----+-----+-----+-----+ | 7 | 4 | m1 | m2 | m3 | m4 | +-----+-----+-----+-----+-----+-----+ A.3.3 PXE_BOOT_SERVERS This option specifies a list of boot server types and their IP addresses. The code for this option is 8 and its length is variable. It is basically a list containing multiple entries of the following 3 elements. * boot server type (2 octets long) * number of IP addresses (1 octet long) supporting the above type. * IP addresses of those servers ([4 * number of IP addresses] octets long). Expires Aug 26, 1999 [Page 6] Feb 26, 1999 Code Len type1 count 'n1' IP addresses +-----+-----+-----+-----+-----+-----..-----+-----..----+--- | 8 | v | t1 | t2 | n1 | IP addr 1 | IP addr 2 | . . +-----+-----+-----+-----+-----+-----..-----+-----..----+--- type2 count 'n2' IP addresses +-----+-----+-----+-----..-----+-----..----+--- | t1 | t2 | n2 | IP addr 1 | IP addr 2 | . . +-----+-----+-----+-----..-----+-----..----+--- A.3.4 PXE_BOOT_MENU This option specifies a string description for each boot server type specified in option #8 above. The client MUST display this list to the user on request to provide the user with descriptions of the boot server types. The code for this option is 9 and its length is variable. It is a list containing multiple entries of the following 3 elements. * boot server type (2 octets long) * length of the description string (1 octet long) * string describing the boot server type ('n' octets long). Code Len type1 str-len description +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 9 | v | t1 | t2 | n1 | n1 octets of description .. | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ type2 str-len description +-----+-----+-----+-----+-----+-----+-----+-----+ | t1 | t2 | n2 | n2 octets of description .. | +-----+-----+-----+-----+-----+-----+-----+-----+ A.3.5 PXE_MENU_PROMPT This option specifies the prompt message that the client can display to the user before proceeding with the remote boot. This option controls how the information obtained through the tag PXE_BOOT_MENU is presented to the user and the duration for which it is displayed on the screen. The code for this option is 10 and its length is variable. Code Len timeout Prompt String +-----+-----+-----+-----+-----+-----+-----+-----+ | 10 | v | t | prompt string .. +-----+-----+-----+-----+-----+-----+-----+-----+ Expires Aug 26, 1999 [Page 7] Feb 26, 1999 If the user presses the key , the prompt string and the menu obtained through tag #8 "PXE_BOOT_MENU" are displayed. The prompt is followed by the number of seconds remaining before the first item in the "PXE_BOOT_MENU" is automatically selected. If this option #10 is not returned, the menu will be displayed without prompt and timeout. Similarly, if the timeout is 255, the menu and the prompt will be displayed indefinitely till there is a user interaction. If the timeout is zero, the client automatically selects the first item in the menu. A.3.6 PXE_BOOT_ITEM This option specifies the boot server type that the client is discovering and also the "layer" number of the boot image that is requested. "Layer 0" always indicates the first bootfile for a particular boot server type. The code for this option is 71 and its length is 4. Code Len Boot Server Type Layer # +-----+-----+--------+--------+-----+-----+ | 71 | 4 | t1 | t2 | n1 | n2 | +-----+-----+--------+--------+-----+-----+ References: [1] Preboot Execution Environment (PXE) Specification Version 2.0 ftp://download.intel.com/ial/wfm/pxespec.pdf [2] Intel's Wired for Management Initiative, URL:http://developer.intel.com/ial/wfm/index.htm [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [4] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extension", RFC 2132, March 1997. [5] 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 Expires Aug 26, 1999 [Page 8] Feb 26, 1999 Author's Address Vish Viswanathan Intel Corporation, MS JF3-206 5200 NE Elam Young Pkwy Hillsboro, OR 97124 Phone: (503) 264-9693 Email: vish.viswanathan@intel.com Expires Aug 26, 1999 [Page 9]