Posted by arlene

Similar to BOOTP, DHCP uses a request/reply mechanism, and the packet format is almost the same for both to provide for backward compatibility. The layout of the packet used by DHCP looks very much like the layout of the BOOTP packet, with a few exceptions. The first 11 fields are the same. However, the last field, which is called the Vendor Extensions area in the BOOTP packet, is called the Options field in the DHCP packet. The format of the options is the same as it was for BOOTP. However, some of the options that are defined in RFC 2132 are specific only to DHCP. The options available for use with BOOTP clients are a subset of those available for use with DHCP clients. Although this field was limited to 64 bytes in the BOOTP packet, it now is a variable-length field that has a minimum of 312 bytes for DHCP options.

1. 

Additional Options Available for DHCP Servers

Following is a listing of the options that can be used for both types of clients. This list includes additional options defined in RFC 2132 that can be used, with DHCP servers and clients. The options listed here are not for use with BOOTP clients.

1. Requested IP Address (Opcode=50)—The client can use this field to request a specific IP address.
2. IP Address Lease Time (Opcode=51)—The client can use this field to request a particular lease time. The server can use this field to fill in the lease time it is willing to offer. The value used in this field is expressed in seconds.
3. Option Overload (Opcode=52)—This option enables the server to use the fields originally allocated in the DHCP packet for the server name and filename fields to store options. This can be done when there are a large number of options to convey to the client. A value of 1 flags the filename field as holding options. A value of 2 flags the server name field as holding options. A value of 3 indicates that both fields hold options.

• TFTP Server Name (Opcode=66)—This field is used to specify the TFTP server when Option Overloading has used the field previously reserved for this.

•  Bootfile Name (Opcode=67)—This field is used to identify the boot filename when Option Overloading has used the field previously reserved for this.

• Server Identifier (Opcode=54)—DHCP servers use this field so that clients can distinguish between multiple DHCP servers answering a request. Clients then will use this address when they need to send unicast messages to the server chosen from the offers received. DHCP clients also use this option when they accept an offer from a server. The value for Server Identifier is simply the IP address of the server.

• Parameter Request List (Opcode=55)—This option enables the client to request certain configuration values. A list of option codes follows this option.

• Message (Opcode=56)—The DHCP server uses this field to send an error message to the client, including it in the DHCPNAK message. The client can also use this field to specify a reason why it has declined to use certain parameters offered by the server. The client uses the DHCPDECLINE message type for this. Both of these message types are discussed shortly.

• Maximum DHCP Message Size (Opcode=57)—This value is the maximum length for a DHCP message that the client can accept. It is used in the DHCPDISCOVER or DHCPREQUEST messages, described later.

• Renewal (T1) Time Value (Opcode=58)—This value is the number of seconds that elapse before a client holding an IP address transitions to the renewing state, at which time it will try t to renew an existing IP address lease.

•  Rebinding (T2) Time Value (Opcode=59)—This value is the number of seconds that elapse before a client holding an IP address transitions to the rebinding state.

• Vendor Class Identifier (Opcode=60)—This parameter can be used by clients to identify the vendor type and configuration of the client. The DHCP server should respond to this option by using Option 43 to return to the client vendor-specific information. Servers that do not support this option should ignore it.

• Client Identifier (Opcode=61)—Clients can use this to specify a unique identifier. The server can use this value to search its database for addressing information for the client. The identifiers chosen by administrators should be unique on the subnet.

Remember that two option values don’t have a data component. These are option zero (Pad option) and option 255 (which marks the end of the options list).

Option Overloading

When the Options Overload option is used in addition to the variable-length option field that is typically used for options, two other fields can be used to store options. This can be useful when a client or server has a maximum size for the total DHCP packet that is not large enough to store all the options the client/server needs to negotiate.

The Options Overload option data field can be 1, 2, or 3. As explained earlier, a value of 1 means that the server name field (sname) contains options. A value of 2 means that the boot filename field (file) contains options. A value of 3 means that both fields contain options.

In this case, other options can be used to store the values that are normally placed into these fields, if necessary. The following must also be done:

• The actual options field must still be terminated with the 255 end option field. The Pad option (zero) can be used to pad the options field.
• An option cannot be split across the options field, the sname field, or the file field. Each option tag and its value must be contained in the same field in the packet.
• The order of precedence for interpreting options is to read them first from the options field, then the sname field, and then the file field (depending on whether the Options Overload field is set to 1, 2, or 3).
• Some options can be used more than once in a packet, and if so, are concatenated by the client.

Possibly related posts: (automatically generated)
The DHCP Packet Format and Additional Options

• How DHCP Interacts with Microsoft's Dynamic Domain Name Service (DNS)
• The DHCP Client/Server Exchange
• Providing Support for BOOTP Clients
• The BOOTP Request/Reply Mechanism
• Taking BOOTP One Step Further: DHCP
• Dynamic DNS
• User Groups in Windows 2000 and Server 2003
• Computer Configuration Issues continue...
• Web Technology & Ecommerce Online Solutions
• The DHCP Client/Server Exchange continue...