DHCP Message Generation, Addressing, Transport and Retransmission
(Page 2 of 3)
Use of Broadcasts and Layer Two Message Delivery
Some DHCP message exchanges require a server to respond back to a client that has a valid and active IP address. An example is a DHCPACK sent in reply to a DHCPINFORM request. In this situation, the server can always send a reply unicast back to the client. Other message exchanges, however, present the same chicken and egg conundrum that we saw with BOOTP: if a client is using DHCP to obtain an IP address, we can't assume that IP address is available for us to use to send a reply.
In BOOTP, there were two specified solution to this situation: first, the server could send back its reply using broadcast addressing as well; second, the server could send back a reply directly to the host at layer two. Due to the performance problems associated with broadcasts, DHCP tries to make the latter method the default for server replies. It assumes that a client's TCP/IP software will be capable of accepting and processing an IP datagram delivered at layer two, even before the IP stack is initialized.
As the standard itself puts it, DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. RFC 1122 is a key standard describing the detailed implementation requirements of TCP/IP hosts. The DHCP standard, however, acknowledges the fact that not all devices may support this behavior. It allows a client to force servers to send back replies using broadcasts instead. This is done by the client setting the special Broadcast (B) flag to 1 in its request.
Since DHCP, like BOOTP, must use either layer two delivery or layer three broadcasts for server replies, it requires a separate well-known port number for servers to send to. Again, for compatibility with BOOTP, the same port number is used, 68. This port number is used whether a server reply is sent unicast or broadcast.
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.