DHCP Client Behavior

Many Transmission Control Protocol/Internet Protocol (TCP/IP) networks use Dynamic Host Configuration Protocol (DHCP) servers that are administratively set up to allocate TCP/IP configuration information to clients on the network.  DHCP is a TCP/IP standard that reduces the complexity and administrative overhead of managing network client IPv4 / IPv6 addresses and other configuration parameters.  We will restrict ourselves to IPv4 behavior in this discussion.  A properly configured DHCP infrastructure eliminates the configuration problems associated with manually configuring TCP/IP.


A DHCP infrastructure consists of the following elements:



  • DHCP servers – Computers that offer dynamic configuration of IPv4 addresses and related configuration parameters to DHCP clients.

  • DHCP clients – Network nodes that support the ability to communicate with a DHCP server to obtain a dynamically leased IPv4 address and related configuration parameters.

  • DHCP relay agents – Network nodes, typically routers, that listen for broadcast and unicast DHCP messages and relay them between DHCP servers and DHCP clients. Without DHCP relay agents, you would have to install a DHCP server on each subnet that contains DHCP clients.

When a Client, configured with the TCP/IP setting “Obtain an IP address automatically”, plugs into a network, it sends out a broadcast from UDP port 68 to UDP port 67 to “DISCOVER” a DHCP Server (or relay agent).  The DHCP Server then responds by sending out an “Offer” (through a relay agent if applicable).  Then the client sends out a “Request”, requesting an IP address which is finally “Acknowledged” by the server so that the client starts using the IP address.


The above process is well understood by Administrators.  However, in situations where a DHCP Server fails or is not available, client behavior needs to be understood for efficient use.  Then there are cases where a laptop user roams between his house (static IP) and office (DHCP) and does not want to keep changing the TCPIP properties every time.


First, let’s understand DHCP client behavior when DHCP server is not available.  To understand well, we will observe the etl trace taken on a DHCP client. Ref: http://technet.microsoft.com/en-us/library/cc731630.aspx – “netsh dhcp client trace enable”.  Etl tracing is saved as the following files: %windir%\system32\logfiles\WMI\dhcpcsvc.etl, dhcpcsvc6.etl and dhcpqec.etl.


Both Windows Vista and Windows XP send out DHCP packets in the following sequence:


DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:42.943 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:42.943 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:42.943 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 5 seconds
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:42.943 (TryReceive:dhcpmsg_c471)Select: waiting for: 5 seconds

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:47.304 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:47.304 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:47.304 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:47.304 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 7 seconds
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:47.304 (TryReceive:dhcpmsg_c471)Select: waiting for: 7 seconds

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:54.184 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:54.184 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:54.184 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:54.184 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 15 seconds
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:54.184 (TryReceive:dhcpmsg_c471)Select: waiting for: 15 seconds

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:09.815 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [1]0430.0910::10/14/2008-20:59:09.815 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [1]0430.0910::10/14/2008-20:59:09.815 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [1]0430.0910::10/14/2008-20:59:09.815 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 32 seconds
DEBUG_TRACE [1]0430.0910::10/14/2008-20:59:09.815 (TryReceive:dhcpmsg_c471)Select: waiting for: 32 seconds

EBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (ObtainInitialParameters:protocol_c2510)121(ERROR_SEM_TIMEOUT)
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (DhcpSetRcvAllMode:protocol_c3941)RcvAll: 0
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (ReObtainInitialParameters:protocol_c3111)Autoconfiguring….
DEBUG_TRACE [0]0430.0910::10/14/2008-20:59:41.243 (ReObtainInitialParameters:protocol_c3153)Ready to acquire autonet address. Notifying NLA…

DEBUG_LEASE [0]0430.0910::10/14/2008-20:59:41.244 (ReObtainInitialParameters:protocol_c3191)Sleeping for 275 seconds.


Thus, if we consider the first DISCOVER packet at 0 seconds, then 4 packets are sent out as:



  • 0th second – 1st packet with 5 sec timeout

  • 5th second – 2nd packet with 7 sec timeout

  • 12th sec: 3rd packet with 15 sec timeout

  • 27th sec: 4th packet with 32 sec timeout

The above 4 packets with a final timeout of about 1 minute may be considered as a “set” for the purpose of this discussion.


In Windows Vista: One such set is sent out every 5 minutes as can be seen above.  After one set, the DHCP client sleeps for 275 seconds or over 4.5 minutes.


In Windows XP: The first 2 sets are sent one after another, after which one set is sent once every 5 minutes (approximately).


A registry key to control this is: AutonetRetries which may be placed as a DWORD in:


HKLM\SYSTEM\CurrentControlSet\Services\Dhcp\Parameters


OR


HKLM\SYSTEM\CurrentControlSet\Services\tcpip\Parameters


AutonetRetries controls the: “DEBUG_LEASE [0]0430.0910::10/14/2008-20:59:41.244 (ReObtainInitialParameters:protocol_c3191)Sleeping for 275 seconds” time period


Thus if the registry is set to 30 (decimal) for example, then the sleep time is reduced to 30 seconds. This means that the set of 4 tries will be sent out every 30 seconds.


Also another interesting reference is:


KB 928233 –  Windows Vista cannot obtain an IP address from certain routers or from certain non-Microsoft DHCP servers


Another registry key suggested here is DhcpConnEnableBcastFlagToggle


Though the purpose of this registry is completely different, on closer inspection, this setting has a side effect in Windows Vista where it sends out 2 sets of DISCOVER packet sets like Windows XP, albeit one set with and the second set without the Broadcast flag.  Subsequent sets will be controlled by the AutonetRetries setting (300 seconds by default).


DHCP Automatic Client Configuration

