Hubbry Logo
Preboot Execution EnvironmentPreboot Execution EnvironmentMain
Open search
Preboot Execution Environment
Community hub
Preboot Execution Environment
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Preboot Execution Environment
Preboot Execution Environment
Preboot Execution Environment
View on Wikipedia
from Wikipedia
A high-level PXE overview

In computing, the Preboot eXecution Environment (PXE; often pronounced as /ˈpɪksiː/ pixie), often called PXE boot (pixie boot), is a specification describing a standardized client–server environment that boots a software assembly, retrieved from a network, on PXE-enabled clients. On the client side it requires only a PXE-capable network interface controller (NIC), and uses a small set of industry-standard network protocols such as Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP).

The concept behind the PXE originated in the early days of protocols like BOOTP/DHCP/TFTP, and as of 2015 it forms part of the Unified Extensible Firmware Interface (UEFI) standard. In modern data centers, PXE is the most frequent choice[1] for operating system booting, installation and deployment.

Overview

[edit]

Since the beginning of computer networks, there has been a persistent need for client systems which can boot appropriate software images, with appropriate configuration parameters, both retrieved at boot time from one or more network servers. This goal requires a client to use a set of pre-boot services, based on industry standard network protocols. Additionally, the Network Bootstrap Program (NBP) which is initially downloaded and run must be built using a client firmware layer (at the device to be bootstrapped via PXE) providing a hardware independent standardized way to interact with the surrounding network booting environment. In this case the availability and subjection to standards are a key factor required to guarantee the network boot process system interoperability.[citation needed]

One of the first attempts in this regard was bootstrap loading using TFTP standard RFC 906, published in 1984, which established the 1981 published Trivial File Transfer Protocol (TFTP) standard RFC 783 to be used as the standard file transfer protocol for bootstrap loading. It was followed shortly after by the Bootstrap Protocol standard RFC 951 (BOOTP), published in 1985, which allowed a diskless client machine to discover its own IP address, the address of a TFTP server, and the name of an NBP to be loaded into memory and executed. BOOTP implementation difficulties, among other reasons, eventually led to the development of the Dynamic Host Configuration Protocol standard RFC 2131 (DHCP) published in 1997. The pioneering TFTP/BOOTP/DHCP approach fell short, as at the time, it did not define the required standardized client side of the provisioning environment.

The Preboot Execution Environment (PXE) was introduced as part of the Wired for Management[2] framework by Intel and is described in the specification published by Intel and SystemSoft. PXE version 2.0 was released in December 1998, and the update 2.1 was made public in September 1999.[3] The PXE environment makes use of several standard client‑server protocols including DHCP and TFTP (now defined by the 1992 published RFC 1350). Within the PXE schema the client side of the provisioning equation is an integral part of the PXE standard and it is implemented either as a Network Interface Card (NIC) BIOS extension or current devices in UEFI code. This distinctive firmware layer makes available at the client the functions of a basic Universal Network Device Interface (UNDI), a minimalistic UDP/IP stack, a Preboot (DHCP) client module and a TFTP client module, together forming the PXE application programming interfaces (APIs) used by the NBP when needing to interact with the services offered by the server counterpart of the PXE environment. TFTP's low throughput, especially when used over high-latency links, has been initially mitigated by the TFTP Blocksize Option RFC 2348 published in May 1998, and later by the TFTP Windowsize Option RFC 7440 published in January 2015, allowing potentially larger payload deliveries and thus improving throughput.[citation needed]

Details

[edit]

The PXE environment relies on a combination of industry-standard Internet protocols, namely UDP/IP, DHCP and TFTP. These protocols have been selected because they are easily implemented in the client's NIC firmware, resulting in standardized small-footprint PXE ROMs. Standardization, small size of PXE firmware images and their low use of resources are some of the primary design goals, allowing the client side of the PXE standard to be identically implemented on a wide variety of systems, ranging from powerful client computers to resource-limited single-board computers (SBC) and system-on-a-chip (SoC) computers.

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-specific options identify the initiated DHCP transaction as a PXE transaction. Standard DHCP servers (non PXE enabled) will be able to answer with a regular DHCPOFFER carrying networking information (i.e. IP address) but not the PXE specific parameters. A PXE client will not be able to boot if it only receives an answer from a non PXE enabled DHCP server.

After parsing a PXE enabled DHCP server DHCPOFFER, 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 (i.e. UEFI Secure Boot), and finally boots from it. NBPs are just the first link in the boot chain process and they generally request via TFTP a small set of complementary files in order to get running a minimalistic OS executive (i.e. WindowsPE, or a basic Linux kernel+initrd). The small OS executive loads its own network drivers and TCP/IP stack. At this point, the remaining instructions required to boot or install a full OS are provided not over TFTP, but using a robust transfer protocol (such as HTTP, CIFS, or NFS).

Integration

[edit]
DHCP vs proxyDHCP Server

The PXE Client/Server environment was designed so it can be seamlessly integrated with an already in place DHCP and TFTP server infrastructure. This design goal presented a challenge when dealing with the classic DHCP protocol. Corporate DHCP servers are usually subject to strict policies that are designed to prevent easily adding the additional parameters and rules required to support a PXE environment. For this reason the PXE standard developed the concept of DHCP redirection or "proxyDHCP". The idea behind a proxyDHCP is to split the PXE DHCP requirements in two independently run and administered server units:

  1. The classic DHCP server providing IP address, IP mask, etc. to all booting DHCP clients.
  2. The proxyDHCP server providing TFTP server IP address and name of the NBP only to PXE identified booting clients.

In a DHCP plus proxyDHCP server environment[3]: 18  the PXE client initially broadcasts a single PXE DHCPDISCOVER packet and receives two complementary DHCPOFFERs; one from the regular non PXE enabled DHCP server and a second one from the proxyDHCP server. Both answers together provide the required information to allow the PXE client to continue with its booting process. This non-intrusive approach allows setting a PXE environment without touching the configuration of an already working DHCP server. The proxyDHCP service may also run on the same host as the standard DHCP service but even in this case they are both two independently run and administered applications. Since two services cannot use the same port 67/UDP on the same host, the proxyDHCP runs on port 4011/UDP. The proxyDHCP approach has proved to be extremely useful in a wide range of PXE scenarios going from corporate to home environments.

