Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

A Windows Server 2003-based DHCP server does not respond correctly to DHCP INFORM requests if the requests are forwarded from the IP Helper API or from relay agents


View products that this article applies to.

Symptoms

Consider the following scenario:
  • A Windows Server 2003-based Dynamic Host Configuration Protocol (DHCP) server receives a DHCP INFORM packet from the IP Helper API or from a relay agent.
  • The broadcast bit is set in this packet.
In this scenario, the Windows Server 2003-based DHCP server sends the request back to the IP Helper API or to the relay agent. The broadcast bit is turned off, and the "yiaddr" field is set to 0. This behavior does not comply with Request for Comments (RFC) 2131, "Dynamic Host Configuration Protocol."

In this scenario, the IP Helper API or the relay agent is unable to forward the response package to the client that is sending the DHCP INFORM packet.

For example, users usually experience about 11 seconds of delay when they use the Web Distributed Authoring and Versioning (WebDAV) Web client service to access a Microsoft SharePoint server. The WebDAV Web client service uses DHCP INFORM requests to query updates to HTTP proxy configuration settings.

↑ Back to the top


Resolution

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 this specific problem. 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.

Prerequisites

To apply this hotfix, you must have either Windows Server 2003 Service Pack 1 or Windows Server 2003 Service Pack 2 installed.

Restart requirement

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 hotfixes.

File information

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 2003 with Service Pack 1, x86-based versions
File nameFile versionFile sizeDateTimePlatform
Dhcpssvc.dll5.2.3790.3107271,87220-Mar-200813:31x86
Windows Server 2003 with Service Pack 2, x86-based versions
File nameFile versionFile sizeDateTimePlatform
Dhcpssvc.dll5.2.3790.4257270,84820-Mar-200814:27x86
Windows Server 2003 with Service Pack 1, Itanium-based versions
File nameFile versionFile sizeDateTimePlatformSP requirementService branch
Dhcpssvc.dll5.2.3790.3107735,74420-Mar-200812:11IA-64SP1Not Applicable
Wdhcpssvc.dll5.2.3790.3107271,87220-Mar-200812:11x86SP1WOW
Windows Server 2003 with Service Pack 2, Itanium-based versions
File nameFile versionFile sizeDateTimePlatformSP requirementService branch
Dhcpssvc.dll5.2.3790.4257732,67220-Mar-200812:16IA-64SP2Not Applicable
Wdhcpssvc.dll5.2.3790.4257270,84820-Mar-200812:16x86SP2WOW
Windows Server 2003, x64-based versions
File nameFile versionFile sizeDateTimePlatformSP requirementService branch
Dhcpssvc.dll5.2.3790.3107434,17620-Mar-200812:11x64SP1Not Applicable
Wdhcpssvc.dll5.2.3790.3107271,87220-Mar-200812:11x86SP1WOW
Windows Server 2003 with Service Pack 2, x64-based versions
File nameFile versionFile sizeDateTimePlatformSP requirementService branch
Dhcpssvc.dll5.2.3790.4257432,64020-Mar-200812:18x64SP2Not Applicable
Wdhcpssvc.dll5.2.3790.4257270,84820-Mar-200812:18x86SP2WOW
Note After you install this hotfix, the Windows Server 2003-based DHCP server does not reset the broadcast bit in the scenario that was discussed in the �Symptoms� section.

↑ Back to the top


Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

↑ Back to the top


More information

