Booting your host from the network without the need to rely on the local operating system or hard disks is a technology that is not used very often in the corporate environment today with some people never having heard that such a thing is possible. With the way things are moving today with virtual machines, virtual storage, dynamic infrastructure, I feel that the trend would be reversed with few folks storing data on local hard drives and more moving to virtual environments and booting from remote storage at least as far as the backend infrastructure is concerned because of the advantages of flexibility, backup, deployment, etc.

Preboot eXecution Environment (PXE) or ‘pixie’ as it is popularly called is one of the many technologies that helps in booting hosts using a Network Interface with the help of images stored remotely. PXE consists of a suite of protocols like IP, UDP, DHCP, TFTP and concepts like Globally Unique Identifier (GUID) and Universal Network Device Interface (UNDI). The firmware of the PXE client is extended with the help of API’s. The PXE client refers to any hardware host device (server, notebook, PC) that is included with the PXE boot code.

PXE is an open industry standard developed by a number of software and hardware vendors. It was initially designed by Intel, with input from several other vendors including 3Com, HP, Dell, Compaq, and Phoenix Technologies. PXE works with a USB adapters and network interface card (NIC) in the PC, making the PC boot over the network.

Hosts that support booting from PXE, have a firmware that tries to locate a PXE redirection service (Proxy DHCP) to get a list of PXE boot servers that are available. After going through the reply, the firmware software will request an appropriate boot server for the file path of the network bootstrap program (NBP) like xxx and download it on the local Random Access Memory (RAM) using TFTP generally, verify and execute it.

If a common NBP is used by all PXE clients it could be specified by BOOTP thereby not needing a proxy DHCP, but the TFTP server is still required.

PXE Protocol

The PXE protocol is a combination of modified versions of DHCP and TFTP. DHCP is used to locate the appropriate boot servers and TFTP is used to download the bootstrap program and other files to the PXE client. Initiation of a PXE bootstrap session is done by the PXE firmware broadcasting a DHCPDISCOVER packet with PXE options (extended DHCPDISCOVER) to port 67 UDP (DHCP Server port). The PXE options identify the firmware of the sending host as capable of PXE, but this message is ignored by standard DHCP servers. If the PXE client receives DHCPOFFERS from such servers, it may request for one of the offered configurations.

PROXY DHCP

When a PXE redirection service (Proxy DHCP) receives an extended DHCPDISCOVER, it replies by sending back a broadcast called an extended DHCPOFFER (DHCPOFFER with extended PXE options) to port 68/UDP (DHCP client port). The reason this packet is broadcasts back because the IP address of the PXE client is not included in DHCPDISCOVER message. The client is mainly identified by its GUID/UUID

Extended DHCPOFFER contains mainly:

 - PXE Discovery Control field to decide whether Multicasting, Broadcasting, or Unicasting is to be used for contacting PXE boot servers
- List of IP addresses of each available PXE Boot Server Type
- PXE Boot Menu with each entry representing a PXE Boot Server Type
- PXE Boot Prompt telling the user to press <F8> to see the boot menu
- Timeout to launch the first boot menu entry if it expires.

The Proxy DHCP service may also be run on the same host as the standard DHCP service. Since both services cannot share port 67/UDP, the Proxy DHCP runs on port 4011/UDP and expects the extended DHCPDISCOVER packets from PXE Clients to be DHCPREQUESTs. 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 Proxy DHCP on the same host, port 4011/UDP.

Boot Server

To contact any PXE Boot Server the firmware must have an IP address and has to consider all information from exactly one extended DHCPOFFER. After choosing an appropriate PXE Boot Server Type the firmware 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 mainly contains the PXE Boot Server Type and the PXE Boot Layer, allowing to run many boot server types with one boot server daemon (or ‘program’). The extended DHCPREQUEST may also be a DHCPINFORM.

If a PXE Boot Server receives an extended DHCPREQUEST as described above and if the boot server is configured for the requested PXE Boot Server Type and client architecture, it must respond by sending back an extended DHCPACK to the source port of the extended DHCPREQUEST.

Extended DHCPACK contains mainly:
- The complete file path to download the NBP via TFTP.
- PXE Boot Server Type and PXE Boot Layer the boot server answered to
- Multicast TFTP configuration, if MTFTP as described in the PXE specification should be used

Additionally the PXE firmware extension was designed as an Option ROM for the IA-32 BIOS so you can get a personal computer (PC) PXE-capable by installing a NIC that provides a PXE Option ROM as can be seen in the figure below

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