Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Network Configuration and Management Protocols (BOOTP, DHCP, SNMP and RMON)            9  Host Configuration and TCP/IP Host Configuration Protocols (BOOTP and DHCP)                 9  TCP/IP Dynamic Host Configuration Protocol (DHCP)                      9  DHCP Messaging, Message Types and Formats

DHCP Messaging, Message Types and Formats 1 2 3 DHCP Message Format

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.

DHCP Messaging, Message Types and Formats 1 2 3 DHCP Message Format