Availability

[edit]

PXE was conceived considering several system architectures. The version 2.1 of the specification defined architecture identifiers for six system types, including IA-64 and DEC Alpha. However, PXE v2.1 only completely covered IA-32. Despite this apparent lack of completeness Intel has recently decided to widely support PXE within the new UEFI specification extending the PXE functionality to all EFI/UEFI environments. Current Unified Extensible Firmware Interface Specification 2.4A, Section 21 Network Protocols — SNP, PXE, and BIS defines the protocols that provide access to network devices while executing in the UEFI boot services environment. These protocols include the Simple Network Protocol (SNP), the PXE Base Code Protocol (PXE), and the Boot Integrity Services Protocol (BIS).[4][5] Today in a PXE environment the client architecture detection is rarely based on the identifiers originally included with the PXE v2.1 specification. Instead, each computer that will be booting from the network should have set DHCP option 93 to indicate the client's architecture. This enables a PXE server to know (at boot time) the exact architecture of the client from the first network boot packet.[6]

With the advent of IPv6, DHCP has evolved into DHCPv6; the need for options supporting PXE within the new DHCP protocol has been addressed in 2010.[7]

The original PXE client firmware extension was designed as an Option ROM for the IA-32 BIOS, so a personal computer (PC) was originally made PXE-capable by installing a network interface controller (NIC) that provided a PXE Option ROM. Today the client PXE code is directly included within the NIC's own firmware or as part of the UEFI firmware on the motherboard.

Even when the original client PXE firmware has been written by Intel and always provided at no cost as a linkable IA32 object code format module included in their Product Development Kit (PDK), the open source world has produced over the years non-standard derivative projects like gPXE/iPXE offering their own ROMs. While Intel based ROMs have been implementing the client side of the PXE standard for more than 20 years some users were willing to trade extra features for stability and PXE standard conformance.[8][failed verification]

Acceptance

[edit]

PXE acceptance since v2.1 has been ubiquitous; today it is virtually impossible to find a network card without PXE firmware on it. The availability of inexpensive Gigabit Ethernet hardware (NICs, switches, routers, etc.) has made PXE the fastest method available for installing an operating system on a client when competing against the classic CD, DVD, and USB flash drive alternatives.

Over the years several major projects have included PXE support, including:

In regard to NBP development there are several projects implementing Boot Managers able to offer boot menu extended features, scripting capabilities, etc.:

All the above-mentioned projects, when they are able to boot/install more than one OS, work under a "Boot Manager - Boot Loader" paradigm. The initial NBP is a Boot Manager able to retrieve its own configuration and deploy a menu of booting options. The user selects a booting option and an OS dependent Boot Loader is downloaded and run in order to continue with the selected specific booting procedure.

Sibling environments

[edit]

Apple has come up with a very similar network boot approach under the umbrella of the Boot Server Discovery Protocol (BSDP) specification. BSDP v0.1 was initially published by Apple in August 1999[9] and its last v1.0.8 was published in September 2010.[10] Mac OS X Server included a system tool called NetBoot. A NetBoot client uses BSDP to dynamically acquire resources that enable it to boot a suitable operating system. BSDP is crafted on top of DHCP using vendor-specific information to provide the additional NetBoot functionality not present in standard DHCP. The protocol is implemented in client firmware. At boot time, the client obtains an IP address via DHCP then discovers boot servers using BSDP. Each BSDP server responds with boot information consisting of:

  • A list of bootable operating system images
  • The default operating system image
  • The client's currently selected operating system image (if defined)

The client chooses an operating system from the list and sends a message to the server indicating its selection. The selected boot server responds supplying the boot file and boot image, and any other information needed to download and execute the selected operating system.

Descendant environments

[edit]

Microsoft created a non-overlapping extension of the PXE environment with their Boot Information Negotiation Layer (BINL). BINL is implemented as a server service and it is a key component of their Remote Installation Services (RIS) and Windows Deployment Services (WDS) strategies. It includes certain preparation processes and a network protocol that could be somehow considered a Microsoft-crafted DHCP extension. BINL is a Microsoft proprietary technology that uses PXE standard client firmware. Currently there is not a publicly available BINL specification.

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Preboot Execution Environment

View on Grokipedia
from Grokipedia
The Preboot Execution Environment (PXE), pronounced "pixie," is an open industry standard that enables a client computer to boot an operating system or bootstrap program directly over a network connection using its network interface card (NIC), without relying on local storage media such as hard drives, floppy disks, or optical discs. Developed by in collaboration with as part of its Wired for Management (WfM) initiative, PXE provides pre-boot services within the device's , allowing for automated in enterprise environments, diskless workstations, and large-scale operating system deployments. PXE operates through a client-server architecture that integrates with standard network protocols, primarily the Dynamic Host Configuration Protocol (DHCP) for IP address assignment and the Trivial File Transfer Protocol (TFTP) for downloading boot files. The process begins when the client's PXE-enabled firmware broadcasts a DHCP discovery request upon startup; the DHCP server responds with an offer including the client's IP address, the boot server's address (via DHCP option 66), and the boot file name (via option 67), such as a network bootstrap program (NBP). The client then connects to a TFTP server to retrieve and execute the NBP in memory, which may load a full operating system image or further configuration tools, such as Windows PE for deployment tasks. Key components of PXE include the PXE client embedded in the NIC's firmware or the system's BIOS/UEFI, a DHCP server configured with PXE-specific options, a TFTP server for file transfer, and an optional boot server hosting the operating system images or provisioning tools. The specification, detailed in Intel's PXE Specification Version 2.1 released on September 20, 1999, defines APIs for firmware services, standardized initiation methods, and compatibility with Intel architecture systems, ensuring interoperability across vendors. While primarily used in x86-based PCs and servers, PXE has been extended for virtual machines, IoT devices, and high-performance computing clusters, though it requires hardware support and is not natively available on platforms like macOS, which use alternative protocols such as BSDP.