When a Windows Server 2003 DHCP client is installed, it automatically attempts to locate a DHCP server and obtain a configuration from it.  If it cannot find a DHCP server, it configures its own IP address using either Automatic Private IP Addressing (APIPA) or an alternate configuration.


How APIPA works


  1. A client is configured to automatically obtain an IP address from the DHCP server.

  2. The client is however unable to contact the DHCP server for dynamic IP address assignment because the DHCP server is unavailable or otherwise unreachable.

  3. The client computer uses the APIPA feature to assign and configure its own private IP address. Using a gratuitous Address Resolution Protocol (ARP) reply, the DHCP client tests to determine whether the IP address it has chosen is already in use. If it is, the client selects another IP address, and if necessary, continues to do so. Once it has an address that is verifiably not in use, it configures the interface with this address.

  4. The IP address which the client assigns to itself is a private IP address in the address range of 169.254.0.0 to 169.254.255.255. This address range is reserved by Internet Assigned Numbers Authority (IANA).

  5. The client continues to check whether the DHCP server is available at 5 minute intervals.

  6. When the DHCP server is available again, the client that assigned itself an IP address through APIPA initiates the DHCP lease process to request and obtain an IP address from the DHCP server.

  7. When the DHCP server assigns an IP address to the client, the client replaces the APIPA address with the one it obtained from the DHCP server.

If the DHCP client obtained a lease from a DHCP server on a previous occasion, and the lease is still valid (not expired) at system startup, the client tries to renew its lease.  If, during the renewal attempt, the client fails to locate any DHCP server, it attempts to ping the default gateway listed in the lease, and proceeds in one of the following ways:



  • If the ping is successful, the DHCP client assumes that it is still located on the same network where it obtained its current lease, and continues to use the lease as long as the lease is still valid.  By default the client then attempts, in the background, to renew its lease when 50 percent of its assigned lease time has expired.

  • If the ping fails, the DHCP client assumes that it has been moved to a network where a DHCP server is not available.  The client then auto-configures its IP address by using the settings on the Alternate Configuration tab.  When the client is auto-configured, it attempts to locate a DHCP server and obtain a lease.

APIPA addresses are invalid on the Internet, and computers that are using APIPA addresses can only communicate with other computers using APIPA addresses on the same network segment.


The APIPA feature configures the client with the following:



  • IP address

  • Subnet mask

The APIPA feature cannot configure the client with any other TCP/IP configuration:



  • Default gateway

  • DNS server IP address

  • WINS server IP address

You have to use an alternate configuration to provide the above TCP/IP configuration information to a client when no DHCP server is available for the client.


So when does a machine decide to use APIPA or alternate configuration?  The behavior is different for Windows XP and Windows Vista. Ref: KB 931550 –  When a DHCP server is unavailable on a Windows Vista-based computer, Windows Vista uses an APIPA IP address much sooner than Windows XP does under the same circumstances.


Let’s look at the behavior in network traces:


Windows Vista:


0.000000    1    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0x7518FEED
2.989037 2 0.0.0.0 255.255.255.255 DHCP DHCP:Request, MsgType = DISCOVER, TransactionID = 0x7518FEED
6.774854 3 0.0.0.0 169.254.29.17 ARP ARP:Request, 0.0.0.0 asks for 169.254.29.17

The first column denotes time in seconds since start.  Thus you can see that Windows Vista configured itself with an APIPA soon after sending first 2 DHCP DISCOVER packets, which is in about 6 seconds.


Now let’s look at Windows XP:


0.000000    3    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0xB9FC38C7
3.000000 4 0.0.0.0 255.255.255.255 DHCP DHCP:Request, MsgType = DISCOVER, TransactionID = 0xB9FC38C7
11.000000 5 0.0.0.0 255.255.255.255 DHCP DHCP:Request, MsgType = DISCOVER, TransactionID = 0xB9FC38C7
27.000000 6 0.0.0.0 255.255.255.255 DHCP DHCP:Request, MsgType = DISCOVER, TransactionID = 0xB9FC38C7
58.000000 7 169.254.61.228 169.254.61.228 ARP ARP:Request, 169.254.61.228 asks for 169.254.61.228

XP waits for one minute to configure an APIPA. In case one uses Alternate Configuration instead of APIPA, the configuration behavior is the same.  It’s just that instead of APIPA, the machine will be configured with the address & parameters specified by the user.


 


0.000000    3    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0x0068B2A9
4.000000 4 0.0.0.0 255.255.255.255 DHCP DHCP:Request, MsgType = DISCOVER, TransactionID = 0x0068B2A9
13.000000 5 0.0.0.0 255.255.255.255 DHCP DHCP:Request, MsgType = DISCOVER, TransactionID = 0x0068B2A9
28.000000 6 0.0.0.0 255.255.255.255 DHCP DHCP:Request, MsgType = DISCOVER, TransactionID = 0x0068B2A9
60.000000 7 192.168.1.3 192.168.1.3 ARP ARP:Request, 192.168.1.3 asks for 192.168.1.3

In case a machine is configured with APIPA, the computer shows “Limited or no connectivity” balloon by default.  In case one is using APIPA deliberately in a small network, then the alert can be disabled.


Open Control Panel -> Network & Internet Connections -> Network Connections -> Right click the specific network interface and choose Properties -> uncheck “Notify me when this connection has limited or no connectivity”.


To disable APIPA, set the following registry key:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\adapter_name (for the specific adapter)


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters (for all adapters)


IPAutoconfigurationEnabled: REG_DWORD


0 – APIPA disabled


1 – default


Ref: KB 244268 – Routing Does Not Work When Multiple Adapters Use Automatic Private IP Addressing Simultaneously


Alternate Configuration Ref: KB 283676 – How to use the Alternate Configuration feature for multiple network connectivity in Windows XP


– Rajeev Narshana