Advanced Topics on DHCP and related protocols
In this article we discuss the dynamic network configuration of booting stations. In either the case of a diskless device trying to load and run its OS from the net, a device trying to locally install its OS from the net, or just a device with not permanently assigned network parameters, there is always a need for the dynamic supply and administration of network parameters.
In an Ethernet world, a network card gets its unique Level 2 MAC address factory embedded on the card's firmware. We users rarely if ever have to change it or care about it. This address is the one that makes Ethernet traffic possible within an Ethernet (allow me to say) collision domain. But this Ethernet address is not going to get us very far by itself. Pure Level 2 Ethernet packets can eventually only get through bridges or switches when they serially or parallel expand their collision domain, but they are never going to get through a router. A router requires the presence of a nested Level 3 Network layer like IP. IP addresses cannot come factory embedded on network card's firmware because they have to be assigned according to their surrounding peers. At this point we can see a valid IP address is the net booting station most required parameter.
RARP:
Back in 1984, we find in the Internet Engineering Task Force (IETF) standard RFC-903 "A Reverse Address Resolution Protocol" the first method for workstations to dynamically get their IP protocol address, when they only know their hardware address. It is a Data-link layer protocol (Level 2) using packets similar in format to ARP packets.
RARP requires one or more host servers with a manually administered database of mappings of Link Layer addresses (MAC addresses) to their respective IP protocol addresses. The fact that RARP is a symmetrical Level 2 protocol makes the client side of the implementation very easy but the server side, on the other hand, it represents a coding challenge when most host OSs do not provide a native Level 2 Application Program Interface (API) due to security reasons.
BOOTP:
One year later the RARP's server side implementation difficulties plus the need of a RARP server on every IP subnet led to a new standard. In September 1985 RFC-951 "Bootstrap Protocol (BOOTP)" describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. BOOTP introduces by the first time the concept of "network booting" as an extension of "network configuration". BOOTP also introduced the innovation of a relay agent, which allowed the forwarding of BOOTP packets off the local network using standard IP routing, thus one central BOOTP server could serve hosts on many IP subnets.
DHCP:
In October 1993 the Dynamic Host Configuration Protocol (DHCP) was first defined in RFC-1531 as a natural extension to BOOTP. The reasons for extending BOOTP were that BOOTP required manual intervention to add configuration information for each client, and that BOOTP did not provide a mechanism for reclaiming previously granted IP addresses when they become unused.
The DHCP (also valid for BOOTP) is implemented as a classic stateless client-server protocol, where the basic transaction consists of a client request followed by a server answer. The protocol stateless feature adds simplicity to the protocol implementation by making every DHCP transaction independent from the previous ones. The different DHCP protocol dialogs are all based on a single DHCP packet format where an specific packet field mainly identifies them as DISCOVER, OFFER, REQUEST or ACKNOWLEGE packets.
A typical client DHCP boot sequence consist of a Level 2 MAC broadcast DHCPDISCOVER packet trying to get DHCP server's attention. The DHCP server/s receiving the discover packet will answer also a Level 2 MAC broadcast DHCPOFFER packet containing the offered IP and additional parameters. The client after pondering the different offers sends to the chosen DHCP server a Level 3 unicast (over UDP) DHCPREQUEST packet. This request packet tells the DHCP server the client has accepted the corresponding offered IP address and the rest of associated parameters. The DHCP server now sends back a Level 3 unicast (over UDP) DHCPACK packet. The rest of non-accepted offers (if any) are withdrawn and the not taken resources (IP addresses) are kept available at their respective servers for further DHCP requests.
The DHCP packet has a fix length header followed by a variable length section ready to hold different DHCP "options".
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | hops (1) |
+---------------+---------------+---------------+---------------+
| xid (4) |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
+-------------------------------+-------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| yiaddr (4) |
+---------------------------------------------------------------+
| siaddr (4) |
+---------------------------------------------------------------+
| giaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
+---------------------------------------------------------------+
| |
| sname (64) |
+---------------------------------------------------------------+
| |
| file (128) |
+---------------------------------------------------------------+
| |
| options (variable size) |
+---------------------------------------------------------------+
FIELD OCTETS DESCRIPTION
----- ------ -----------
op 1 Message op code / message type.
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type, see ARP section in "Assigned
Numbers" RFC; e.g., '1' = 10mb ethernet.
hlen 1 Hardware address length (e.g. '6' for 10mb
ethernet).
hops 1 Client sets to zero, optionally used by relay agents
when booting via a relay agent.
xid 4 Transaction ID, a random number chosen by the
client, used by the client and server to associate
messages and responses between a client and a
server.
secs 2 Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; only filled in if client is in
BOUND, RENEW or REBINDING state and can respond
to ARP requests.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK by server.
giaddr 4 Relay agent IP address, used in booting via a
relay agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name, null terminated string.
file 128 Boot file name, null terminated string; "generic"
name or null in DHCPDISCOVER, fully qualified
directory-path name in DHCPOFFER.
options var Optional parameters field. See the options
documents for a list of defined options.
Format of a DHCP message
As we can see Serva's DHCP configuration Tab pretty much resembles DHCP packet structure. GUI DHCP option numbers can be seen between parenthesis.
Different DHCP packets fields are populated as described next.
/DHCP Client messages (RFC-2131)--------------------------------------------------------------------\
Field DHCPDISCOVER DHCPREQUEST(67) DHCPDECLINE, DHCPREQUEST(67)
DHCPINFORM DHCPRELEASE
----- ------------ ----------- ----------- -----------
'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' selected by client 'xid' from server selected by
DHCPOFFER message client
'secs' 0 or seconds since 0 or seconds since 0
DHCP process started DHCP process started
'flags' Set 'BROADCAST' Set 'BROADCAST' 0
flag if client flag if client
requires broadcast requires broadcast
reply reply
'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE) client's
client's network address client's network network address
network address (BOUND/RENEW/REBIND) address
(DHCPINFORM) (DHCPRELEASE)
'yiaddr' 0 0 0
'siaddr' 0 0 0
'giaddr' 0 0 0
'chaddr' client's hardware client's hardware client's hardware
address address address
'sname' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'file' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'options' options options (unused)
Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
------ ------------ ----------- -----------
Requested IP address MAY MUST (in MUST
(DISCOVER) SELECTING or (DHCPDECLINE),
MUST NOT INIT-REBOOT) MUST NOT
(INFORM) MUST NOT (in (DHCPRELEASE)
BOUND or
RENEWING)
IP address lease time MAY MAY MUST NOT
(DISCOVER)
MUST NOT
(INFORM)
Use 'file'/'sname' fields MAY MAY MAY
DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
DHCPINFORM DHCPRELEASE
Client identifier MAY MAY MAY
Vendor class identifier MAY MAY MUST NOT
Server identifier MUST NOT MUST (after MUST
SELECTING)
MUST NOT (after
INIT-REBOOT,
BOUND, RENEWING
or REBINDING)
Parameter request list MAY MAY MUST NOT
Maximum message size MAY MAY MUST NOT
Message SHOULD NOT SHOULD NOT SHOULD
Site-specific MAY MAY MUST NOT
All others MAY MAY MUST NOT
\DHCP Client messages (RFC-2131)--------------------------------------------------------------------/
/DHCP Server messages (RFC-2131)--------------------------------------------------------------------\
Field DHCPOFFER DHCPACK DHCPNAK
----- --------- ------- -------
'op' BOOTREPLY BOOTREPLY BOOTREPLY
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' 'xid' from client 'xid' from client 'xid' from client
DHCPDISCOVER DHCPREQUEST DHCPREQUEST
message message message
'secs' 0 0 0
'ciaddr' 0 'ciaddr' from 0
DHCPREQUEST or 0
'yiaddr' IP address offered IP address 0
to client assigned to client
'siaddr' IP address of next IP address of next 0
bootstrap server bootstrap server
'flags' 'flags' from 'flags' from 'flags' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'sname' Server host name Server host name (unused)
or options or options
'file' Client boot file Client boot file (unused)
name or options name or options
'options' options options
Option DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- -------
Requested IP address MUST NOT MUST NOT MUST NOT
IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
MUST NOT (DHCPINFORM)
Use 'file'/'sname' fields MAY MAY MUST NOT
DHCP message type DHCPOFFER DHCPACK DHCPNAK
Parameter request list MUST NOT MUST NOT MUST NOT
Message SHOULD SHOULD SHOULD
Client identifier MUST NOT MUST NOT MAY
Vendor class identifier MAY MAY MAY
Server identifier MUST MUST MUST
Maximum message size MUST NOT MUST NOT MUST NOT
All others MAY MAY MUST NOT
\DHCP Server messages (RFC-2131)--------------------------------------------------------------------/
PXE:
BOOTP and DHCP completely support a client booting station; They both provide an IP address (yiaddr), a TFTP server IP address (siaddr), and the file name of the bootstrap loader (file). But they are unable to provide different booting information based on i.e. the client's architecture. For this reason a new preboot execution environment specification was created; PXE. It is basically based on classic DHCP and TFTP but adding some special DHCP options. These new options allow the booting station to identify itself as a PXE client communicating to the DHCP server client's characteristics (i.e. its architecture). There are also defined new DHCP options for specifying the TFTP server IP and the bootstrap loader file name.
Now clients that identify themselves as PXE clients could receive booting information on the old DHCP siaddr and file fields or also alternatively contained in the new DHCP options 66 and 67. Serva automatically returns booting information populating the fields siaddr and file but it can also additionally/alternatively return booting information on PXE DHCP options 66 and 67 if they are manually set. This feature adds a higher degree of flexibility when dealing with non 100% PXE compliant booting stations.
ProxyDHCP:
The PXE proxyDHCP server behaves much like a regular DHCP server by listening/answering to ordinary DHCPDISCOVER client traffic. However, unlike a regular DHCP server, the PXE proxyDHCP server does not provide/administer network IP addresses, and it only responds to clients that identify themselves as PXE clients. This strategy allows to add PXE capabilities to a network segment that already has a working DHCP server.
When the network works with a PXE DHCP server there will be only one sequence DHCPDISCOVER-DHCPOFFER-DHCPREQUEST-DHCPACK. When the network works with a regular DHCP Server plus a proxyDHCP there is one DHCPDISCOVER packet followed by 2 consecutive DHCPOFFER-DHCPREQUEST-DHCPACK sequences; one providing the assigned IP address from the DHCP server and the other one providing the TFTP IP address/bootstrap loader file name from the proxyDHCP server.
NOTE: In order to avoid a cluttered animation DHCP offers are shown as unicast packets when in fact they are Level 2 multicast packets.
BINL:
The Boot Information Negotiation Layer (BINL) service is a key component of Microsoft's RIS and WDS remote OS install strategies. It includes certain preparation/maintenance processes and a network protocol that could be somehow considered a Microsoft crafted DHCP extension.
The BINL network protocol handles a number of client initiated request/response transactions where booting clients ask for vital information to complete their remote OS install actions. i.e. BINL identifies and supplies the correct driver binary for the client PC's network card on the text phase of a RIS install scenario.
Final words
Using the data provided in this article you will have a good starting point for effectively use your DHCP/proxyDHCP server on your next net boot/install endeavor.
Comments or ideas on how to improve the information contained in this document please contact us here.
| Updated | 05/03/2016 |
| Originally published | 06/24/2012 |