Introduction

Definition and Purpose

The Preboot Execution Environment (PXE) is a standardized client-server framework that enables computers to operating systems or software assemblies over a network interface without relying on local storage devices, leveraging protocols such as DHCP for address assignment and TFTP for file transfer. Developed as an industry standard by , PXE operates within the of network-enabled devices to facilitate remote loading of images from a server. PXE serves several primary purposes in modern environments, including diskless for thin clients that operate without onboard storage by loading entire runtime environments from a central server. It supports automated operating system deployment in enterprises, allowing IT administrators to push standardized images to multiple machines efficiently. Additionally, PXE enables remote installation in centers for bare-metal provisioning of servers and facilitates stateless computing, where systems into temporary, non-persistent configurations that reset upon reboot. Key benefits of PXE include reduced dependency on local hardware such as hard drives or optical media, which lowers costs and simplifies maintenance for diskless setups. It promotes centralized management of boot images and updates from a single server, ensuring consistency across deployments. Furthermore, PXE enhances scalability for large-scale environments, supporting rapid provisioning of hundreds or thousands of devices without individual physical interventions. Basic prerequisites for PXE functionality include a network interface card (NIC) with embedded PXE support and a compatible network infrastructure featuring and TFTP servers. Client devices must also have enabled in their or settings to initiate the process.

Historical Development

The Preboot Execution Environment (PXE) originated in the mid-1990s as part of 's Wired for Management (WfM) initiative, aimed at reducing for enterprise computing through enhanced remote manageability. This effort built upon foundational network protocols, including the (BOOTP) defined in RFC 951 (1985), which provided basic diskless booting capabilities, and the (DHCP) outlined in RFC 2131 (1997), which extended BOOTP with dynamic assignment and boot server discovery. WfM's baseline specification, released in 1998, incorporated PXE as a key component to enable standardized across Intel Architecture systems. The initial PXE specification, version 2.0, was released by Intel in December 1998, in collaboration with Systems Soft and other contributors, as an element of the broader Network Computing System Architecture for pre-OS environment management. This version established a client-server model using DHCP extensions and Trivial File Transfer Protocol (TFTP) for downloading boot images. An update to version 2.1 followed in September 1999, introducing multicast support via the Multicast Trivial File Transfer Protocol (MTFTP) to improve efficiency in mass deployments. A significant early adoption milestone occurred in 2000 with Microsoft's integration of PXE into Remote Installation Services (RIS) for Windows 2000 Server, facilitating automated OS installations over networks. PXE's evolution continued with formal extensions for modern networking. In 2010, RFC 5970 defined DHCPv6 options to support PXE-like network booting over IPv6, addressing the transition from IPv4. The specification was further integrated into the Unified Extensible Firmware Interface (UEFI) with version 2.5, released by the UEFI Forum in April 2015, which standardized PXE within UEFI's network boot architecture. Open-source enhancements emerged around 2007 with gPXE, a modular extension of the Etherboot project, providing advanced features like HTTP support; this evolved into iPXE in 2010 as a maintained fork for broader compatibility. By 2025, PXE maintained relevance in and environments for bare-metal provisioning, as seen in tools like System Center Virtual Machine Manager (VMM) 2025, which leverages PXE for host deployment. Recent updates, such as the NVM Express Boot Specification revision 1.2 ratified on March 11, 2025, enable over NVMe fabrics (NVMe-oF), supporting pre-OS environments like for enhanced performance in data centers and virtualized setups.

Technical Specifications

Protocol Stack and Components

The Preboot Execution Environment (PXE) relies on a layered built upon standard protocols to enable network-based without local storage. At the base, UDP over IP serves as the for all communications, ensuring lightweight, connectionless data exchange suitable for pre-OS environments. The (DHCP) operates on UDP ports 67 (server) and 68 (client) to assign IP addresses to the client and facilitate discovery of boot servers by providing essential configuration details in its option fields. (TFTP), using UDP port 69, handles the transfer of bootstrap files from the server to the client, leveraging its simplicity for small, read-only file operations in bandwidth-constrained scenarios. Core components of PXE include specific DHCP options that extend standard IP assignment to support functionality. DHCP Option 66 specifies the server host name, allowing the client to locate the TFTP server, while Option 67 identifies the file name to be downloaded. In environments with an existing DHCP infrastructure, ProxyDHCP operates on UDP port 4011 as a non-address-assigning extension, providing PXE-specific options without interfering with IP leasing. These options ensure compatibility with legacy networks while enabling targeted server information. PXE introduces vendor-specific extensions to DHCP for enhanced boot capabilities. The DHCP vendor class identifier (Option 60) is set to "PXEClient" (or variants like "PXEClient:Arch:xxxxx::yyyzzz") to signal PXE compliance and trigger appropriate server responses. Within DHCP Option 43, suboptions such as PXE_BOOT_SERVERS (suboption 8) list available boot servers by type and IP, while PXE_BOOT_MENU (suboption 9) provides a list of boot item descriptions for client selection, and PXE_MENU_PROMPT (suboption 10) defines the display prompt with a timeout for automated selection. These extensions allow dynamic menu presentation and server discovery tailored to the client's needs. The Network Bootstrap Program (NBP) serves as the initial executable downloaded via TFTP, loaded into memory at address 0:7C00h for x86 systems and executed to continue the boot process. NBPs are typically binary executables compatible with the PXE API, such as pxelinux.0 from the project for Linux-based booting or undionly.kpxe from the implementation for advanced scripting and chainloading support. This modular format allows flexibility in selecting operating system loaders or diagnostic tools. Architecture support in PXE is determined through DHCP Option 93, which conveys the client's system to the server for delivering architecture-appropriate files. For example, value 0x00 indicates (x86 PC), while 0x07 denotes EFI BC (x64 ), enabling servers to differentiate and provide compatible NBPs for or .

Boot Process Steps

