Preboot Execution Environment

From Wikipedia, the free encyclopedia
Jump to: navigation, search
For a high-level overview of network booting, see Network booting.

The Preboot eXecution Environment (PXE, also known as Pre-Execution Environment; sometimes pronounced "pixie") is an environment to boot computers using a network interface independently of data storage devices (like hard disks) or installed operating systems.


Since the beginning of computer networks, there is a persistent need for client systems able to boot appropriate software images, using appropriate configuration parameters, both retrieved from one or more network servers. This goal requires of a client using a set of pre-boot services, based on industry standard network protocols. Additionally, the initially downloaded and run Network Bootstrap Program (NBP) must be built relying on a hardware independent firmware layer providing a standardized way to interact with the surrounding network booting environment.

One of the first attempts in this regard has been the standard Bootstrap protocol (BOOTP) which allows a disk-less client machine to discover its own IP address, the address of a server host, and the name of an NBP to be loaded into memory and executed. This approach felt short because at the time it was not defined the required standardized client side of the provisioning equation. Difficulties on BOOTP implementation among other reasons eventually led to the development of the current Dynamic Host Configuration Protocol standard (DHCP).

Finally the Preboot Execution Environment (PXE) was introduced as part of the Wired for Management framework by Intel and is described in the specification published by Intel and SystemSoft. PXE version 2.0 was released on December 28 1998, and almost a year later, the update 2.1 was made public on September 20 1999.[1] The PXE environment makes use of several standard network protocols like DHCP and Trivial File Transfer Protocol (TFTP). It also uses concepts like globally unique identifier (GUID) and universally unique identifier (UUID). The client (the device to be bootstrapped via PXE) side of the PXE equation is now part of the standard and it is implemented either as a Network Interface Card (NIC) BIOS extension or today in modern devices as UEFI code. This client firmware component includes a basic network card driver, a minimalistic IP stack, and the PXE standardized application programming interface (API) used by the NBP code when interacting with the PXE environment.

Environment details[edit]

As previously said the PXE environment relies on a combination of industry-standard Internet protocols, namely TCP/IP, DHCP, and TFTP. DHCP is used to provide the appropriate client network parameters and specifically the location (IP address) of the TFTP server hosting, ready for download, the initial bootstrap program (NBP) and complementary files.

To initiate a PXE bootstrap session the DHCP component of the client's PXE firmware broadcasts a DHCPDISCOVER packet containing PXE-specific options to port 67/UDP (DHCP server port); it asks for the required network configuration and network booting parameters. The PXE options identify the request as a PXE transaction. Standard DHCP servers (non PXE enabled) will be able to answer regular networking information (i.e. IP address) but no the PXE specific parameters. A PXE client will not be able to boot if only receives answers from non PXE enabled DHCP servers.

After parsing a PXE enabled DHCP server answer, the client will be able to set its own network IP address, IP Mask, etc, and to point to the network located booting resources, based on the received TFTP Server IP address and the name of the NBP. The Client next transfers the NBP into its own random-access memory (RAM) using TFTP, possibly verifies it, and finally boots from it. NBPs are just the first link in the boot chain process and they generally request via TFTP complementary files in order to get running a minimalistic OS executive (i.e. WindowsPE, or a basic Linux kernel+initrd). When the small OS executive is alive it loads its own fully capable network drivers and the rest of transfers for booting or installing a full OS are performed not by TFTP but at this point using more powerful protocols like HTTP, CIFS, NFS, etc.


If a PXE redirection service (ProxyDHCP) receives a PXE DHCPDISCOVER, it replies with a proxyDHCP DHCPOFFER to the client's port 68/UDP (DHCP client port). A proxyDHCP offer does not provide IP information. This particular characteristic allows us to split in two the PXE DHCP needs; a regular DHCP server providing only network configuration parameters while a proxyDHCP provides only the PXE specific information. The client in this situation continues the negotiation process independently with each server until it gathers all the required booting parameters. A proxyDHCP remains silent when receiving a non PXE DHCPDISCOVER inquire.

A proxyDHCP DHCPOFFER contains mainly:

  • a PXE Discovery Control field to recommend multicasting, broadcasting, or unicasting to contact PXE boot servers
  • a list of IP addresses of each available PXE Boot Server Type
  • a PXE Boot Menu with each entry representing a PXE Boot Server Type
  • a PXE Boot Prompt telling the user to press a certain key to see the boot menu
  • a timeout to launch the first boot menu entry if it expires

