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.

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.

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.

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)              |

  -----      ------       -----------

  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
  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
  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.

Fig 1: Serva's DHCP configuration Tab

Different DHCP packets fields are populated as described next.

/DHCP Client messages (RFC-2131)--------------------------------------------------------------------\

           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
IP address lease time      MAY           MAY              MUST NOT
                           MUST NOT
Use 'file'/'sname' fields  MAY           MAY              MAY
                           DHCPINFORM                     DHCPRELEASE
Client identifier          MAY           MAY              MAY
Vendor class identifier    MAY           MAY              MUST NOT
Server identifier          MUST NOT      MUST (after      MUST
                                         MUST NOT (after
                                         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
           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)--------------------------------------------------------------------/

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.

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.


Content on this page requires a newer version of Adobe Flash Player.

Get Adobe Flash player

Select an animation and press the Play button

NOTE: In order to avoid a cluttered animation DHCP offers are shown as unicast packets when in fact they are Level 2 multicast packets.

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