The Preboot Execution Environment (PXE) boot process begins when the client device powers on and its —either or —initializes the network interface card (NIC) equipped with PXE support. The loads the PXE , which prompts the user or automatically enters PXE mode if configured as the primary device. In this mode, the client broadcasts a DHCP Discover packet on UDP port 67 to locate a () server, including PXE-specific vendor class identifiers to indicate its boot capabilities. Upon receiving the Discover packet, the DHCP server responds with a DHCP Offer packet containing the client's , subnet mask, gateway, and PXE extensions such as boot server host name (DHCP option 66) and boot file name (DHCP option 67), along with details of available boot servers. The client then unicasts a DHCP Request packet to accept the offer, and the server acknowledges with a DHCP Acknowledgment (ACK) packet, confirming the and providing the necessary boot information. This exchange ensures the client obtains both network configuration and directions to the boot server. With the boot server details acquired, the client initiates a connection to the boot server—typically on the same or a different host as the DHCP server—using the on UDP port 69 to download the Network Bootstrap Program (NBP), specified in the boot file name from the DHCP ACK. If a ProxyDHCP server is deployed to separate DHCP and boot services, the client performs an additional UDP discovery on port 4011 to retrieve boot menu options without interfering with standard DHCP operations. The NBP, often a small image, is transferred block by block and loaded into the client's base . Once downloaded, the firmware executes the NBP, which typically loads a minimal , such as a lightweight kernel or a preinstallation environment like (WinPE), into memory. This environment enables further network-based actions, including additional file downloads for operating system installation, diagnostics, or remote management. The NBP can leverage PXE APIs for continued network access or terminate the process, returning control to the . Throughout the process, error handling ensures reliability; for instance, if network communication fails—such as no DHCP response after retry timeouts (e.g., 4, 8, 16, and 32 seconds)—the client falls back to local boot devices like hard drives or optical media. TFTP downloads support variants via Multicast TFTP (MTFTP) when enabled (PXE option 9), allowing efficient simultaneous booting of multiple clients in large-scale deployments by reducing server load and bandwidth usage. In environments, the PXE process adapts using , where the client sends a Solicit message to discover servers, receives an Advertise message with boot information via dedicated options (e.g., Boot File URL option), and proceeds with Request and Reply exchanges for address assignment and NBP details, as defined in the IPv6 network boot extensions.

Implementation

Server-Side Setup

The server-side setup for Preboot Execution Environment (PXE) requires a combination of network services to facilitate client discovery, IP assignment, and file transfer during the boot process. Primarily, a (DHCP) server is essential to assign IP addresses to clients and provide boot information, such as the location of the boot server and the initial boot file name. A (TFTP) server is also mandatory to host and deliver small boot files, including network bootstrap programs (NBPs) like pxelinux.0 or boot.wim, due to TFTP's efficiency for initial lightweight transfers. In modern implementations, an HTTP or server can supplement TFTP for serving larger files, such as full operating system installers, to improve performance and security over high-bandwidth networks. Configuration begins with installing and setting up the DHCP server, such as on or DHCP on Windows, to include PXE-specific options. For instance, DHCP option 60 identifies the client as a PXE device (e.g., "PXEClient"), option 66 specifies the boot server host name or IP, and option 67 names the boot file (e.g., "pxelinux.0" for clients or "shim.efi" for ). A sample configuration in /etc/dhcp/dhcpd.conf might define a with next-server pointing to the TFTP server IP and filename set to the NBP, followed by enabling and starting the service (e.g., systemctl enable dhcpd). Next, install the TFTP server (e.g., tftp-server package on or Windows TFTP via ), configure its root directory (typically /var/lib/tftpboot), and populate it with boot files. This setup ensures clients receive directed broadcasts or responses during discovery. To avoid conflicts in environments with existing production DHCP servers, a ProxyDHCP service can be deployed separately, providing PXE boot information without handling IP assignments. ProxyDHCP listens on UDP port 4011 for PXE requests, responding with options like next-server and boot filename, while the primary DHCP manages addressing. Tools like can implement ProxyDHCP, configured with dhcp-range set to proxy mode and pxe-service tags for legacy or clients, allowing coexistence on the same network without modifications to the main DHCP. This integration supports multiple boot servers, enabling clients to select options via discovery. Boot image management involves hosting NBPs, operating system installers, and diagnostic tools on the TFTP (or HTTP) server, organized in a for accessibility. For example, Windows Imaging Format (WIM) files like boot.wim can be placed in a \Boot folder, with a Boot Configuration Data (BCD) store created using bcdedit.exe to define boot entries, then copied to TFTP. On , tools like pxelinux from the Syslinux project enable dynamic menus by configuring files in pxelinux.cfg/, where default or IP-based (hexadecimal) configs specify kernel (vmlinuz) and initrd images for various options, supporting multi-distro environments. Filenames must adhere to TFTP limits (≤63 characters), and tsize support ensures progress indicators during transfers. For scalability in large deployments, multiple boot servers can be load-balanced using network load-balancing technologies to distribute PXE requests and prevent overload. Integration with directory services like Active Directory allows authentication during boot, as seen in Windows Deployment Services (WDS), where the PXE server role is configured to require AD credentials for secure image deployment. This setup supports high-availability through redundant PXE components, ensuring reliable service across enterprise networks.

Client-Side Support