The proxyDHCP service may also run on the same host as the standard DHCP service. Since two services cannot use the same port 67/UDP, the proxyDHCP runs on port 4011/UDP and expects the DHCPDISCOVER packets from PXE Clients to be DHCPREQUESTs.[1]:18 The standard DHCP service has to send a special combination of PXE options in its DHCPOFFER, so the PXE client knows to look for a proxyDHCP on the same host, port 4011/UDP.

Today modern PXE implementations (2014) do not count on PXE embedded Boot Menu capabilities; instead they implement the Boot Manager/Boot Loader strategy. A Boot Manager is an NBP able to retrieve by TFTP a configuration file containing its menu information and displays it on the booting client screen. When the user selects a boot option the Boot Manager chain loads (TFTP transfer an run) the corresponding Boot Loader with its required parameters. A Boot Loader is an OS dependent piece of code able to continue with the boot/install process.

Boot server contact[edit]

To contact a PXE Boot Server the booting system must have an IP address (perhaps from a DHCP server).

It multicasts or unicasts a DHCPREQUEST packet extended with PXE-specific options (extended DHCPREQUEST) to port 4011/UDP or broadcasts it to port 67/UDP. This packet contains the PXE Boot Server type and the PXE Boot Layer, allowing multiple boot server types to run from one daemon. The extended DHCPREQUEST may be a DHCPINFORM.[1]:16

A PXE Boot Server receiving an extended DHCPREQUEST configured for the requested type and client architecture responds with an extended DHCPACK including:

  • the complete file path to download the NBP via TFTP.
  • PXE Boot Server type and PXE Boot Layer it answered
  • the multicast TFTP configuration, if MTFTP as described in the PXE specification should be used.

The booting system accepts information from only one extended DHCPOFFER.

A 2.1 version PXE Boot Server supports "Boot Integrity Services"[2] allowing the Client to verify downloaded NBPs using a checksum file which is downloaded from the same boot server as the NBP.

To get the file path of this credentials file another exchange of extended DHCPREQUEST and extended DHCPACK is required.

Network bootstrap program[edit]

After receiving the requested extended DHCPACK, the Network Bootstrap Program is uploaded into RAM and after it is verified or if verification is not required, the NBP will be executed. It has access to the APIs of the PXE firmware extension (Pre-boot, UDP, TFTP, Universal Network Device Interface (UNDI)). Its functions or tasks are not described in the PXE specification.


The PXE Client/Server Protocol was designed so:

  • it can be used in the same network as an existing DHCP environment without interference
  • it can be integrated completely into standard DHCP services
  • it can be easily extended at the most important points without a call for papers
  • every service (DHCP, Proxy DHCP, Boot Server) can be implemented standalone or in any combination of them.

The design goal of utilizing existing DHCP and TFTP servers cannot be achieved in a strictly conforming implementation. Some aspects of the PXE protocol require that the DHCP and TFTP servers be modified and communicate. One specific example is using multicast, where DHCP packets provide the multicast group information rather than an opening RFC-2090 multicast TFTP exchange. The impact of this is minimal as the most common PXE client implementation (written by Intel and provided at no cost as a linkable IA32 binary module) interoperates with a combination of isolated DHCP and unicast TFTP servers.


PXE was designed considering several system architectures. The 2.1 version of the specification assigns architecture identifiers to six system types, including IA-64 and DEC Alpha. However, PXE v 2.1 only completely covers IA-32. Intel included PXE in the EFI for IA-64, creating a de facto standard with the implementation today extended to all EFI/UEFI environments.

Additionally, the PXE firmware extension was designed as an Option ROM for the IA-32 BIOS, so a personal computer (PC) can be made PXE-capable by installing a network interface controller (NIC) that provides a PXE Option ROM. This procedure also applies to the newer AMD64 processor standard for PC.

Even when the PXE firmware has been freely provided by Intel the open source world has produced non-standard derivatives projects like PXELINUX, gPXE and iPXE. While Intel ROMs are rock solid implementing the PXE standard some people are willing to trade more features for stability and PXE standard conformance.

See also[edit]


  1. ^ a b c "Preboot Execution Environment (PXE) Specification - Version 2.1" (PDF). Intel Corporation. 1999-09-20. Retrieved 2014-02-08. 
  2. ^ "Boot Integrity Services Application Programming Interface" (PDF). Retrieved 2009-02-18. 

External links[edit]