Operation Manual

146
when its lease time expires. If the client wants to use the IP address continually, it should
unicast a DHCP-REQUEST message to the server to extend its lease.
After obtaining parameters via DHCP, a host should be able to exchange packets with any
other host in the networks.

The Format of DHCP Message
Figure 9-1 DHCP model gives the process of DHCP and Figure 9-3 describes each field in the
DHCP message. The numbers in parentheses indicate the size of each field in octets. The
names for the fields given in the figure will be used throughout this document to refer to the
fields in DHCP messages.
Figure 9-3 The Format of DHCP Message
1) op：Message type, ‘1’ = BOOT-REQUEST, ‘2’ = BOOT-REPLY.
2) htype：Hardware address type, '1' for ethernet.
3) hlen：Hardware address length, '6' for ethernet.
4) hops：Clients set this field to zero and broadcast the DHCP-REQUEST message, optionally
used by relay-agents when booting via a relay-agent.
5) xid：Transaction ID, a random number chosen by the client, used by the client and server to
associate messages.
6) secs：Filled in by client, seconds elapsed since client started trying to boot.
7) flags：A client that cannot receive unicast IP datagrams until its protocol software has been
configured with an IP address should set the first bit in the 'flags' field to 1 in any
DHCP-DISCOVER or DHCP-REQUEST message that client sends. A client that can receive
unicast IP datagrams before its protocol software has been configured should clear the
first bit to 0. A server or relay agent sending or relaying a DHCP message directly to a
DHCP client should examine the first bit in the 'flags' field. If this bit is set to 1, the DHCP
message should be sent as an IP broadcast and if the bit is cleared to 0, the message
should be sent as an IP unicast. The remaining bits of the flags field are reserved for future
use and must be set to zero by clients and ignored by servers and relay agents.