Client-side support for the Preboot Execution Environment (PXE) requires specific hardware, firmware, and software components on the target device to enable without local storage. The primary hardware prerequisite is a PXE-enabled (NIC) that integrates the Universal Network Driver Interface () specification, version 2.1 or later, to provide low-level network access during the preboot phase. Examples include Intel's PRO/1000 series NICs or equivalent, which support Ethernet connectivity at minimum speeds of 10/100 Mbps, though is recommended for modern deployments to handle larger bootstrap files efficiently. Firmware integration occurs through Option ROMs embedded in the device's or stack, which the system initializes during the (POST) to detect and activate PXE capabilities. In legacy systems, PXE operates as a Boot Entry Vector (BEV) Option ROM loaded into upper memory (typically C8000h–E0000h), comprising separate modules for the driver, Base Code, and optional to manage network I/O and boot initiation. firmware, widely adopted since the early 2010s, extends this support via protocols like EFI_PXE_BASE_CODE_PROTOCOL and EFI_SIMPLE_NETWORK_PROTOCOL, enabling PXE on 64-bit systems with optimized network stacks for faster boot times. Architecture compatibility is indicated via DHCP Option 93 in the client's discovery packet: type 0 for x86 PC, type 7 for EFI , and types 9 ( 32-bit) or 10 ( 64-bit) for -based systems under extended specifications. Once the Network Bootstrap Program (NBP) is downloaded and executed, a minimal client executive environment takes over, often resembling a DOS-like real-mode kernel or an embedded variant to load the operating . Tools like enhance this by providing an open-source replacement or chainloader that supports scripting for automated boot sequences and protocols beyond TFTP, such as HTTP for faster transfers, while maintaining compatibility with both and across x86 and architectures. PXE compatibility extends to bare-metal installations of major operating systems, including Windows via tools like Deployment Toolkit, Linux distributions through bootloaders such as GRUB or ELILO, and Unix variants like Solaris, all leveraging the NBP to initiate OS deployment without prior local installation. Virtual machine environments also support PXE booting; for instance, enables it for guest operating systems listed in its compatibility guide, allowing simulated network boots in virtualized setups. Client detection begins with a broadcast DHCPDISCOVER packet from the driver, including tags for PXE client identification (Option 60: "PXEClient"), system architecture (Option 93), and UNDI version (Option 94) to solicit server responses. Troubleshooting common issues involves verifying network configuration: tagging must be handled by the NIC firmware or switch to prevent broadcast drops across segments, and firewalls should not block UDP ports 67/68 (DHCP), 69 (TFTP), or 4011 (BINL service).

Standards and Evolution

Standardization History

The foundations of the Preboot Execution Environment (PXE) lie in earlier Internet protocols developed by the (IETF). The (BOOTP), defined in RFC 951 in August 1985, established a framework for diskless clients to request IP addresses and boot file locations from a server using UDP broadcasts. This was complemented by the (TFTP), standardized in RFC 1350 in July 1992, which provided a lightweight mechanism for transferring boot images over UDP without authentication or directory browsing. Building on BOOTP, the (DHCP) was formalized in RFC 2131 in March 1997, introducing dynamic IP leasing, vendor-specific options, and enhanced configuration capabilities essential for scalable network booting. PXE emerged from industry efforts led by , , and (DEC) under the Wired for Management (WfM) baseline specification, aimed at standardizing remote hardware . Intel released the initial PXE Specification Version 1.0 in December 1997 as an appendix to the WfM 2.0 document, defining a client-server protocol for using DHCP and TFTP. This evolved into Version 2.0 in December 1998 and Version 2.1 in September 1999, specifying UDP/IP-based discovery, boot server selection, and file loading for x86 platforms. These specifications influenced IETF work through the Dynamic Host Configuration , which addressed PXE integration with existing protocols. Key IETF standardizations followed to formalize PXE . RFC 2348, published in May 1998, extended TFTP with a blocksize option to optimize large file transfers during downloads. Vendor-specific DHCP options for PXE were codified in RFC 4578 in November 2006, defining codes 93 (client architecture), 94 (client network device interface), 97 (UUID), and others for IPv4 environments. For support, RFC 5970 in September 2010 introduced options like 59 (boot file URL) and 60 (vendor class) to enable in dual-stack networks. Open contributions transitioned PXE into broader firmware standards via the Extensible Firmware Interface (EFI) and its successor, the Unified Extensible Firmware Interface (UEFI), managed by the UEFI Forum. The PXE Base Code Protocol was integrated as a core EFI component by 2005, providing abstractions for DHCP, TFTP, and ARP in firmware. This was formalized further in the UEFI Specification version 2.5, released in April 2015, which incorporated PXE into the network protocols chapter alongside Simple Network Protocol (SNP) for consistent implementation across vendors. In the 2020s, PXE standards evolved for performance and compatibility, with RFC 7440 in January 2015 adding a TFTP windowsize option to allow batched block transmissions, reducing latency in PXE transfers; subsequent errata and implementations aligned it with secure boot requirements in environments.

Version Updates and Extensions

The Preboot Execution Environment (PXE) specification , released by in December 1998, established the core framework for by integrating (DHCP) for IP address assignment and boot server discovery with (TFTP) for downloading the network bootstrap program (NBP). This version introduced the Universal Network Driver Interface () model, which abstracts network interface card (NIC) hardware through a standardized , allowing protocol drivers to operate independently of specific NIC implementations and enabling broader hardware compatibility. Version 2.1, published in September 1999, built upon this foundation by incorporating TFTP support as defined in RFC 2090, which optimizes file transfers for multiple clients by reducing network overhead compared to methods. It also improved boot server discovery through enhanced DHCP options, including and broadcast mechanisms controlled by the PXE_DISCOVERY_CONTROL tag, facilitating more reliable detection in diverse network environments. To address IPv6 adoption, extensions emerged with RFC 5970 in September 2010, which specifies options for PXE booting, including boot file URLs and architecture types to enable network over without relying on IPv4 fallbacks. Complementary experimental efforts, such as HTTP-based protocols, have explored faster transfer mechanisms over by leveraging HTTP's efficiency over TFTP, though these remain implementation-specific and not fully standardized. Integration with the Unified Extensible Firmware Interface (UEFI) advanced in 2015 with version 2.5 of the UEFI specification, natively incorporating PXE as a UEFI protocol through the Simple Network Protocol and PXE Base Code Protocol, allowing seamless operation within the UEFI driver model without legacy BIOS dependencies. UEFI 2.6, released in 2017, further extended this by adding HTTP Boot support, which mitigates TFTP's limitations like small block sizes and unicast inefficiencies, enabling direct URI-based file downloads for improved performance in modern networks. As of 2025, PXE aligns with 2.11 (released December 2024) and later versions' Secure Boot requirements, mandating signed bootloaders and images to verify integrity during network boot sequences. The open-source implementation has introduced key enhancements, including a for dynamic boot configurations, chainloading capabilities to load subsequent images from HTTP or other protocols, and support for SAN booting via targets. Additionally, integration with NVMe over Fabrics (NVMe-oF) enables PXE-initiated boots from remote NVMe storage arrays over Ethernet transports like TCP or RDMA, providing low-latency access to networked persistent storage for high-performance environments.

