This article has been archived. It is offered "as is" and will no longer be updated.
Consider the following scenario:
A Dynamic Host Configuration Protocol (DHCP) server that is running Windows Server 2008 receives a DHCPInform message from a relay agent.
The broadcast bit is set in this message.
In this scenario, the DHCP server that is running Windows Server 2008 sends the message back to the relay agent. In the message, the broadcast bit is not set, and the yiaddr field is set to 0. This behavior does not comply with the "Dynamic Host Configuration Protocol" specifications in Request for Comments (RFC) 2131. Therefore, the relay agent cannot forward the message back to the client that sent the DHCPInform message.
For example, users use the Web Distributed Authoring and Versioning (WebDAV) Web Client service to access a Microsoft SharePoint server. However, they usually experience an 11-second delay when they use the WebDAV Web Client service. In this case, the WebDAV Web Client service uses DHCPInform messages to query for updates in the configuration settings for the HTTP proxy.
This problem occurs because the DHCP server that is running Windows Server 2008 clears the broadcast bit in the DHCPInform packet.
After you install this hotfix, the DHCP server that is running Windows Server 2008 does not reset the broadcast bit.
A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.
If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.
Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:
Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.
Important Windows Vista and Windows Server 2008 hotfixes are included in the same packages. However, only one of these products may be listed on the “Hotfix Request” page. To request the hotfix package that applies to both Windows Vista and Windows Server 2008, just select the product that is listed on the page.
To apply this hotfix, your computer must be running Windows Server 2008. Additionally, your computer must have the DHCP server role enabled.
You do not have to restart the computer after you apply this hotfix. However, you must restart the DHCP service.
Hotfix replacement information
This hotfix does not replace any other previously released hotfixes.
To apply this hotfix, you do not have to make any changes to the registry.
The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.
Windows Server 2008 file information note
The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately . MUM and MANIFEST files, and the associated security catalog (.cat) files, are critical to maintaining the state of the updated component. The security catalog files (attributes not listed) are signed with a Microsoft digital signature.
For all supported x86-based versions of Windows Server 2008
For all supported x64-based versions of Windows Server 2008
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
The following is an example of the network traces that are generated at each stage of the process :
A DHCP client sends a DHCPInform message that has the broadcast bit set.
The DHCP server sends back a message for which the broadcast bit is not set.
Frame: + Ethernet: Etype = Internet IP (IPv4) + Ipv4: Src = 10.4.16.222, Dest = 10.10.16.2, Next Protocol = UDP, Packet ID = 27188, Total IP Length = 328 - Udp: SrcPort = BOOTP server(67), DstPort = BOOTP server(67), Length = 308 SourcePort: BOOTP server(67), 67(0x43) DestinationPort: BOOTP server(67), 67(0x43) TotalLength: 308 (0x134) Checksum: 64061 (0xFA3D) - Dhcp: Reply, MsgType = ACK, TransactionID = 0x1A5624C3 OpCode: Reply, 2(0x02) Hardwaretype: Ethernet HardwareAddressLength: 6 (0x6) HopCount: 0 (0x0) TransactionID: 441853123 (0x1A5624C3) Seconds: 0 (0x0) - Flags: 0 (0x0) Broadcast: (0...............) <- Broadcast bit is cleared Reserved: (.000000000000000) ClientIP: 10.10.18.18 YourIP: 0.0.0.0 <-- It is correct behavior. However, the relay agent will use this address if the broadcast bit is cleared. ServerIP: 0.0.0.0 RelayAgentIP: 10.10.16.2 + ClientHardwareAddress: 00-19-B9-20-FA-0E ServerHostName: BootFileName: MagicCookie: 126.96.36.199 + MessageType: ACK + ServerIdentifier: 10.4.16.222 + SubnetMask: 255.255.128.0 + DomainName: parl.gc.ca + Router: 10.10.16.1 + DomainNameServer: 0.0.168038622.168038623 + NBOverTCPIPNameServer: 0.0.168038622.168038623 + NodeType: H-node (8) + End:
DHCP relay agent uses the following RFC specifications:
A server or relay agent that sends or relays a DHCP message directly to a DHCP client should examine the BROADCAST bit in the "flags" field. The server or relay agent does not send the DHCP message to a relay agent specified in the "giaddr" field. If the BROADCAST bit is set to 1, the DHCP message should be sent as an IP broadcast by using an IP broadcast address (preferably 0xffffffff) as the IP destination address and as the link-layer broadcast address. If the BROADCAST bit is cleared to 0, the message should be sent as an IP unicast to the IP address that is specified in the "yiaddr" field and in the link-layer address that is specified in the "chaddr" field. If unicasting is not possible, the message can be sent as an IP broadcast by using an IP broadcast address (preferably 0xffffffff) as the IP destination address and by using the link-layer broadcast address as the link-layer destination address.