Packets for DHCP Client Initialization

When a server receives a DHCPDISCOVER message from a client, the server chooses a network address for the requesting client. If no address is available, the server can choose to report the problem to the system administrator. If an address is available, the new address should be chosen as follows:

• The client's current address as recorded in the client's current binding, ELSE

• The clients previous address as recorded in the clients (now expired or released) binding, if that address is in the server's pool of available addresses and not already allocated, ELSE

• The address requested in the Requested IP Address' option, if that address is valid and not already allocated, ELSE

• A new address allocated from the server's pool of available addresses; the address is selected based on the subnet from which the message was received (if 'giaddr' is 0) or on the address of the relay agent that forwarded the message ('giaddr' when not 0).

Note that, in some network architectures (such as Internets with more than one IP subnet assigned to a physical network segment), it might be the case that the DHCP client should be assigned an address from a different subnet than the address recorded in 'giaddr'. Thus, DHCP does not require that the client be assigned an address from the subnet in 'giaddr'. A server is free to choose some other subnet, and it is beyond the scope of the DHCP specification to describe ways in which the assigned IP address might be chosen.

Although not required for correct operation of DHCP, the server should not reuse the selected network address before the client responds to the server's DHCPOFFER message. The server might choose to record the address as offered to the client.

The server must also choose an expiration time for the lease, as follows (see Tables A-14 and A-15 for field and option descriptions):

• IF the client has not requested a specific lease in the DHCPDISCOVER message and the client already has an assigned network address, the server returns the lease expiration time that was previously assigned to that address (note that the client must explicitly request a specific lease to extend the expiration time on a previously assigned address), ELSE

• IF the client has not requested a specific lease in the DHCPDISCOVER message and the client does not have an assigned network address, the server assigns a locally configured default lease time, ELSE

• IF the client has requested a specific lease in the DHCPDISCOVER message (regardless of whether the client has an assigned network address), the server might choose either to return the requested lease (if the lease is acceptable to local policy) or select another lease.

Table A-14. Fields Used by DHCP Servers
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 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
Table A-15. Options Used by DHCP Servers
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

After the network address and lease have been determined, the server constructs a DHCPOFFER message with the offered configuration parameters. It is important for all DHCP servers to return the same parameters (with the possible exception of a newly allocated network address) to ensure predictable client behavior regardless of which server the client selects. The configuration parameters MUST be selected by applying the following rules in the order given in the following list. The network administrator is responsible for configuring multiple DHCP servers to ensure uniform responses from those servers. The server MUST return to the client:

• The clients network address, as determined by the rules given earlier in this section.

• The expiration time for the client's lease, as determined by the rules given earlier in this section.

• Parameters requested by the client, according to the following rules:

- IF the server has been explicitly configured with a default value for the parameter, the server MUST include that value in an appropriate option in the 'option' field, ELSE.

- IF the server recognizes the parameter as a parameter defined in the Host Requirements Document, the server MUST include the default value for that parameter as given in the Host Requirements document in an appropriate option in the 'option' field, ELSE.

• The server MUST NOT return a value for that parameter.

The server MUST supply as many of the requested parameters as possible and MUST omit any parameters it cannot provide. The server MUST include each requested parameter only once unless explicitly allowed in the DHCP Options and BOOTP Vendor Extensions document.

• Any parameters from the existing binding that differ from the Host Requirements Document defaults.

• Any parameters specific to this client (as identified by the contents of 'chaddr' or client identifier' in the DHCPDISCOVER or DHCPREQUEST message), for example, as configured by the network administrator.

• Any parameters specific to this clients class (as identified by the contents of the 'vendor class identifier' option in the DHCPDISCOVER or DHCPREQUEST message), for example, as configured by the network administrator. The parameters MUST be identified by an exact match between the client's vendor class identifiers and the client's classes identified in the server.

• Parameters with non-default values on the client's subnet.

Table A-16 shows the packets that a TCP/IP station running DHCP sends when it boots. Although a DHCP client sends more packets when initializing, DHCP is still recommended. The benefits of dynamic configuration far outweigh the disadvantages of the extra traffic and extra broadcast packets. (The client and server use broadcast packets until the point that they believe each other's IP addresses.)

The approximate packet size is also shown. On top of the packet size, add data link layer overhead. Depending on the implementation of DHCP, the packets might be slightly different than shown here.

Continue reading here: Table A19 Maximum Collision Domains for 100BaseT

Was this article helpful?

0 0