The following steps occur in the scenario that is described in the "Symptoms" section:
  1. A DHCP client sends a DHCP Inform request that has a broadcast bit that resembles the following.
    + Ethernet: Etype = Internet IP (IPv4)
    + Ipv4: Src = 10.10.18.18, Dest = 255.255.255.255, Next Protocol = UDP, Packet ID = 6076, Total IP Length = 328
    - Udp: SrcPort = BOOTP client(68), DstPort = BOOTP server(67), Length = 308
    SourcePort: BOOTP client(68), 68(0x44)
    DestinationPort: BOOTP server(67), 67(0x43)
    TotalLength: 308 (0x134)
    Checksum: 7521 (0x1D61)
    - Dhcp: Request, MsgType = INFORM, TransactionID = 0x1A5624C3
    OpCode: Request, 1(0x01)
    Hardwaretype: Ethernet
    HardwareAddressLength: 6 (0x6)
    HopCount: 0 (0x0)
    TransactionID: 441853123 (0x1A5624C3)
    Seconds: 0 (0x0)
    - Flags: 32768 (0x8000)
    Broadcast: (1...............) <---- Broadcast bit is set.
    Reserved: (.000000000000000)
    ClientIP: 10.10.18.18
    YourIP: 0.0.0.0
    ServerIP: 0.0.0.0
    RelayAgentIP: 0.0.0.0
    + ClientHardwareAddress: 00-19-B9-20-FA-0E
    ServerHostName: 
    BootFileName: 
    MagicCookie: 99.130.83.99
    + MessageType: INFORM
    + clientID: (Type 1)
    + HostName: VISTA009W
    + VendorClassIdentifier: MSFT 5.0
    + ParameterRequestList: 
    + End:
    
  2. The relay agent forwards a DHCP INFORM request that resembles the following to a DHCP server.
    Frame: 
    + Ethernet: Etype = Internet IP (IPv4)
    + Ipv4: Src = 10.10.16.2, Dest = 10.4.16.222, Next Protocol = UDP, Packet ID = 45398, Total IP Length = 328
    - Udp: SrcPort = BOOTP client(68), DstPort = BOOTP server(67), Length = 308
    SourcePort: BOOTP client(68), 68(0x44)
    DestinationPort: BOOTP server(67), 67(0x43)
    TotalLength: 308 (0x134)
    Checksum: 49722 (0xC23A)
    - Dhcp: Request, MsgType = INFORM, TransactionID = 0x1A5624C3
    OpCode: Request, 1(0x01)
    Hardwaretype: Ethernet
    HardwareAddressLength: 6 (0x6)
    HopCount: 1 (0x1)
    TransactionID: 441853123 (0x1A5624C3)
    Seconds: 0 (0x0)
    - Flags: 32768 (0x8000)
    Broadcast: (1...............) <---- Broadcast bit is set
    Reserved: (.000000000000000)
    ClientIP: 10.10.18.18
    YourIP: 0.0.0.0
    ServerIP: 0.0.0.0
    RelayAgentIP: 10.10.16.2
    + ClientHardwareAddress: 00-19-B9-20-FA-0E
    ServerHostName: 
    BootFileName: 
    MagicCookie: 99.130.83.99
    + MessageType: INFORM
    + clientID: (Type 1)
    + HostName: VISTA009W
    + VendorClassIdentifier: MSFT 5.0
    + ParameterRequestList: 
    + End:
    
  3. The DHCP server responds to the DHCP INFORM request by sending a response that does not have a broadcast flag. The response resembles the following.
    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: 99.130.83.99
    + MessageType: ACK
    + ServerIdentifier: <XX.X.XX.XXX>
    + SubnetMask: 255.255.128.0
    + DomainName: <domain_name>
    + Router: <XX.XX.XX.X>
    + DomainNameServer: <X.X.XXXXXXXXX.XXXXXXXXX>
    + NBOverTCPIPNameServer: <X.X.XXXXXXXXX.XXXXXXXXX>
    + NodeType: H-node (8)
    + End:
    
  4. Per RFC 2131, the relay agent sends a message that resembles the following.
    Frame: 
    + Ethernet: Etype = Internet IP (IPv4)
    + Ipv4: Src = 10.10.16.2, Dest = 0.0.0.0, Next Protocol = UDP, Packet ID = 45402, Total IP Length = 328 destination 0.0.0.0 as YourIP ('yiaddr') is 0.0.0.0
    - Udp: SrcPort = BOOTP server(67), DstPort = BOOTP client(68), Length = 308
    SourcePort: BOOTP server(67), 67(0x43)
    DestinationPort: BOOTP client(68), 68(0x44)
    TotalLength: 308 (0x134)
    Checksum: 0 (0x0)
    - 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...............) <- no broadcast bit
    Reserved: (.000000000000000)
    ClientIP: 10.10.18.18
    YourIP: 0.0. 00.
    ServerIP: 0.0.0.0
    RelayAgentIP: 10.10.16.2
    + ClientHardwareAddress: 00-19-B9-20-FA-0E
    ServerHostName: 
    BootFileName: 
    MagicCookie: 99.130.83.99
    + MessageType: ACK
    + ServerIdentifier: <XX.X.XX.XXX>
    + SubnetMask: 255.255.128.0
    + DomainName: <domain_name>
    + Router: <XX.XX.XX.X>
    + DomainNameServer: <X.X.XXXXXXXXX.XXXXXXXXX>
    + NBOverTCPIPNameServer: <X.X.XXXXXXXXX.XXXXXXXXX>
    + NodeType: H-node (8)
    + End:
    

    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. If this bit is 1, the DHCP message should be sent as an IP broadcast by using an IP broadcast address as the IP destination address and as the link-layer broadcast address. (The IP broadcast should preferably be 0xffffffff.) If the BROADCAST bit is 0, the message should be sent as an IP unicast to the IP address that is specified in the "yiaddr" field (the Your IP address field) and to the link-layer address that is specified in the "chaddr" field (the Client Hardware address field). If unicasting is not possible, the message may be sent as an IP broadcast by using an IP broadcast address (preferably 0xffffffff) as the IP destination address. The link-layer broadcast address should be used as the link-layer destination address. However, the DHCP client does not receive this packet because its destination is 0.0.0.0.

    For more information about RFC 2131, visit the following Internet Drafts Web site:
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
824684 Description of the standard terminology that is used to describe Microsoft software updates

↑ Back to the top


Keywords: kbautohotfix, kbexpertiseinter, kbqfe, kbHotfixServer, KB950574

↑ Back to the top

Article Info
Article ID : 950574
Revision : 2
Created on : 10/8/2011
Published on : 10/8/2011
Exists online : False
Views : 330