Sibling Environments

The Preboot Execution Environment (PXE) shares conceptual similarities with several parallel technologies developed for diskless or remote booting in specific ecosystems, particularly during the late and . These sibling protocols addressed similar challenges in discovering boot servers and loading operating system images over IP networks but diverged in scope, standardization, and implementation details. Apple's Boot Server Discovery Protocol (BSDP), introduced as part of around 2005-2007 with refinements continuing into the , exemplifies a vendor-specific approach tailored for macOS NetBoot deployments. BSDP operates as a UDP-based extension to DHCP and BOOTP, enabling clients to discover available boot images after obtaining IP configuration via standard DHCP; it uses UDP ports 67 and 68 for server listening and client communication, akin to ProxyDHCP mechanisms in PXE but integrated directly into Apple's bootpd daemon. Unlike PXE's broader compatibility, BSDP supports image selection through broadcast discovery followed by optional announcements from servers, allowing clients to choose from multiple NetBoot images advertised on the network. Sun Microsystems' network booting protocol, prevalent in Solaris deployments from the 1980s through the pre-2000s era, relied on RARP for IP address resolution and BOOTP for additional boot parameters, forming an early foundation for remote booting in Unix-like environments. This approach used broadcast-based RARP requests to map MAC addresses to IPs, followed by BOOTP to retrieve server details and boot file locations, typically loading initial bootloaders via TFTP before mounting root filesystems over NFS. While RARP was standardized in IETF RFC 903, Sun's protocol emphasized proprietary optimizations for SPARC hardware, contributing to broadcast-heavy network traffic without the structured proxy options of later systems. In parallel, Open Firmware-based booting for SPARC systems provided a Forth-interpreted environment for network loading of operating systems, serving as a sibling technology in embedded and workstation Unix contexts since the late 1980s. Compliant with IEEE 1275 standards, initializes hardware and executes Forth scripts to perform network discovery using BOOTP or RARP, downloading bootloaders via TFTP and subsequently loading kernels over NFS for Solaris or similar OSes. This Forth-based firmware offered interactive control during boot, contrasting PXE's more automated, option-rom-driven process, but shared the reliance on legacy IP protocols for discovery in pre-DHCP eras. Comparatively, these protocols all leverage DHCP-like broadcast discovery for initial server location—mirroring PXE's own mechanisms—but differ markedly in interoperability and transfer methods. BSDP remains confined to the , limiting its use to macOS clients for NetBoot image selection and deployment, whereas PXE's cross-platform design supports diverse hardware from x86 to . in BSDP typically involves TFTP for initial files, followed by NFS (ports 111, 2049) or HTTP for disk images, enabling efficient shadow volumes in NetBoot scenarios; Sun's and approaches similarly prioritize NFS for root mounting post-TFTP, though without BSDP's multicast-enhanced selection. As of 2025, BSDP persists in legacy macOS deployment tools for compatible Intel-based systems, though Apple has deprecated NetBoot functionality in T2-equipped and Macs, rendering it inactive for modern hardware while its influence endures in protocol designs for vendor-specific booting. Sun's RARP/BOOTP integration and Open Firmware's network capabilities, now largely legacy following Oracle's shift away from , continue to inform Unix-derived embedded systems but have been supplanted by standardized alternatives like PXE in broader enterprise contexts.

Descendant and Integrated Environments

Microsoft's Boot Information Negotiation Layer (BINL) serves as a proprietary extension to the Preboot Execution Environment (PXE), enabling enhanced boot image selection and negotiation for Remote Installation Services (RIS), introduced in , and its successor, (WDS). BINL operates as a server-side service that integrates with PXE-compatible clients, allowing the use of RIS boot files while maintaining compatibility with standard PXE protocols for automated OS deployment in enterprise environments. This layer facilitates dynamic selection of boot images based on client hardware and policy, streamlining large-scale Windows installations without requiring local media. iPXE, an open-source firmware succeeding gPXE (initially released around 2007), builds directly on PXE by adding support for modern protocols such as HTTP, , , and advanced scripting capabilities. These enhancements allow iPXE to handle larger boot images more efficiently than traditional TFTP-based PXE, while its enables conditional chainloading of multiple boot options, such as selecting between local and network images dynamically. Widely adopted in open-source communities, iPXE maintains full backward compatibility with PXE 2.1 while extending functionality for complex deployment scenarios, including SAN booting via . UEFI HTTP Boot, introduced in the UEFI Specification version 2.7 in 2017, represents a direct evolution of PXE by replacing TFTP with HTTP or for transferring boot files, particularly beneficial for larger OS images that exceed TFTP limitations. This protocol leverages UEFI's network stack to enable faster, more reliable downloads over standard web infrastructure, and it has been integrated into environments for WDS deployments as well as various Linux distributions like . By supporting secure transport, UEFI HTTP Boot addresses PXE's scalability issues in modern networks, facilitating seamless integration with existing HTTP servers for enterprise provisioning. PXE has been integrated into virtualization platforms to enable network booting of virtual machines and hypervisors; for instance, VMware ESXi has supported PXE booting for installer deployment since its early versions around 2006, allowing stateless configurations where the hypervisor loads entirely from the network. Similarly, supports PXE network boot for guest VMs using legacy network adapters, enabling automated OS imaging within virtual environments without . In , PXE-compatible workflows support hybrid deployments; for example, Azure facilitates custom image provisioning through shared image galleries, incorporating PXE for on-premises bare-metal nodes in hybrid scenarios where they boot via network protocols before integrating with or other services. For container orchestration, often employs PXE for bare-metal node provisioning, as seen in setups like the WEDOS PXE bootable , where nodes boot over the network to join clusters dynamically using tools like Tinkerbell or MAAS. As of 2025, PXE extensions are emerging in , particularly for booting over high-speed and networks, enabling low-latency provisioning of distributed edge servers. , an open-source baseboard management controller project, incorporates PXE enhancements for server management, allowing remote updates and in edge appliances tailored for telco and IoT environments.

Adoption and Challenges

Usage and Acceptance

The Preboot Execution Environment (PXE) is primarily utilized for enterprise operating system deployment, such as through Microsoft Endpoint Configuration Manager (MECM, formerly SCCM) for imaging Windows systems over the network. It enables automated OS installations without , streamlining large-scale refreshes and new device setups in corporate environments. In data centers, PXE facilitates bare-metal provisioning, allowing servers to and install operating systems directly from network resources, which is essential for rapid scaling in and infrastructures. Additionally, PXE supports configurations in sectors like and healthcare, where diskless workstations from centralized servers to access virtual desktops and applications, reducing hardware dependencies. PXE has seen widespread adoption since the 2000s, particularly with the proliferation of infrastructure, becoming a standard for in server environments due to broad hardware support. By the early , the majority of server network interface cards (NICs) included PXE compatibility, reflecting its integration into enterprise-grade hardware from vendors like and . Major Linux distributions, including and (RHEL), incorporate PXE support natively for automated installations, while hypervisors like Red Hat Enterprise Virtualization leverage it for deploying hosts via network boot. In industry settings, PXE is a cornerstone of ITIL-compliant , enabling standardized processes for device provisioning in large organizations. Many companies employ PXE for zero-touch provisioning, automating server and endpoint deployments to minimize manual intervention and accelerate operations. Its integration with DevOps tools like Foreman and has further boosted acceptance, allowing orchestration of PXE-based workflows in automated pipelines for physical and virtual infrastructure. PXE supports bare-metal management in cloud infrastructures, including deployments. However, its prevalence in consumer applications has waned due to the ubiquity of solid-state drives (SSDs), which favor local over network dependency. Key success factors for PXE's enduring acceptance include significant cost savings by eliminating the need for physical installation media and enabling bulk deployments. It also supports efficient remote management, allowing administrators to boot, diagnose, and provision devices across global networks without on-site access. The technology's stems from its open specifications, ensuring compatibility across diverse hardware and software ecosystems from multiple vendors.

Security and Limitations

The Preboot Execution Environment (PXE) is susceptible to several key vulnerabilities that can compromise network boot integrity. Unauthenticated DHCP responses enable rogue boot servers to intercept client requests and redirect to malicious network bootstrap programs (NBPs), as the protocol relies on broadcast discovery without inherent authentication mechanisms. For instance, in 2024, exploits targeting System Center Configuration Manager (SCCM) PXE deployments, such as PXETHIEF, allowed attackers to download encrypted media variables containing certificates and crack weak passwords to access network access accounts, facilitating unauthorized image deployment. Additionally, the Trivial File Transfer Protocol (TFTP) used for transferring boot files lacks encryption, exposing them to man-in-the-middle attacks where malicious code can be injected into OS images. Broadcast-based discovery further exacerbates risks, as spoofed responses can corrupt the boot process or lead to denial-of-service by flooding distribution points with illegitimate requests. PXE's reliance on legacy protocols introduces notable limitations in performance and compatibility. The use of UDP-based TFTP for file transfers results in slow downloads for large boot images, as it lacks efficient error correction and is prone to packet loss over congested networks. Older PXE versions exhibit an IPv4 bias, with limited native IPv6 support requiring additional configuration or tools like iPXE, which can complicate deployments in dual-stack environments. Furthermore, PXE faces challenges in wireless and VLAN-segmented networks, where BIOS firmware often fails to activate wireless adapters early in the boot process, and broadcast traffic may not propagate reliably across subnets without proper relay agents. To mitigate these vulnerabilities, organizations can implement layered defenses. UEFI Secure Boot validates the digital signatures of NBPs, preventing execution of tampered loaders during the preboot phase. Network-level controls like and IP source guard on switches filter unauthorized DHCP responses, blocking rogue servers from responding to PXE requests. Enhanced tools such as support for encrypted transfers of boot files, reducing exposure compared to unencrypted TFTP, while network segmentation isolates PXE traffic to trusted VLANs, limiting lateral movement by potential attackers. Best practices for securing PXE emphasize proactive management and compliance. Regular updates for / ensure authenticated update mechanisms with digital signatures, aligning with NIST SP 800-147 guidelines for protecting through root-of-trust validation and non-bypassable controls. Monitoring tools should detect unauthorized PXE traffic, such as anomalous DHCP broadcasts, while requiring PXE passwords and restricting access to known devices only.

References

  1. https://www.techtarget.com/searchnetworking/definition/Preboot-Execution-Environment
  2. https://learn.microsoft.com/en-us/previous-versions/ms818762(v=msdn.10)
  3. https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/os-deployment/understand-pxe-boot
  4. https://www.novell.com/documentation/zenworks-24.4/zen_cm_preboot_imaging/data/bvb2dvw.html
  5. https://dimitrije.website/files/pxespec.pdf
  6. https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/application-policy-infrastructure-controller-apic/212041-Understanding-and-Troubleshooting-PXE-bo.html
  7. https://www.intel.com/content/www/us/en/support/articles/000099292/ethernet-products/800-series-network-adapters-up-to-200gbe.html
  8. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/managing_storage_devices/setting-up-a-remote-diskless-system_managing-storage-devices
  9. https://www.digitalocean.com/community/tutorials/bare-metal-provisioning-with-pxe-and-ipxe
  10. https://dl.dell.com/manuals/all-products/esuprt_software/esuprt_ent_sys_mgmt/openmanage-essentials-v25_white-papers103_en-us.pdf
  11. https://netboot.me/comparing-ipxe-and-pxe-which-network-booting-protocol-is-right-for-you/
  12. https://www.redhat.com/en/blog/exploring-pxe-booting-red-hat-openshift-agent-based-installer
  13. https://www.manageengine.com/products/os-deployer/benefits-of-pxe-boot.html
  14. https://kifarunix.com/set-up-pxe-boot-server-on-ubuntu-24-04-step-by-step/
  15. https://www.cendio.com/blog/pxe-linux-remote-desktop-thinlinc/
  16. https://nvmexpress.org/wp-content/uploads/NVM-Express-Boot-Specification-Revision-1.2-2025.03.11-Ratified.pdf
  17. https://datatracker.ietf.org/doc/html/rfc4578
  18. https://datatracker.ietf.org/doc/html/rfc5970
  19. https://learn.microsoft.com/en-us/windows/deployment/configure-a-pxe-server-to-load-windows-pe
  20. https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/advanced/Network_based_Installations/
  21. https://www.redhat.com/en/blog/pxe-boot-uefi
  22. https://docs.oracle.com/en/operating-systems/oracle-linux/6/install/ol-pxe-boot.html
  23. https://techdocs.broadcom.com/us/en/vmware-cis/nsx/vmware-nsx/4-1/installation-guide/installing-nsx-edge/manually-deploying-nsx-edge-node-outside-of-nsx/install-nsx-edge-on-bare-metal/prepare-a-pxe-server-for-bare-metal-nsx-edge-installation.html
  24. https://www.ibm.com/docs/en/aix/7.1.0?topic=protocol-preboot-execution-environment-proxy-dhcp-daemon
  25. https://ipxe.org/appnote/proxydhcp
  26. https://kernel.googlesource.com/pub/scm/boot/syslinux/syslinux/+/0d064db972a8bdff2e508a56f07e533348b84017/pxelinux.doc
  27. https://docs.bmc.com/xwiki/bin/view/Automation-DevSecOps/Server-Automation/TrueSight-Server-Automation/tssa244/Planning/Deployment-use-cases/High-availability-and-disaster-recovery/PXE-provisioning-infrastructure-high-availability-and-disaster-recovery/High-availability-for-the-PXE-provisioning-infrastructure/
  28. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj648426%28v=ws.11%29
  29. https://www.intel.com/content/dam/develop/external/us/en/documents/intel-uefi-pxe-boot-performance-analysis-820238.pdf
  30. https://ipxe.org/
  31. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/6-5/vsphere-virtual-machine-administration-guide-6-5/deploying-virtual-machines-vSphereVirtualMachineAdministration/create-a-virtual-machine-without-a-template-or-clone-h5-vSphereVirtualMachineAdministration/installing-a-guest-operating-system-vSphereVirtualMachineAdministration/using-pxe-with-virtual-machines-vSphereVirtualMachineAdministration.html
  32. https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/os-deployment/troubleshoot-pxe-boot-issues
  33. https://community.cisco.com/t5/switching/pxe-boot-requests-fail-across-vlan-s/td-p/2485239
  34. https://github.com/tianocore/tianocore.github.io/wiki/PXE
  35. https://datatracker.ietf.org/doc/html/rfc2348
  36. https://uefi.org/specs/UEFI/2.10/Apx_E_Universal_Network_Driver_Interfaces.html
  37. https://datatracker.ietf.org/doc/html/rfc7440
  38. https://uefi.org/specifications
  39. https://nvmexpress.org/wp-content/uploads/NVMe-oF-Network-Boot-Webinar-Deck_FINAL.pdf
  40. https://images.apple.com/server/docs/NetBoot_TB_v10.4.pdf
  41. https://static.afp548.com/mactips/bootpd.html
  42. https://www.macos.utah.edu/documentation/system_deployment/netboot/netboot_bits_and_pieces/terms/bsdp-boot_service_discovery_rotocol.html
  43. https://blog.apnic.net/2022/05/12/john-gilmore-on-arp-rarp-bootp-dhcp-and-sun/
  44. https://docs.oracle.com/cd/E19120-01/open.solaris/819-2379/hbsparcboot-79782/index.html
  45. https://datatracker.ietf.org/doc/html/rfc903
  46. https://www.devicetree.org/open-firmware/home.html
  47. https://knowledge.broadcom.com/external/article/184952/ports-and-protocols-for-symantec-it-mana.html
  48. https://cs.uwaterloo.ca/twiki/view/CF/NetBoot
  49. https://www.vercot.com/~serva/an/WindowsPXE1.html
  50. https://learn.microsoft.com/en-us/windows/win32/wds/about-the-windows-deployment-services-api
  51. https://ipxe.org/scripting
  52. https://ipxe.org/docs
  53. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf
  54. https://documentation.suse.com/sles/15-SP7/html/SLES-all/cha-deployment-prep-uefi-httpboot.html
  55. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/6-7/esxi-installation-and-setup-6-7/installing-and-setting-up-esxi-install/before-you-install-esxi-install/media-options-for-booting-the-esxi-installer-install/network-booting-the-esxi-installer-install.html
  56. https://petri.com/boot-hyper-v-virtual-machine-using-pxe/
  57. https://kubernetes.io/blog/2021/12/22/kubernetes-in-kubernetes-and-pxe-bootable-server-farm/
  58. https://www.iotforall.com/wi-fi-7-improvements-ai-iot
  59. https://www.lannerinc.com/news-and-events/eagle-lanner-tech-blog/why-open-bmc-for-network-appliances-is-the-future
  60. https://learn.microsoft.com/en-us/intune/configmgr/osd/deploy-use/use-pxe-to-deploy-windows-over-the-network
  61. https://docs.oracle.com/en/enterprise-manager/cloud-control/enterprise-manager-cloud-control/13.4/emlch/understanding-pxe-booting-and-kickstart-technology.html
  62. https://cs.uwaterloo.ca/~brecht/servers/docs/PowerEdge-2600/en/Broadcom/UG/pxe.htm
  63. https://linuxconfig.org/network-booting-with-linux-pxe
  64. https://centlinux.com/setup-linux-pxe-server/
  65. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/5/html/hypervisor_deployment_guide/sect-deployment_guide-preparing_red_hat_enterprise_virtualization_hypervisor_installation_media-deploying_rhev_hypervisors_with_pxe_and_tftp
  66. https://zpesystems.com/zero-touch-provisioning/
  67. https://docs.theforeman.org/3.0/Provisioning_Guide/index-foreman-deb.html
  68. https://heimdalsecurity.com/blog/what-is-pxe-boot/
  69. https://www.cablematters.com/Blog/Networking/pxe-boot-guide
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.